All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 09 Jan 2015 13:42:42 +0000	[thread overview]
Message-ID: <54AFDAD2.7010505@arm.com> (raw)
In-Reply-To: <20150109123345.GR21092@cbox>

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?)

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.

Cheers,
Andre.

>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Changelog:
>>  (new in v6)
>>
>>  include/linux/kvm_host.h |    1 +
>>  virt/kvm/kvm_main.c      |   33 +++++++++++++++++++++------------
>>  2 files changed, 22 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index 83d770e..723d0d2 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -1038,6 +1038,7 @@ void kvm_device_get(struct kvm_device *dev);
>>  void kvm_device_put(struct kvm_device *dev);
>>  struct kvm_device *kvm_device_from_filp(struct file *filp);
>>  int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type);
>> +int kvm_check_device_type(u32 type);
>>  void kvm_unregister_device_ops(u32 type);
>>  
>>  extern struct kvm_device_ops kvm_mpic_ops;
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 1cc6e2e..c7711b2 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2341,13 +2341,24 @@ static struct kvm_device_ops *kvm_device_ops_table[KVM_DEV_TYPE_MAX] = {
>>  #endif
>>  };
>>  
>> -int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>> +int kvm_check_device_type(u32 type)
>>  {
>>  	if (type >= ARRAY_SIZE(kvm_device_ops_table))
>> -		return -ENOSPC;
>> +		return -EINVAL;
>>  
>> -	if (kvm_device_ops_table[type] != NULL)
>> -		return -EEXIST;
>> +	if (kvm_device_ops_table[type] == NULL)
>> +		return -ENODEV;
>> +
>> +	return -EEXIST;
> 
> I think this looks a bit screwy, the function always return errors...?
> 
>> +}
>> +
>> +int kvm_register_device_ops(struct kvm_device_ops *ops, u32 type)
>> +{
>> +	int ret;
>> +
>> +	ret = kvm_check_device_type(type);
>> +	if (ret != -ENODEV)
>> +		return ret;
>>  
>>  	kvm_device_ops_table[type] = ops;
>>  	return 0;
>> @@ -2364,19 +2375,17 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
>>  {
>>  	struct kvm_device_ops *ops = NULL;
>>  	struct kvm_device *dev;
>> -	bool test = cd->flags & KVM_CREATE_DEVICE_TEST;
>>  	int ret;
>>  
>> -	if (cd->type >= ARRAY_SIZE(kvm_device_ops_table))
>> -		return -ENODEV;
> 
> now you're basically changing a userspace-facing ABI because the ENODEV
> becomes an EINVAL, right?
> 
>> -
>> -	ops = kvm_device_ops_table[cd->type];
>> -	if (ops == NULL)
>> -		return -ENODEV;
>> +	ret = kvm_check_device_type(cd->type);
>> +	if (ret != -EEXIST)
>> +		return ret;
>>  
>> -	if (test)
>> +	if (cd->flags & KVM_CREATE_DEVICE_TEST)
>>  		return 0;
>>  
>> +	ops = kvm_device_ops_table[cd->type];
>> +
>>  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>>  	if (!dev)
>>  		return -ENOMEM;
>> -- 
>> 1.7.9.5
>>
> 
> Thanks,
> -Christoffer
> 

  reply	other threads:[~2015-01-09 13:42 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 [this message]
2015-01-11 15:22       ` Christoffer Dall
2015-01-12 12:33         ` Andre Przywara
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=54AFDAD2.7010505@arm.com \
    --to=andre.przywara@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.