From: andre.przywara@arm•com (Andre Przywara)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v6 18/20] KVM: introduce kvm_check_device_type()
Date: Mon, 12 Jan 2015 12:33:26 +0000 [thread overview]
Message-ID: <54B3BF16.2080105@arm.com> (raw)
In-Reply-To: <20150111152239.GD21444@cbox>
Hej Christoffer,
On 11/01/15 15:22, Christoffer Dall wrote:
> On Fri, Jan 09, 2015 at 01:42:42PM +0000, Andre Przywara wrote:
>> Hi Christoffer,
>>
>> On 09/01/15 12:33, Christoffer Dall wrote:
>>> On Fri, Jan 09, 2015 at 11:54:36AM +0000, Andre Przywara wrote:
>>>> While we can easily register and unregister KVM devices, there is
>>>> currently no easy way of checking whether a device has been
>>>> registered.
>>>> Introduce kvm_check_device_type() for that purpose and use it in two
>>>> existing functions. Also change the return code for an invalid
>>>> type number from ENOSPC to EINVAL.
>>>> This function will be later used by another patch set to check
>>>> whether a KVM_CREATE_IRQCHIP ioctl is valid.
>>>
>>> I feel like this is misguided and the vgic should be able to figure this
>>> stuff out internally. Did you have code for this approach somewhere
>>> that I can take a look at?
>>
>> I pushed my WIP patch on top of the kvm-gicv3/v6 tree.
>> Given how that looks I reckoned the generic solution would be more
>> preferable.
>> Basically we internally decide in the _probe function whether we support
>> GICv2 emulation or not, which is mostly driven by device tree
>> properties. So at the moment I just register the GIC_V2 KVM device or
>> not. Now with the "vgic internal" solution I misuse the GICV address
>> base as a hint of the GICv2 emulation availability. Alternatively I have
>> to introduce a new variable to mirror what the KVM device array already
>> holds, which seems kind of exerted to me.
>> Besides that I am not sure if the GICV address hint will always be a
>> reliable indicator and what we will do if there will be another GIC
>> model to be emulated in the future (maybe we need that for the ITS
>> emulation already?)
>
> I don't think it looks that bad.
>
> Only your gicv3 and gicv2 code files know what they are capable of
> emulating, how you choose to store this state internally in those files
> is a somewhat orthogonal discussion from using the kvm device API.
Well, the point is that the emulation capability is a hardware property
and thus the knowledge is actually in the host part of the VGIC (so in
vgic-v3.c and vgic-v2.c). From here we "communicate" the capability to
userland by registering the respective VGIC KVM devices only. Since the
emulation part of the VGIC lives in different files (vgic.c and
vgic-vx-emul.c) we would need some kind of export to them, too. I found
that it would be cleaner to just re-use what we already have with the
KVM devices.
> Using the KVM device api is just another way of storing and exposing the
> information globally (you take registering the device types as an
> indication of the state).
>
> Finally, I don't even think you ned the can_emulate function, I think
> you should just return an error from init_vgic_model (which happens to
> collide with my suggestion on making those functions a void function in
> one of the previous patches) and you're done.
I think I checked this before and since the init_vgic_model()
implementations are in vgic-vx-emul.c we don't know the hardware
capability anymore and would need some kind of variable holding that
information (which lead me to re-using the KVM device knowledge). But I
will re-check if there is an easy fix in here.
>>
>> So I prefer the more generic solution.
>> Let me know what you think, I can as well drop 18/20 and merge the above
>> mentioned patch.
>>
>>> I forget: Are we still requiring KVM_CREATE_IRQCHIP for VGICv3 or are we
>>> just relying on users to use KVM_CREATE_DEVICE for anything in the
>>> future?
>>
>> Since KVM_CREATE_IRQCHIP does not take an argument, we cannot use it for
>> GICv3. So GICv3 mandates KVM_CREATE_DEVICE. We need userspace
>> adjustments for GICv3 anyway, so that's not a problem.
>
> ok, so KVM_CREATE_IRQCHIP is a direct alias for KVM_CREATE_DEVICE(GIC_V2)
> and is deprecated for GICv3? If so, we should probably update the
> documentation to indicate the KVM_CREATE_IRQCHIP creates a GICv2 and
> should not be used for any other in-kernel GIC versions.
What about the following wording in api.txt:
-----
On ARM/arm64, a GICv2 is created. Any other VGIC versions require the
usage of KVM_CREATE_DEVICE (which can and should also be used to create
a virtual GICv2).
-----
In fact both QEMU and kvmtool currently try KVM_CREATE_DEVICE first even
for a VGICv2 on a GICv2 and only fall back to KVM_CREATE_IRQCHIP if that
fails (to support older kernels).
Cheers,
Andre.
next prev parent reply other threads:[~2015-01-12 12:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 11:54 [PATCH v6 00/20] KVM GICv3 emulation Andre Przywara
2015-01-09 11:54 ` [PATCH v6 01/20] arm/arm64: KVM: rework MPIDR assignment and add accessors Andre Przywara
2015-01-09 11:54 ` [PATCH v6 02/20] arm/arm64: KVM: pass down user space provided GIC type into vGIC code Andre Przywara
2015-01-09 11:54 ` [PATCH v6 03/20] arm/arm64: KVM: refactor vgic_handle_mmio() function Andre Przywara
2015-01-09 11:54 ` [PATCH v6 04/20] arm/arm64: KVM: wrap 64 bit MMIO accesses with two 32 bit ones Andre Przywara
2015-01-09 11:54 ` [PATCH v6 05/20] arm/arm64: KVM: introduce per-VM ops Andre Przywara
2015-01-11 14:58 ` Christoffer Dall
2015-01-09 11:54 ` [PATCH v6 06/20] arm/arm64: KVM: move kvm_register_device_ops() into vGIC probing Andre Przywara
2015-01-09 11:54 ` [PATCH v6 07/20] arm/arm64: KVM: dont rely on a valid GICH base address Andre Przywara
2015-01-09 11:54 ` [PATCH v6 08/20] arm/arm64: KVM: make the maximum number of vCPUs a per-VM value Andre Przywara
2015-01-11 14:58 ` Christoffer Dall
2015-01-12 9:34 ` Andre Przywara
2015-01-09 11:54 ` [PATCH v6 09/20] arm/arm64: KVM: make the value of ICC_SRE_EL1 a per-VM variable Andre Przywara
2015-01-09 11:54 ` [PATCH v6 10/20] arm/arm64: KVM: refactor MMIO accessors Andre Przywara
2015-01-09 11:54 ` [PATCH v6 11/20] arm/arm64: KVM: refactor/wrap vgic_set/get_attr() Andre Przywara
2015-01-09 11:54 ` [PATCH v6 12/20] arm/arm64: KVM: add vgic.h header file Andre Przywara
2015-01-09 11:54 ` [PATCH v6 13/20] arm/arm64: KVM: split GICv2 specific emulation code from vgic.c Andre Przywara
2015-01-09 11:54 ` [PATCH v6 14/20] arm/arm64: KVM: add opaque private pointer to MMIO data Andre Przywara
2015-01-09 11:54 ` [PATCH v6 15/20] arm/arm64: KVM: add virtual GICv3 distributor emulation Andre Przywara
2015-01-11 15:15 ` Christoffer Dall
2015-01-12 9:57 ` Andre Przywara
2015-01-12 17:08 ` Christoffer Dall
2015-01-09 11:54 ` [PATCH v6 16/20] arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields Andre Przywara
2015-01-09 11:54 ` [PATCH v6 17/20] arm64: KVM: add SGI generation register emulation Andre Przywara
2015-01-09 11:54 ` [PATCH v6 18/20] KVM: introduce kvm_check_device_type() Andre Przywara
2015-01-09 12:33 ` Christoffer Dall
2015-01-09 13:42 ` Andre Przywara
2015-01-11 15:22 ` Christoffer Dall
2015-01-12 12:33 ` Andre Przywara [this message]
2015-01-12 17:11 ` Christoffer Dall
2015-01-14 12:33 ` Andre Przywara
2015-01-09 11:54 ` [PATCH v6 19/20] arm/arm64: KVM: enable kernel side of GICv3 emulation Andre Przywara
2015-01-11 15:32 ` Christoffer Dall
2015-01-09 11:54 ` [PATCH v6 20/20] arm/arm64: KVM: allow userland to request a virtual GICv3 Andre Przywara
2015-01-11 15:35 ` Christoffer Dall
2015-01-13 16:25 ` [PATCH v6 00/20] KVM GICv3 emulation Tomasz Nowicki
2015-01-14 0:04 ` Andre Przywara
2015-01-14 8:50 ` Tomasz Nowicki
2015-01-14 8:51 ` Eric Auger
2015-01-14 10:48 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54B3BF16.2080105@arm.com \
--to=andre.przywara@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox