Since the advent of dynamic initialization of VGIC, this latter is
initialized very late, on the first vcpu run. This initialization
could be initiated much earlier by the user, as soon as it has
provided the requested dimensioning parameters:
- number of IRQs and number of vCPUs,
- DIST and CPU interface base address.
One motivation behind being able to initialize the VGIC sooner is
related to the setup of IRQ injection in VFIO use case. The VFIO
signaling, especially when used along with irqfd must be set *after*
vgic initialization to prevent any virtual IRQ injection before
VGIC initialization. If virtual IRQ injection occurs before the VGIC
init, the IRQ cannot be injected and subsequent injection is blocked
due to VFIO completion mechanism (unmask/mask or forward/unforward).
This patch adds a new entry to the VGIC KVM device that allows
the user to manually request the VGIC init:
- a new KVM_DEV_ARM_VGIC_GRP_CTRL group is introduced.
- Its first attribute is KVM_DEV_ARM_VGIC_CTRL_INIT
The rationale behind introducing a group is to be able to add other
controls later on, if needed.
Obviously, as soon as the init is done, the dimensioning parameters
cannot be changed.
Signed-off-by: Eric Auger <[email protected]>
---
Documentation/virtual/kvm/devices/arm-vgic.txt | 11 +++++++++++
arch/arm/include/uapi/asm/kvm.h | 2 ++
arch/arm64/include/uapi/asm/kvm.h | 2 ++
virt/kvm/arm/vgic.c | 14 +++++++++++++-
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt
index df8b0c7..80db43f 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
@@ -81,3 +81,14 @@ Groups:
-EINVAL: Value set is out of the expected range
-EBUSY: Value has already be set, or GIC has already been initialized
with default values.
+
+ KVM_DEV_ARM_VGIC_GRP_CTRL
+ Attributes:
+ KVM_DEV_ARM_VGIC_CTRL_INIT
+ request the initialization of the VGIC, no additional parameter in
+ kvm_device_attr.addr.
+ Errors:
+ -ENXIO: distributor or CPU interface base address were not set prior
+ to that call
+ -EINVAL: number of vcpus is not known
+ -ENOMEM: memory shortage when allocating vgic internal data
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index 77547bb..2499867 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -175,6 +175,8 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
#define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
+#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
+#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 1ed4417..b35c95a 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -161,6 +161,8 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
#define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
+#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
+#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index b76c38c..2fe5bdb 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -2474,7 +2474,14 @@ static int vgic_set_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
return ret;
}
-
+ case KVM_DEV_ARM_VGIC_GRP_CTRL: {
+ switch (attr->attr) {
+ case KVM_DEV_ARM_VGIC_CTRL_INIT:
+ r = kvm_vgic_init(dev->kvm);
+ return r;
+ }
+ break;
+ }
}
return -ENXIO;
@@ -2553,6 +2560,11 @@ static int vgic_has_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
return vgic_has_attr_regs(vgic_cpu_ranges, offset);
case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
return 0;
+ case KVM_DEV_ARM_VGIC_GRP_CTRL:
+ switch (attr->attr) {
+ case KVM_DEV_ARM_VGIC_CTRL_INIT:
+ return 0;
+ }
}
return -ENXIO;
}
--
1.9.1
On 2 December 2014 at 17:27, Eric Auger <[email protected]> wrote:
> Since the advent of dynamic initialization of VGIC, this latter is
> initialized very late, on the first vcpu run. This initialization
> could be initiated much earlier by the user, as soon as it has
> provided the requested dimensioning parameters:
> - number of IRQs and number of vCPUs,
> - DIST and CPU interface base address.
>
> One motivation behind being able to initialize the VGIC sooner is
> related to the setup of IRQ injection in VFIO use case. The VFIO
> signaling, especially when used along with irqfd must be set *after*
> vgic initialization to prevent any virtual IRQ injection before
> VGIC initialization. If virtual IRQ injection occurs before the VGIC
> init, the IRQ cannot be injected and subsequent injection is blocked
> due to VFIO completion mechanism (unmask/mask or forward/unforward).
This implies that you're potentially injecting virtual IRQs
(and changing the state of the VGIC) before we actually
start running the VM (ie before userspace calls KVM_RUN).
Is that right? It seems odd, but maybe vfio works that way?
-- PMM
On 12/02/2014 06:50 PM, Peter Maydell wrote:
> On 2 December 2014 at 17:27, Eric Auger <[email protected]> wrote:
>> Since the advent of dynamic initialization of VGIC, this latter is
>> initialized very late, on the first vcpu run. This initialization
>> could be initiated much earlier by the user, as soon as it has
>> provided the requested dimensioning parameters:
>> - number of IRQs and number of vCPUs,
>> - DIST and CPU interface base address.
>>
>> One motivation behind being able to initialize the VGIC sooner is
>> related to the setup of IRQ injection in VFIO use case. The VFIO
>> signaling, especially when used along with irqfd must be set *after*
>> vgic initialization to prevent any virtual IRQ injection before
>> VGIC initialization. If virtual IRQ injection occurs before the VGIC
>> init, the IRQ cannot be injected and subsequent injection is blocked
>> due to VFIO completion mechanism (unmask/mask or forward/unforward).
>
> This implies that you're potentially injecting virtual IRQs
> (and changing the state of the VGIC) before we actually
> start running the VM (ie before userspace calls KVM_RUN).
> Is that right? It seems odd, but maybe vfio works that way?
Hi Peter,
as soon as VFIO signaling is set up (the device IRQ index is linked to
an eventfd, the physical IRQ VFIO handler is installed and the physical
IRQ is enabled at interrupt controller level), virtual IRQs are likely
to be injected. With current QEMU code, we setup this VFIO signaling
*before* the vgic readiness (either on machine init done or reset
notifier) and we face that issue of early injection. QEMU related
patches to follow ...
Best Regards
Eric
>
> -- PMM
>
On Tue, Dec 02, 2014 at 05:50:00PM +0000, Peter Maydell wrote:
> On 2 December 2014 at 17:27, Eric Auger <[email protected]> wrote:
> > Since the advent of dynamic initialization of VGIC, this latter is
> > initialized very late, on the first vcpu run. This initialization
> > could be initiated much earlier by the user, as soon as it has
> > provided the requested dimensioning parameters:
> > - number of IRQs and number of vCPUs,
> > - DIST and CPU interface base address.
> >
> > One motivation behind being able to initialize the VGIC sooner is
> > related to the setup of IRQ injection in VFIO use case. The VFIO
> > signaling, especially when used along with irqfd must be set *after*
> > vgic initialization to prevent any virtual IRQ injection before
> > VGIC initialization. If virtual IRQ injection occurs before the VGIC
> > init, the IRQ cannot be injected and subsequent injection is blocked
> > due to VFIO completion mechanism (unmask/mask or forward/unforward).
>
> This implies that you're potentially injecting virtual IRQs
> (and changing the state of the VGIC) before we actually
> start running the VM (ie before userspace calls KVM_RUN).
> Is that right? It seems odd, but maybe vfio works that way?
>
Yeah, I can't think of a cleaner way to do this. VFIO doesn't know
anything about KVM or whether a machine is running or not. QEMU has to
configure all this before starting a VM (wiring up IRQs after the VM is
running is even more weird imho, when would you even do that?) so
interrupts from the real hardware are bound to hit VFIO just
before/during/after VCPUs are started, and VFIO doesn't have any caching
mechanism for this state, it really has to go to the consumer of the
interrupt, which is KVM in the case of forwarded interrupts.
Did I miss something obvious here?
-Christoffer
On Tue, Dec 02, 2014 at 06:27:31PM +0100, Eric Auger wrote:
> Since the advent of dynamic initialization of VGIC, this latter is
> initialized very late, on the first vcpu run. This initialization
> could be initiated much earlier by the user, as soon as it has
> provided the requested dimensioning parameters:
> - number of IRQs and number of vCPUs,
> - DIST and CPU interface base address.
>
> One motivation behind being able to initialize the VGIC sooner is
> related to the setup of IRQ injection in VFIO use case. The VFIO
> signaling, especially when used along with irqfd must be set *after*
> vgic initialization to prevent any virtual IRQ injection before
> VGIC initialization. If virtual IRQ injection occurs before the VGIC
> init, the IRQ cannot be injected and subsequent injection is blocked
> due to VFIO completion mechanism (unmask/mask or forward/unforward).
>
> This patch adds a new entry to the VGIC KVM device that allows
> the user to manually request the VGIC init:
> - a new KVM_DEV_ARM_VGIC_GRP_CTRL group is introduced.
> - Its first attribute is KVM_DEV_ARM_VGIC_CTRL_INIT
>
> The rationale behind introducing a group is to be able to add other
> controls later on, if needed.
>
> Obviously, as soon as the init is done, the dimensioning parameters
> cannot be changed.
you would need to add a check in the vcpu_create path, which I don't
believe we currently have. That may conflict with Andre's series so we
need to coordinate.
We're also seeing this potentially being useful for migration, so my
feeling is that the GICv3 patches should be rebased on this patch and
this patch should include a check in the vcpu create path.
>
> Signed-off-by: Eric Auger <[email protected]>
> ---
> Documentation/virtual/kvm/devices/arm-vgic.txt | 11 +++++++++++
> arch/arm/include/uapi/asm/kvm.h | 2 ++
> arch/arm64/include/uapi/asm/kvm.h | 2 ++
> virt/kvm/arm/vgic.c | 14 +++++++++++++-
> 4 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt
> index df8b0c7..80db43f 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
> @@ -81,3 +81,14 @@ Groups:
> -EINVAL: Value set is out of the expected range
> -EBUSY: Value has already be set, or GIC has already been initialized
> with default values.
> +
> + KVM_DEV_ARM_VGIC_GRP_CTRL
> + Attributes:
> + KVM_DEV_ARM_VGIC_CTRL_INIT
> + request the initialization of the VGIC, no additional parameter in
> + kvm_device_attr.addr.
> + Errors:
> + -ENXIO: distributor or CPU interface base address were not set prior
> + to that call
this should be more generic to also apply to GICv3, I would suggest:
"VGIC not properly configured as required prior to calling this
attribute."
alternatively, the attribute should be KVM_DEV_ARM_VGIC_V2_CTRL_INIT.
> + -EINVAL: number of vcpus is not known
can we have a different error code for this case? ENODEV for example?
> + -ENOMEM: memory shortage when allocating vgic internal data
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index 77547bb..2499867 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -175,6 +175,8 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> +#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> +#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 1ed4417..b35c95a 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -161,6 +161,8 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> +#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> +#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index b76c38c..2fe5bdb 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -2474,7 +2474,14 @@ static int vgic_set_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
>
> return ret;
> }
> -
> + case KVM_DEV_ARM_VGIC_GRP_CTRL: {
> + switch (attr->attr) {
> + case KVM_DEV_ARM_VGIC_CTRL_INIT:
> + r = kvm_vgic_init(dev->kvm);
> + return r;
> + }
> + break;
> + }
> }
>
> return -ENXIO;
> @@ -2553,6 +2560,11 @@ static int vgic_has_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
> return vgic_has_attr_regs(vgic_cpu_ranges, offset);
> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
> return 0;
> + case KVM_DEV_ARM_VGIC_GRP_CTRL:
> + switch (attr->attr) {
> + case KVM_DEV_ARM_VGIC_CTRL_INIT:
> + return 0;
> + }
> }
> return -ENXIO;
> }
> --
> 1.9.1
>
On 2 December 2014 at 17:54, Eric Auger <[email protected]> wrote:
> as soon as VFIO signaling is set up (the device IRQ index is linked to
> an eventfd, the physical IRQ VFIO handler is installed and the physical
> IRQ is enabled at interrupt controller level), virtual IRQs are likely
> to be injected. With current QEMU code, we setup this VFIO signaling
> *before* the vgic readiness (either on machine init done or reset
> notifier) and we face that issue of early injection. QEMU related
> patches to follow ...
So can you describe in QEMU terms how the lifecycle of these
things works? How do we ensure that we don't start trying
to inject VFIO IRQs before we've even created the vgic, for
instance?
thanks
-- PMM
Hi Christoffer
On 12/03/2014 11:45 AM, Christoffer Dall wrote:
> On Tue, Dec 02, 2014 at 06:27:31PM +0100, Eric Auger wrote:
>> Since the advent of dynamic initialization of VGIC, this latter is
>> initialized very late, on the first vcpu run. This initialization
>> could be initiated much earlier by the user, as soon as it has
>> provided the requested dimensioning parameters:
>> - number of IRQs and number of vCPUs,
>> - DIST and CPU interface base address.
>>
>> One motivation behind being able to initialize the VGIC sooner is
>> related to the setup of IRQ injection in VFIO use case. The VFIO
>> signaling, especially when used along with irqfd must be set *after*
>> vgic initialization to prevent any virtual IRQ injection before
>> VGIC initialization. If virtual IRQ injection occurs before the VGIC
>> init, the IRQ cannot be injected and subsequent injection is blocked
>> due to VFIO completion mechanism (unmask/mask or forward/unforward).
>>
>> This patch adds a new entry to the VGIC KVM device that allows
>> the user to manually request the VGIC init:
>> - a new KVM_DEV_ARM_VGIC_GRP_CTRL group is introduced.
>> - Its first attribute is KVM_DEV_ARM_VGIC_CTRL_INIT
>>
>> The rationale behind introducing a group is to be able to add other
>> controls later on, if needed.
>>
>> Obviously, as soon as the init is done, the dimensioning parameters
>> cannot be changed.
>
> you would need to add a check in the vcpu_create path,
check added in v2
which I don't
> believe we currently have. That may conflict with Andre's series so we
> need to coordinate.
>
> We're also seeing this potentially being useful for migration, so my
> feeling is that the GICv3 patches should be rebased on this patch and
> this patch should include a check in the vcpu create path.
>
>>
>> Signed-off-by: Eric Auger <[email protected]>
>> ---
>> Documentation/virtual/kvm/devices/arm-vgic.txt | 11 +++++++++++
>> arch/arm/include/uapi/asm/kvm.h | 2 ++
>> arch/arm64/include/uapi/asm/kvm.h | 2 ++
>> virt/kvm/arm/vgic.c | 14 +++++++++++++-
>> 4 files changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt
>> index df8b0c7..80db43f 100644
>> --- a/Documentation/virtual/kvm/devices/arm-vgic.txt
>> +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
>> @@ -81,3 +81,14 @@ Groups:
>> -EINVAL: Value set is out of the expected range
>> -EBUSY: Value has already be set, or GIC has already been initialized
>> with default values.
>> +
>> + KVM_DEV_ARM_VGIC_GRP_CTRL
>> + Attributes:
>> + KVM_DEV_ARM_VGIC_CTRL_INIT
>> + request the initialization of the VGIC, no additional parameter in
>> + kvm_device_attr.addr.
>> + Errors:
>> + -ENXIO: distributor or CPU interface base address were not set prior
>> + to that call
>
> this should be more generic to also apply to GICv3, I would suggest:
>
> "VGIC not properly configured as required prior to calling this
> attribute."
corrected
>
> alternatively, the attribute should be KVM_DEV_ARM_VGIC_V2_CTRL_INIT.
>
>> + -EINVAL: number of vcpus is not known
>
> can we have a different error code for this case? ENODEV for example?
corrected
Thanks
Eric
>
>> + -ENOMEM: memory shortage when allocating vgic internal data
>
>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>> index 77547bb..2499867 100644
>> --- a/arch/arm/include/uapi/asm/kvm.h
>> +++ b/arch/arm/include/uapi/asm/kvm.h
>> @@ -175,6 +175,8 @@ struct kvm_arch_memory_slot {
>> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> +#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> +#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 1ed4417..b35c95a 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -161,6 +161,8 @@ struct kvm_arch_memory_slot {
>> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> +#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> +#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>>
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
>> index b76c38c..2fe5bdb 100644
>> --- a/virt/kvm/arm/vgic.c
>> +++ b/virt/kvm/arm/vgic.c
>> @@ -2474,7 +2474,14 @@ static int vgic_set_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
>>
>> return ret;
>> }
>> -
>> + case KVM_DEV_ARM_VGIC_GRP_CTRL: {
>> + switch (attr->attr) {
>> + case KVM_DEV_ARM_VGIC_CTRL_INIT:
>> + r = kvm_vgic_init(dev->kvm);
>> + return r;
>> + }
>> + break;
>> + }
>> }
>>
>> return -ENXIO;
>> @@ -2553,6 +2560,11 @@ static int vgic_has_attr(struct kvm_device *dev, struct kvm_device_attr *attr)
>> return vgic_has_attr_regs(vgic_cpu_ranges, offset);
>> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>> return 0;
>> + case KVM_DEV_ARM_VGIC_GRP_CTRL:
>> + switch (attr->attr) {
>> + case KVM_DEV_ARM_VGIC_CTRL_INIT:
>> + return 0;
>> + }
>> }
>> return -ENXIO;
>> }
>> --
>> 1.9.1
>>
On 12/04/2014 11:02 AM, Peter Maydell wrote:
> On 2 December 2014 at 17:54, Eric Auger <[email protected]> wrote:
>> as soon as VFIO signaling is set up (the device IRQ index is linked to
>> an eventfd, the physical IRQ VFIO handler is installed and the physical
>> IRQ is enabled at interrupt controller level), virtual IRQs are likely
>> to be injected. With current QEMU code, we setup this VFIO signaling
>> *before* the vgic readiness (either on machine init done or reset
>> notifier) and we face that issue of early injection. QEMU related
>> patches to follow ...
>
> So can you describe in QEMU terms how the lifecycle of these
> things works? How do we ensure that we don't start trying
> to inject VFIO IRQs before we've even created the vgic, for
> instance?
Hi Peter,
Here is the sequence:
1) The VGIC early initialization is initiated in a machine init done
notifier. This notifier is registered in kvm_arm_gic_realize
(http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00220.html). It
executes after vcpu instantiations + dist/cpu interface base address
setting + nb irq setting.
2) the VFIO signaling and irqfd setup is done in a reset notifier
http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg04365.html
Besides https://lkml.org/lkml/2014/12/3/601 now prevents the irqfd setup
if the vgic is not initialized.
QEMU tear down:
in kvm_vm_release, kvm_irqfd_release is called before kvm_vgic_destroy.
This means the irqfd injection is stopped before vgic initialization.
VFIO driver will also will be released by QEMU process, independently on
KVM life cycle. If it still exist while KVM has been released, VFIO
signaling may still be up, meaning eventfd can be signaled but there is
no registered handler anymore, hence no risk of virtual IRQ injection.
Best Regards
Eric
>
> thanks
> -- PMM
>
On 4 December 2014 at 12:01, Eric Auger <[email protected]> wrote:
> Here is the sequence:
> 1) The VGIC early initialization is initiated in a machine init done
> notifier. This notifier is registered in kvm_arm_gic_realize
> (http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00220.html). It
> executes after vcpu instantiations + dist/cpu interface base address
> setting + nb irq setting.
> 2) the VFIO signaling and irqfd setup is done in a reset notifier
> http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg04365.html
OK. And on x86 VFIO how does this work? Obviously x86's GIC just
initializes as soon as it's created, but do we do the irqfd setup
in a reset notifier there too?
thanks
-- PMM
On 12/04/2014 01:07 PM, Peter Maydell wrote:
> On 4 December 2014 at 12:01, Eric Auger <[email protected]> wrote:
>> Here is the sequence:
>> 1) The VGIC early initialization is initiated in a machine init done
>> notifier. This notifier is registered in kvm_arm_gic_realize
>> (http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00220.html). It
>> executes after vcpu instantiations + dist/cpu interface base address
>> setting + nb irq setting.
>> 2) the VFIO signaling and irqfd setup is done in a reset notifier
>> http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg04365.html
>
> OK. And on x86 VFIO how does this work? Obviously x86's GIC just
> initializes as soon as it's created, but do we do the irqfd setup
> in a reset notifier there too?
This is what I understand from PCI intx init sequence: the vfio
signaling and irqfd setup happens in the vfio_initfn function instead.
first vfio signaling with user-side eventfd handlers is setup
(vfio_enable_intx). if KVM is enabled, vfio_enable_intx then tears the
user-side handlers down and replace them by irqfd kernel-side handlers
(IRQFD setup). the virtual IRQ to be injected to the guest is set to
vdev->intx.route.irq. This obviously requires this routing to be set
before the QEMU PCI VFIO device instantiation.
On ARM case, VFIO device are bound to be dynamically instantiated from
command line using dynamic sysbus device instantiation. Binding of IRQ
is done by a platform bus machine init done notifier. Only at that stage
we know the gsi. hence doing the irqfd init in a reset notifier.
Eric
>
> thanks
> -- PMM
>