All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "penberg@kernel.org" <penberg@kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Marc Zyngier <Marc.Zyngier@arm.com>
Subject: Re: [PATCH 03/11] kvmtool: AArch{32,64}: use KVM_CREATE_DEVICE & co to instanciate the GIC
Date: Mon, 26 Jan 2015 12:06:01 +0000	[thread overview]
Message-ID: <54C62DA9.7010809@arm.com> (raw)
In-Reply-To: <20150126112603.GE15598@arm.com>

On 26/01/15 11:26, Will Deacon wrote:
> On Fri, Jan 23, 2015 at 04:35:02PM +0000, Andre Przywara wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> As of 3.14, KVM/arm supports the creation/configuration of the GIC through
>> a more generic device API, which is now the preferred way to do so.
>>
>> Plumb the new API in, and allow the old code to be used as a fallback.
>>
>> [Andre: Rename some functions on the way to differentiate between
>> creation and initialisation more clearly.]
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  tools/kvm/arm/gic.c                    |   60 ++++++++++++++++++++++++++++----
>>  tools/kvm/arm/include/arm-common/gic.h |    2 +-
>>  tools/kvm/arm/kvm.c                    |    6 ++--
>>  3 files changed, 57 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/kvm/arm/gic.c b/tools/kvm/arm/gic.c
>> index 5d8cbe6..ce5f7fa 100644
>> --- a/tools/kvm/arm/gic.c
>> +++ b/tools/kvm/arm/gic.c
>> @@ -7,7 +7,41 @@
>>  #include <linux/byteorder.h>
>>  #include <linux/kvm.h>
>>  
>> -int gic__init_irqchip(struct kvm *kvm)
>> +static int gic_fd = -1;
>> +
>> +static int gic__create_device(struct kvm *kvm)
>> +{
>> +	int err;
>> +	u64 cpu_if_addr = ARM_GIC_CPUI_BASE;
>> +	u64 dist_addr = ARM_GIC_DIST_BASE;
>> +	struct kvm_create_device gic_device = {
>> +		.type	= KVM_DEV_TYPE_ARM_VGIC_V2,
>> +	};
>> +	struct kvm_device_attr cpu_if_attr = {
>> +		.group	= KVM_DEV_ARM_VGIC_GRP_ADDR,
>> +		.attr	= KVM_VGIC_V2_ADDR_TYPE_CPU,
>> +		.addr	= (u64)(unsigned long)&cpu_if_addr,
>> +	};
>> +	struct kvm_device_attr dist_attr = {
>> +		.group	= KVM_DEV_ARM_VGIC_GRP_ADDR,
>> +		.attr	= KVM_VGIC_V2_ADDR_TYPE_DIST,
>> +		.addr	= (u64)(unsigned long)&dist_addr,
>> +	};
>> +
>> +	err = ioctl(kvm->vm_fd, KVM_CREATE_DEVICE, &gic_device);
>> +	if (err)
>> +		return err;
>> +
>> +	gic_fd = gic_device.fd;
>> +
>> +	err = ioctl(gic_fd, KVM_SET_DEVICE_ATTR, &cpu_if_attr);
>> +	if (err)
>> +		return err;
>> +
>> +	return ioctl(gic_fd, KVM_SET_DEVICE_ATTR, &dist_attr);
>> +}
>> +
>> +static int gic__create_irqchip(struct kvm *kvm)
>>  {
>>  	int err;
>>  	struct kvm_arm_device_addr gic_addr[] = {
>> @@ -23,12 +57,6 @@ int gic__init_irqchip(struct kvm *kvm)
>>  		}
>>  	};
>>  
>> -	if (kvm->nrcpus > GIC_MAX_CPUS) {
>> -		pr_warning("%d CPUS greater than maximum of %d -- truncating\n",
>> -				kvm->nrcpus, GIC_MAX_CPUS);
>> -		kvm->nrcpus = GIC_MAX_CPUS;
>> -	}
>> -
>>  	err = ioctl(kvm->vm_fd, KVM_CREATE_IRQCHIP);
>>  	if (err)
>>  		return err;
>> @@ -41,6 +69,24 @@ int gic__init_irqchip(struct kvm *kvm)
>>  	return err;
>>  }
>>  
>> +int gic__create(struct kvm *kvm)
>> +{
>> +	int err;
>> +
>> +	if (kvm->nrcpus > GIC_MAX_CPUS) {
>> +		pr_warning("%d CPUS greater than maximum of %d -- truncating\n",
>> +				kvm->nrcpus, GIC_MAX_CPUS);
>> +		kvm->nrcpus = GIC_MAX_CPUS;
>> +	}
>> +
>> +	/* Try the new way first, and fallback on legacy method otherwise */
>> +	err = gic__create_device(kvm);
>> +	if (err)
>> +		err = gic__create_irqchip(kvm);
> 
> This fallback doesn't look safe to me:
> 
>   - gic_fd might remain initialised
>   - What does the kernel vgic driver do if you've already done
>     a successful KVM_CREATE_DEVICE and then try to use the legacy method?

Good point. I think we need to cleanup the device by closing the fd (and
resetting the variable to -1) in case any of the subsequent ioctls
return with an error (e.g. due to unaligned addresses).
I have to check what happens in the kernel in that case, though.

Cheers,
Andre.

  reply	other threads:[~2015-01-26 12:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 16:34 [PATCH 00/11] kvmtool: Support new VGIC kernel features Andre Przywara
2015-01-23 16:35 ` [PATCH 01/11] kvmtool: add new VGIC_GRP definition (pulled from 3.19-rc1) Andre Przywara
2015-01-23 16:35 ` [PATCH 02/11] kvmtool: AArch64: Reserve two 64k pages for GIC CPU interface Andre Przywara
2015-01-23 16:35 ` [PATCH 03/11] kvmtool: AArch{32,64}: use KVM_CREATE_DEVICE & co to instanciate the GIC Andre Przywara
2015-01-26 11:26   ` Will Deacon
2015-01-26 12:06     ` Andre Przywara [this message]
2015-01-23 16:35 ` [PATCH 04/11] kvmtool: irq: add irq__get_nr_allocated_lines Andre Przywara
2015-01-23 16:35 ` [PATCH 05/11] kvmtool: AArch{32,64}: dynamically configure the number of GIC interrupts Andre Przywara
2015-01-23 16:35 ` [PATCH 06/11] kvmtool: finish VGIC initialisation explicitly Andre Przywara
2015-01-23 16:35 ` [PATCH 07/11] kvmtool: prepare for instantiating different IRQ chip devices Andre Przywara
2015-01-23 16:35 ` [PATCH 08/11] kvmtool: public header definitions from GICv3 emulation patch series Andre Przywara
2015-01-23 16:35 ` [PATCH 09/11] kvmtool: add required GICv3 defines also to ARM Andre Przywara
2015-01-23 16:35 ` [PATCH 10/11] kvmtool: add support for supplying GICv3 redistributor addresses Andre Przywara
2015-01-23 16:35 ` [PATCH 11/11] kvmtool: add command line parameter to instantiate a vGICv3 Andre Przywara
2015-01-26 11:30   ` Will Deacon
2015-01-26 11:43     ` Andre Przywara
2015-01-26 11:52       ` Marc Zyngier

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=54C62DA9.7010809@arm.com \
    --to=andre.przywara@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=penberg@kernel.org \
    --cc=will.deacon@arm.com \
    /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.