Message ID | 1458958450-19662-2-git-send-email-andre.przywara@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Sat, Mar 26, 2016 at 02:13:59AM +0000, Andre Przywara wrote: > The ARM GICv3 ITS MSI controller requires a device ID to be able to > assign the proper interrupt vector. On real hardware, this ID is > sampled from the bus. To be able to emulate an ITS controller, extend > the KVM MSI interface to let userspace provide such a device ID. For > PCI devices, the device ID is simply the 16-bit bus-device-function > triplet, which should be easily available to the userland tool. > > Also there is a new KVM capability which advertises whether the > current VM requires a device ID to be set along with the MSI data. > This flag is still reported as not available everywhere, later we will > enable it when ITS emulation is used. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > Reviewed-by: Eric Auger <eric.auger@linaro.org> > --- > Documentation/virtual/kvm/api.txt | 12 ++++++++++-- > include/uapi/linux/kvm.h | 5 ++++- > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index cb2ef0b..8f7351d 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -2163,10 +2163,18 @@ struct kvm_msi { > __u32 address_hi; > __u32 data; > __u32 flags; > - __u8 pad[16]; > + __u32 devid; Are we imposing any unfortunate restrictions for other architectures by using a u32 over a u64 for the device ID? -Christoffer > + __u8 pad[12]; > }; > > -No flags are defined so far. The corresponding field must be 0. > +flags: KVM_MSI_VALID_DEVID: devid contains a valid value > +devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier > + for the device that wrote the MSI message. > + For PCI, this is usually a BFD identifier in the lower 16 bits. > + > +The per-VM KVM_CAP_MSI_DEVID capability advertises the need to provide > +the device ID. If this capability is not set, userland cannot rely on > +the kernel to allow the KVM_MSI_VALID_DEVID flag being set. > > > 4.71 KVM_CREATE_PIT2 > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 50f44a2..6a02871 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -852,6 +852,7 @@ struct kvm_ppc_smmu_info { > #define KVM_CAP_S390_RI 124 > #define KVM_CAP_ARM_PMU_V3 125 > #define KVM_CAP_VCPU_ATTRIBUTES 126 > +#define KVM_CAP_MSI_DEVID 127 > > #ifdef KVM_CAP_IRQ_ROUTING > > @@ -1010,12 +1011,14 @@ struct kvm_one_reg { > __u64 addr; > }; > > +#define KVM_MSI_VALID_DEVID (1U << 0) > struct kvm_msi { > __u32 address_lo; > __u32 address_hi; > __u32 data; > __u32 flags; > - __u8 pad[16]; > + __u32 devid; > + __u8 pad[12]; > }; > > struct kvm_arm_device_addr { > -- > 2.7.3 >
On 3/25/16, 7:13 PM, "kvmarm-bounces@lists.cs.columbia.edu on behalf of Andre Przywara" <kvmarm-bounces@lists.cs.columbia.edu on behalf of andre.przywara@arm.com> wrote: >The ARM GICv3 ITS MSI controller requires a device ID to be able to >assign the proper interrupt vector. On real hardware, this ID is >sampled from the bus. To be able to emulate an ITS controller, extend >the KVM MSI interface to let userspace provide such a device ID. For >PCI devices, the device ID is simply the 16-bit bus-device-function >triplet, which should be easily available to the userland tool. Once VFIO is used it becomes impossible to guess the device ID. Does the VFIO series take care of this? > >Also there is a new KVM capability which advertises whether the >current VM requires a device ID to be set along with the MSI data. >This flag is still reported as not available everywhere, later we will >enable it when ITS emulation is used. > >Signed-off-by: Andre Przywara <andre.przywara@arm.com> >Reviewed-by: Eric Auger <eric.auger@linaro.org> >--- > Documentation/virtual/kvm/api.txt | 12 ++++++++++-- > include/uapi/linux/kvm.h | 5 ++++- > 2 files changed, 14 insertions(+), 3 deletions(-) > >diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >index cb2ef0b..8f7351d 100644 >--- a/Documentation/virtual/kvm/api.txt >+++ b/Documentation/virtual/kvm/api.txt >@@ -2163,10 +2163,18 @@ struct kvm_msi { > __u32 address_hi; > __u32 data; > __u32 flags; >- __u8 pad[16]; >+ __u32 devid; >+ __u8 pad[12]; > }; > >-No flags are defined so far. The corresponding field must be 0. >+flags: KVM_MSI_VALID_DEVID: devid contains a valid value >+devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier >+ for the device that wrote the MSI message. >+ For PCI, this is usually a BFD identifier in the lower 16 bits. >+ >+The per-VM KVM_CAP_MSI_DEVID capability advertises the need to provide >+the device ID. If this capability is not set, userland cannot rely on >+the kernel to allow the KVM_MSI_VALID_DEVID flag being set. > > > 4.71 KVM_CREATE_PIT2 >diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >index 50f44a2..6a02871 100644 >--- a/include/uapi/linux/kvm.h >+++ b/include/uapi/linux/kvm.h >@@ -852,6 +852,7 @@ struct kvm_ppc_smmu_info { > #define KVM_CAP_S390_RI 124 > #define KVM_CAP_ARM_PMU_V3 125 > #define KVM_CAP_VCPU_ATTRIBUTES 126 >+#define KVM_CAP_MSI_DEVID 127 > > #ifdef KVM_CAP_IRQ_ROUTING > >@@ -1010,12 +1011,14 @@ struct kvm_one_reg { > __u64 addr; > }; > >+#define KVM_MSI_VALID_DEVID (1U << 0) > struct kvm_msi { > __u32 address_lo; > __u32 address_hi; > __u32 data; > __u32 flags; >- __u8 pad[16]; >+ __u32 devid; >+ __u8 pad[12]; > }; > > struct kvm_arm_device_addr { >-- >2.7.3 > >_______________________________________________ >kvmarm mailing list >kvmarm@lists.cs.columbia.edu >https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Christoffer, On 03/04/16 10:15, Christoffer Dall wrote: > On Sat, Mar 26, 2016 at 02:13:59AM +0000, Andre Przywara wrote: >> The ARM GICv3 ITS MSI controller requires a device ID to be able to >> assign the proper interrupt vector. On real hardware, this ID is >> sampled from the bus. To be able to emulate an ITS controller, extend >> the KVM MSI interface to let userspace provide such a device ID. For >> PCI devices, the device ID is simply the 16-bit bus-device-function >> triplet, which should be easily available to the userland tool. >> >> Also there is a new KVM capability which advertises whether the >> current VM requires a device ID to be set along with the MSI data. >> This flag is still reported as not available everywhere, later we will >> enable it when ITS emulation is used. >> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >> Reviewed-by: Eric Auger <eric.auger@linaro.org> >> --- >> Documentation/virtual/kvm/api.txt | 12 ++++++++++-- >> include/uapi/linux/kvm.h | 5 ++++- >> 2 files changed, 14 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >> index cb2ef0b..8f7351d 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -2163,10 +2163,18 @@ struct kvm_msi { >> __u32 address_hi; >> __u32 data; >> __u32 flags; >> - __u8 pad[16]; >> + __u32 devid; > > Are we imposing any unfortunate restrictions for other architectures by > using a u32 over a u64 for the device ID? Mmmh, good point. I guess not only for other architectures, but also for the future in general. Are there any objections against increasing this to a u64? Cheers, Andre. >> + __u8 pad[12]; >> }; >> >> -No flags are defined so far. The corresponding field must be 0. >> +flags: KVM_MSI_VALID_DEVID: devid contains a valid value >> +devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier >> + for the device that wrote the MSI message. >> + For PCI, this is usually a BFD identifier in the lower 16 bits. >> + >> +The per-VM KVM_CAP_MSI_DEVID capability advertises the need to provide >> +the device ID. If this capability is not set, userland cannot rely on >> +the kernel to allow the KVM_MSI_VALID_DEVID flag being set. >> >> >> 4.71 KVM_CREATE_PIT2 >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 50f44a2..6a02871 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -852,6 +852,7 @@ struct kvm_ppc_smmu_info { >> #define KVM_CAP_S390_RI 124 >> #define KVM_CAP_ARM_PMU_V3 125 >> #define KVM_CAP_VCPU_ATTRIBUTES 126 >> +#define KVM_CAP_MSI_DEVID 127 >> >> #ifdef KVM_CAP_IRQ_ROUTING >> >> @@ -1010,12 +1011,14 @@ struct kvm_one_reg { >> __u64 addr; >> }; >> >> +#define KVM_MSI_VALID_DEVID (1U << 0) >> struct kvm_msi { >> __u32 address_lo; >> __u32 address_hi; >> __u32 data; >> __u32 flags; >> - __u8 pad[16]; >> + __u32 devid; >> + __u8 pad[12]; >> }; >> >> struct kvm_arm_device_addr { >> -- >> 2.7.3 >> >
On 25/05/16 16:55, Andre Przywara wrote: > Hi Christoffer, > > On 03/04/16 10:15, Christoffer Dall wrote: >> On Sat, Mar 26, 2016 at 02:13:59AM +0000, Andre Przywara wrote: >>> The ARM GICv3 ITS MSI controller requires a device ID to be able to >>> assign the proper interrupt vector. On real hardware, this ID is >>> sampled from the bus. To be able to emulate an ITS controller, extend >>> the KVM MSI interface to let userspace provide such a device ID. For >>> PCI devices, the device ID is simply the 16-bit bus-device-function >>> triplet, which should be easily available to the userland tool. >>> >>> Also there is a new KVM capability which advertises whether the >>> current VM requires a device ID to be set along with the MSI data. >>> This flag is still reported as not available everywhere, later we will >>> enable it when ITS emulation is used. >>> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com> >>> Reviewed-by: Eric Auger <eric.auger@linaro.org> >>> --- >>> Documentation/virtual/kvm/api.txt | 12 ++++++++++-- >>> include/uapi/linux/kvm.h | 5 ++++- >>> 2 files changed, 14 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >>> index cb2ef0b..8f7351d 100644 >>> --- a/Documentation/virtual/kvm/api.txt >>> +++ b/Documentation/virtual/kvm/api.txt >>> @@ -2163,10 +2163,18 @@ struct kvm_msi { >>> __u32 address_hi; >>> __u32 data; >>> __u32 flags; >>> - __u8 pad[16]; >>> + __u32 devid; >> >> Are we imposing any unfortunate restrictions for other architectures by >> using a u32 over a u64 for the device ID? > > Mmmh, good point. I guess not only for other architectures, but also for > the future in general. > > Are there any objections against increasing this to a u64? I'm not sure this is really necessary. A PCI RID is 16bit, and expanding it to 32bit is already making quite a bit of space for further extension. Also, some architecture might be unhappy of having a 64bit quantity that is not 64bit aligned... Thanks, M.
On Wed, May 25, 2016 at 05:16:54PM +0100, Marc Zyngier wrote: > On 25/05/16 16:55, Andre Przywara wrote: > > Hi Christoffer, > > > > On 03/04/16 10:15, Christoffer Dall wrote: > >> On Sat, Mar 26, 2016 at 02:13:59AM +0000, Andre Przywara wrote: > >>> The ARM GICv3 ITS MSI controller requires a device ID to be able to > >>> assign the proper interrupt vector. On real hardware, this ID is > >>> sampled from the bus. To be able to emulate an ITS controller, extend > >>> the KVM MSI interface to let userspace provide such a device ID. For > >>> PCI devices, the device ID is simply the 16-bit bus-device-function > >>> triplet, which should be easily available to the userland tool. > >>> > >>> Also there is a new KVM capability which advertises whether the > >>> current VM requires a device ID to be set along with the MSI data. > >>> This flag is still reported as not available everywhere, later we will > >>> enable it when ITS emulation is used. > >>> > >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com> > >>> Reviewed-by: Eric Auger <eric.auger@linaro.org> > >>> --- > >>> Documentation/virtual/kvm/api.txt | 12 ++++++++++-- > >>> include/uapi/linux/kvm.h | 5 ++++- > >>> 2 files changed, 14 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > >>> index cb2ef0b..8f7351d 100644 > >>> --- a/Documentation/virtual/kvm/api.txt > >>> +++ b/Documentation/virtual/kvm/api.txt > >>> @@ -2163,10 +2163,18 @@ struct kvm_msi { > >>> __u32 address_hi; > >>> __u32 data; > >>> __u32 flags; > >>> - __u8 pad[16]; > >>> + __u32 devid; > >> > >> Are we imposing any unfortunate restrictions for other architectures by > >> using a u32 over a u64 for the device ID? > > > > Mmmh, good point. I guess not only for other architectures, but also for > > the future in general. > > > > Are there any objections against increasing this to a u64? > > I'm not sure this is really necessary. A PCI RID is 16bit, and expanding > it to 32bit is already making quite a bit of space for further extension. > > Also, some architecture might be unhappy of having a 64bit quantity that > is not 64bit aligned... > ok, thanks for the explanation. -Christoffer
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index cb2ef0b..8f7351d 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2163,10 +2163,18 @@ struct kvm_msi { __u32 address_hi; __u32 data; __u32 flags; - __u8 pad[16]; + __u32 devid; + __u8 pad[12]; }; -No flags are defined so far. The corresponding field must be 0. +flags: KVM_MSI_VALID_DEVID: devid contains a valid value +devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier + for the device that wrote the MSI message. + For PCI, this is usually a BFD identifier in the lower 16 bits. + +The per-VM KVM_CAP_MSI_DEVID capability advertises the need to provide +the device ID. If this capability is not set, userland cannot rely on +the kernel to allow the KVM_MSI_VALID_DEVID flag being set. 4.71 KVM_CREATE_PIT2 diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 50f44a2..6a02871 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -852,6 +852,7 @@ struct kvm_ppc_smmu_info { #define KVM_CAP_S390_RI 124 #define KVM_CAP_ARM_PMU_V3 125 #define KVM_CAP_VCPU_ATTRIBUTES 126 +#define KVM_CAP_MSI_DEVID 127 #ifdef KVM_CAP_IRQ_ROUTING @@ -1010,12 +1011,14 @@ struct kvm_one_reg { __u64 addr; }; +#define KVM_MSI_VALID_DEVID (1U << 0) struct kvm_msi { __u32 address_lo; __u32 address_hi; __u32 data; __u32 flags; - __u8 pad[16]; + __u32 devid; + __u8 pad[12]; }; struct kvm_arm_device_addr {