| Message ID | 20230213151348.56451-6-yi.l.liu@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add vfio_device cdev for iommufd support | expand |
On Mon, 13 Feb 2023 07:13:38 -0800 Yi Liu <yi.l.liu@intel.com> wrote: > This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*. > Old userspace uses KVM_DEV_VFIO_GROUP* works as well. > > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > --- > Documentation/virt/kvm/devices/vfio.rst | 45 ++++++++++++++++--------- > include/uapi/linux/kvm.h | 16 ++++++--- > virt/kvm/vfio.c | 16 ++++----- > 3 files changed, 50 insertions(+), 27 deletions(-) > > diff --git a/Documentation/virt/kvm/devices/vfio.rst b/Documentation/virt/kvm/devices/vfio.rst > index 2d20dc561069..90f22933dcfa 100644 > --- a/Documentation/virt/kvm/devices/vfio.rst > +++ b/Documentation/virt/kvm/devices/vfio.rst > @@ -9,24 +9,37 @@ Device types supported: > - KVM_DEV_TYPE_VFIO > > Only one VFIO instance may be created per VM. The created device > -tracks VFIO groups in use by the VM and features of those groups > -important to the correctness and acceleration of the VM. As groups > -are enabled and disabled for use by the VM, KVM should be updated > -about their presence. When registered with KVM, a reference to the > -VFIO-group is held by KVM. > +tracks VFIO files (group or device) in use by the VM and features > +of those groups/devices important to the correctness and acceleration > +of the VM. As groups/devices are enabled and disabled for use by the > +VM, KVM should be updated about their presence. When registered with > +KVM, a reference to the VFIO file is held by KVM. > > Groups: > - KVM_DEV_VFIO_GROUP > - > -KVM_DEV_VFIO_GROUP attributes: > - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking > - kvm_device_attr.addr points to an int32_t file descriptor > - for the VFIO group. > - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking > - kvm_device_attr.addr points to an int32_t file descriptor > - for the VFIO group. > - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table > + KVM_DEV_VFIO_FILE > + alias: KVM_DEV_VFIO_GROUP > + > +KVM_DEV_VFIO_FILE attributes: > + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device > + tracking > + > + alias: KVM_DEV_VFIO_GROUP_ADD > + > + kvm_device_attr.addr points to an int32_t file descriptor for the > + VFIO file. > + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM > + device tracking > + > + alias: KVM_DEV_VFIO_GROUP_DEL > + > + kvm_device_attr.addr points to an int32_t file descriptor for the > + VFIO file. > + > + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table > allocated by sPAPR KVM. > + > + alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE > + > kvm_device_attr.addr points to a struct:: > > struct kvm_vfio_spapr_tce { > @@ -39,3 +52,5 @@ KVM_DEV_VFIO_GROUP attributes: > - @groupfd is a file descriptor for a VFIO group; > - @tablefd is a file descriptor for a TCE table allocated via > KVM_CREATE_SPAPR_TCE. > + > + only accepts vfio group file > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 55155e262646..484a8133bc69 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -1401,10 +1401,18 @@ struct kvm_device_attr { > __u64 addr; /* userspace address of attr data */ > }; > > -#define KVM_DEV_VFIO_GROUP 1 > -#define KVM_DEV_VFIO_GROUP_ADD 1 > -#define KVM_DEV_VFIO_GROUP_DEL 2 > -#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE 3 > +#define KVM_DEV_VFIO_FILE 1 > + > +#define KVM_DEV_VFIO_FILE_ADD 1 > +#define KVM_DEV_VFIO_FILE_DEL 2 > +#define KVM_DEV_VFIO_FILE_SET_SPAPR_TCE 3 > + > +/* KVM_DEV_VFIO_GROUP aliases are for compile time uapi compatibility */ > +#define KVM_DEV_VFIO_GROUP KVM_DEV_VFIO_FILE > + > +#define KVM_DEV_VFIO_GROUP_ADD KVM_DEV_VFIO_FILE_ADD > +#define KVM_DEV_VFIO_GROUP_DEL KVM_DEV_VFIO_FILE_DEL > +#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE KVM_DEV_VFIO_FILE_SET_SPAPR_TCE > > enum kvm_device_type { > KVM_DEV_TYPE_FSL_MPIC_20 = 1, > diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c > index 857d6ba349e1..d869913baafd 100644 > --- a/virt/kvm/vfio.c > +++ b/virt/kvm/vfio.c > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev, long attr, > int32_t fd; > > switch (attr) { > - case KVM_DEV_VFIO_GROUP_ADD: > + case KVM_DEV_VFIO_FILE_ADD: > if (get_user(fd, argp)) > return -EFAULT; > return kvm_vfio_file_add(dev, fd); > > - case KVM_DEV_VFIO_GROUP_DEL: > + case KVM_DEV_VFIO_FILE_DEL: > if (get_user(fd, argp)) > return -EFAULT; > return kvm_vfio_file_del(dev, fd); > > #ifdef CONFIG_SPAPR_TCE_IOMMU > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: > return kvm_vfio_file_set_spapr_tce(dev, arg); I don't see that the SPAPR code is so easily fungible to a device file descriptor. The kvm_vfio_spapr_tce data structure includes a groupfd, which is required to match a groupfd on the file_list. So a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use this TCE code. Maybe SPAPR code is therefore tied to the group interface since there's nobody around advancing this code any longer. That also makes me wonder what we're really gaining in forcing this generalization from group to file. There's no userspace that's suddenly going to find itself with a device cdev to require an ABI compatible interface. So we allow either groups or cdevs, but then we potentially end up with a file_list of both groups and device cdevs. Given the SPAPR issue above, is there some advantage to creating a parallel FILE interface alongside the GROUP interface, with separate file lists for each? At least that would allow SPAPR to expose only a GROUP interface via the has_attr interface below. Maybe there's some utility in general for being able to probe device cdev support here? Thanks, Alex > #endif > } > @@ -309,7 +309,7 @@ static int kvm_vfio_set_attr(struct kvm_device *dev, > struct kvm_device_attr *attr) > { > switch (attr->group) { > - case KVM_DEV_VFIO_GROUP: > + case KVM_DEV_VFIO_FILE: > return kvm_vfio_set_file(dev, attr->attr, > u64_to_user_ptr(attr->addr)); > } > @@ -321,12 +321,12 @@ static int kvm_vfio_has_attr(struct kvm_device *dev, > struct kvm_device_attr *attr) > { > switch (attr->group) { > - case KVM_DEV_VFIO_GROUP: > + case KVM_DEV_VFIO_FILE: > switch (attr->attr) { > - case KVM_DEV_VFIO_GROUP_ADD: > - case KVM_DEV_VFIO_GROUP_DEL: > + case KVM_DEV_VFIO_FILE_ADD: > + case KVM_DEV_VFIO_FILE_DEL: > #ifdef CONFIG_SPAPR_TCE_IOMMU > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: > #endif > return 0; > }
On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote: > > index 857d6ba349e1..d869913baafd 100644 > > --- a/virt/kvm/vfio.c > > +++ b/virt/kvm/vfio.c > > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev, long attr, > > int32_t fd; > > > > switch (attr) { > > - case KVM_DEV_VFIO_GROUP_ADD: > > + case KVM_DEV_VFIO_FILE_ADD: > > if (get_user(fd, argp)) > > return -EFAULT; > > return kvm_vfio_file_add(dev, fd); > > > > - case KVM_DEV_VFIO_GROUP_DEL: > > + case KVM_DEV_VFIO_FILE_DEL: > > if (get_user(fd, argp)) > > return -EFAULT; > > return kvm_vfio_file_del(dev, fd); > > > > #ifdef CONFIG_SPAPR_TCE_IOMMU > > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: > > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: > > return kvm_vfio_file_set_spapr_tce(dev, arg); > > I don't see that the SPAPR code is so easily fungible to a device > file descriptor. The kvm_vfio_spapr_tce data structure includes a > groupfd, which is required to match a groupfd on the file_list. So > a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use > this TCE code. SPAPR cannot use cdev at all, cdev mode only works with iommufd. So with my other remark about blocking unbound cdevs, in SPAPR mode you can never open a cdev and make it bound thus kvm_vfio_file_iommu_group() and others will return NULL always for cdev. Thus AFAICT this is all fine. Yi, you should also add some kconfig stuff to ensure that SPAPR always has the group interface compiled in. > That also makes me wonder what we're really gaining in forcing this > generalization from group to file. I think it is just less code overall. Otherwise we need to needlessly double quite a lot of stuff, rather pointlessly, IMHO. I'm still thinking about proposing to just delete all this SPAPR stuff. Power still hasn't had the patches applied to make it work again so it seems to all be dead. Jason
On Tue, 14 Feb 2023 19:25:19 -0400 Jason Gunthorpe <jgg@nvidia.com> wrote: > On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote: > > > index 857d6ba349e1..d869913baafd 100644 > > > --- a/virt/kvm/vfio.c > > > +++ b/virt/kvm/vfio.c > > > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev, long attr, > > > int32_t fd; > > > > > > switch (attr) { > > > - case KVM_DEV_VFIO_GROUP_ADD: > > > + case KVM_DEV_VFIO_FILE_ADD: > > > if (get_user(fd, argp)) > > > return -EFAULT; > > > return kvm_vfio_file_add(dev, fd); > > > > > > - case KVM_DEV_VFIO_GROUP_DEL: > > > + case KVM_DEV_VFIO_FILE_DEL: > > > if (get_user(fd, argp)) > > > return -EFAULT; > > > return kvm_vfio_file_del(dev, fd); > > > > > > #ifdef CONFIG_SPAPR_TCE_IOMMU > > > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: > > > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: > > > return kvm_vfio_file_set_spapr_tce(dev, arg); > > > > I don't see that the SPAPR code is so easily fungible to a device > > file descriptor. The kvm_vfio_spapr_tce data structure includes a > > groupfd, which is required to match a groupfd on the file_list. So > > a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use > > this TCE code. > > SPAPR cannot use cdev at all, cdev mode only works with iommufd. > > So with my other remark about blocking unbound cdevs, in SPAPR mode > you can never open a cdev and make it bound thus > kvm_vfio_file_iommu_group() and others will return NULL always for > cdev. > > Thus AFAICT this is all fine. A device file opened through a group could be passed through this interface though, right? Do we just chalk that up to user error? Maybe the SPAPR extension at least needs to be documented as relying on registering groups rather than devices. > Yi, you should also add some kconfig stuff to ensure that SPAPR always > has the group interface compiled in. > > > That also makes me wonder what we're really gaining in forcing this > > generalization from group to file. > > I think it is just less code overall. Otherwise we need to needlessly > double quite a lot of stuff, rather pointlessly, IMHO. > > I'm still thinking about proposing to just delete all this SPAPR > stuff. Power still hasn't had the patches applied to make it work > again so it seems to all be dead. There's been some off-list discussion about at least fixing SPAPR support, but yes, it either needs to get some love or we ought to think about its future. Thanks, Alex
On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > A device file opened through a group could be passed through this > interface though, right? Yes, I think so > Do we just chalk that up to user error? Maybe the SPAPR extension > at least needs to be documented as relying on registering groups > rather than devices. The way these APIs work is you have to pass the same FD to all of them. The SPAPR stuff is no different, if you used a cdev with KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd with the SPAPR group_fd. Yi just didn't rename it. It is weird, but logically self consistent, I think. > > I'm still thinking about proposing to just delete all this SPAPR > > stuff. Power still hasn't had the patches applied to make it work > > again so it seems to all be dead. > > There's been some off-list discussion about at least fixing SPAPR > support, but yes, it either needs to get some love or we ought to think > about its future. Thanks, The patches exist, they just need to be applied AFAIK. If the people responsible can't care enough about this to even do that then I find it hard to care at all about the state of SPAPR. Jason
----- Original Message ----- > From: "Jason Gunthorpe" <jgg@nvidia.com> > To: "Alex Williamson" <alex.williamson@redhat.com> > Cc: "Yi Liu" <yi.l.liu@intel.com>, joro@8bytes.org, "kevin tian" <kevin.tian@intel.com>, "robin murphy" > <robin.murphy@arm.com>, cohuck@redhat.com, "eric auger" <eric.auger@redhat.com>, nicolinc@nvidia.com, "kvm" > <kvm@vger.kernel.org>, mjrosato@linux.ibm.com, "chao p peng" <chao.p.peng@linux.intel.com>, "yi y sun" > <yi.y.sun@linux.intel.com>, peterx@redhat.com, jasowang@redhat.com, "shameerali kolothum thodi" > <shameerali.kolothum.thodi@huawei.com>, lulu@redhat.com, "suravee suthikulpanit" <suravee.suthikulpanit@amd.com>, > intel-gvt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, "linux-s390" <linux-s390@vger.kernel.org>, > "Timothy Pearson" <tpearson@raptorengineering.com>, "Michael Ellerman" <mpe@ellerman.id.au> > Sent: Tuesday, February 14, 2023 6:17:46 PM > Subject: Re: [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace > On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > >> A device file opened through a group could be passed through this >> interface though, right? > > Yes, I think so > >> Do we just chalk that up to user error? Maybe the SPAPR extension >> at least needs to be documented as relying on registering groups >> rather than devices. > > The way these APIs work is you have to pass the same FD to all of > them. The SPAPR stuff is no different, if you used a cdev with > KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd with the > SPAPR group_fd. Yi just didn't rename it. > > It is weird, but logically self consistent, I think. > >> > I'm still thinking about proposing to just delete all this SPAPR >> > stuff. Power still hasn't had the patches applied to make it work >> > again so it seems to all be dead. >> >> There's been some off-list discussion about at least fixing SPAPR >> support, but yes, it either needs to get some love or we ought to think >> about its future. Thanks, > > The patches exist, they just need to be applied AFAIK. If the people > responsible can't care enough about this to even do that then I find > it hard to care at all about the state of SPAPR. > > Jason I've been discussing the state of the patches offline, apologies for the delay in checking in here. I'll be taking over SPAPR support going forward, as we need it for our product line. My current thoughts are to rebase / fix and test the patches that were already generated, to at least get support reenabled, then we can coordinate on further changes needed to maintain the support going forward. I should have a rebased patchset ready later this week. Thank you!
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Wednesday, February 15, 2023 7:25 AM > > On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote: > > > index 857d6ba349e1..d869913baafd 100644 > > > --- a/virt/kvm/vfio.c > > > +++ b/virt/kvm/vfio.c > > > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device > *dev, long attr, > > > int32_t fd; > > > > > > switch (attr) { > > > - case KVM_DEV_VFIO_GROUP_ADD: > > > + case KVM_DEV_VFIO_FILE_ADD: > > > if (get_user(fd, argp)) > > > return -EFAULT; > > > return kvm_vfio_file_add(dev, fd); > > > > > > - case KVM_DEV_VFIO_GROUP_DEL: > > > + case KVM_DEV_VFIO_FILE_DEL: > > > if (get_user(fd, argp)) > > > return -EFAULT; > > > return kvm_vfio_file_del(dev, fd); > > > > > > #ifdef CONFIG_SPAPR_TCE_IOMMU > > > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: > > > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: > > > return kvm_vfio_file_set_spapr_tce(dev, arg); > > > > I don't see that the SPAPR code is so easily fungible to a device > > file descriptor. The kvm_vfio_spapr_tce data structure includes a > > groupfd, which is required to match a groupfd on the file_list. So > > a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use > > this TCE code. > > SPAPR cannot use cdev at all, cdev mode only works with iommufd. > > So with my other remark about blocking unbound cdevs, in SPAPR mode > you can never open a cdev and make it bound thus > kvm_vfio_file_iommu_group() and others will return NULL always for > cdev. > > Thus AFAICT this is all fine. > > Yi, you should also add some kconfig stuff to ensure that SPAPR always > has the group interface compiled in. Ok. I can make VFIO to select VFIO_GROUP for SPAPR. Regards, Yi Liu
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Wednesday, February 15, 2023 8:18 AM > > On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > > > A device file opened through a group could be passed through this > > interface though, right? > > Yes, I think so > > > Do we just chalk that up to user error? Maybe the SPAPR extension > > at least needs to be documented as relying on registering groups > > rather than devices. > > The way these APIs work is you have to pass the same FD to all of > them. The SPAPR stuff is no different, if you used a cdev with > KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd with > the > SPAPR group_fd. Yi just didn't rename it. This is because SPAPR cannot accept cdev fd yet. It explicitly requires group fd and get iommu_group during the handling. Regards, Yi Liu
> From: Liu, Yi L <yi.l.liu@intel.com> > Sent: Friday, February 17, 2023 1:34 PM > > > From: Jason Gunthorpe <jgg@nvidia.com> > > Sent: Wednesday, February 15, 2023 8:18 AM > > > > On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > > > > > A device file opened through a group could be passed through this > > > interface though, right? > > > > Yes, I think so > > > > > Do we just chalk that up to user error? Maybe the SPAPR extension > > > at least needs to be documented as relying on registering groups > > > rather than devices. > > > > The way these APIs work is you have to pass the same FD to all of > > them. The SPAPR stuff is no different, if you used a cdev with > > KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd > with > > the > > SPAPR group_fd. Yi just didn't rename it. > > This is because SPAPR cannot accept cdev fd yet. It explicitly requires > group fd and get iommu_group during the handling. Sorry I misunderstood it. I think this can be renamed to be fds if no objection. Maybe as below, so that old userspace that uses group_fds can still compile. I doubt if a new flag is needed to identify the provided fds are group or device fds. I guess no since the pci hot reset code does not really care about it. It cares more the fd is held by the application. struct vfio_pci_hot_reset { __u32 argsz; __u32 flags; __u32 count; union { __s32 group_fds[]; __s32 fds[]; }; }; Regards, Yi Liu
On Fri, Feb 17, 2023 at 05:48:57AM +0000, Liu, Yi L wrote: > > From: Liu, Yi L <yi.l.liu@intel.com> > > Sent: Friday, February 17, 2023 1:34 PM > > > > > From: Jason Gunthorpe <jgg@nvidia.com> > > > Sent: Wednesday, February 15, 2023 8:18 AM > > > > > > On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > > > > > > > A device file opened through a group could be passed through this > > > > interface though, right? > > > > > > Yes, I think so > > > > > > > Do we just chalk that up to user error? Maybe the SPAPR extension > > > > at least needs to be documented as relying on registering groups > > > > rather than devices. > > > > > > The way these APIs work is you have to pass the same FD to all of > > > them. The SPAPR stuff is no different, if you used a cdev with > > > KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd > > with > > > the > > > SPAPR group_fd. Yi just didn't rename it. > > > > This is because SPAPR cannot accept cdev fd yet. It explicitly requires > > group fd and get iommu_group during the handling. > > Sorry I misunderstood it. I think this can be renamed to be fds if > no objection. Maybe as below, so that old userspace that uses > group_fds can still compile. I doubt if a new flag is needed to > identify the provided fds are group or device fds. I guess no since > the pci hot reset code does not really care about it. It cares more > the fd is held by the application. I wouldn't change it, even though it does work like this spapr requires the group fd because it doesn't work with iommufd. No sense in confusing things. Jason
diff --git a/Documentation/virt/kvm/devices/vfio.rst b/Documentation/virt/kvm/devices/vfio.rst index 2d20dc561069..90f22933dcfa 100644 --- a/Documentation/virt/kvm/devices/vfio.rst +++ b/Documentation/virt/kvm/devices/vfio.rst @@ -9,24 +9,37 @@ Device types supported: - KVM_DEV_TYPE_VFIO Only one VFIO instance may be created per VM. The created device -tracks VFIO groups in use by the VM and features of those groups -important to the correctness and acceleration of the VM. As groups -are enabled and disabled for use by the VM, KVM should be updated -about their presence. When registered with KVM, a reference to the -VFIO-group is held by KVM. +tracks VFIO files (group or device) in use by the VM and features +of those groups/devices important to the correctness and acceleration +of the VM. As groups/devices are enabled and disabled for use by the +VM, KVM should be updated about their presence. When registered with +KVM, a reference to the VFIO file is held by KVM. Groups: - KVM_DEV_VFIO_GROUP - -KVM_DEV_VFIO_GROUP attributes: - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking - kvm_device_attr.addr points to an int32_t file descriptor - for the VFIO group. - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking - kvm_device_attr.addr points to an int32_t file descriptor - for the VFIO group. - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table + KVM_DEV_VFIO_FILE + alias: KVM_DEV_VFIO_GROUP + +KVM_DEV_VFIO_FILE attributes: + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device + tracking + + alias: KVM_DEV_VFIO_GROUP_ADD + + kvm_device_attr.addr points to an int32_t file descriptor for the + VFIO file. + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM + device tracking + + alias: KVM_DEV_VFIO_GROUP_DEL + + kvm_device_attr.addr points to an int32_t file descriptor for the + VFIO file. + + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table allocated by sPAPR KVM. + + alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE + kvm_device_attr.addr points to a struct:: struct kvm_vfio_spapr_tce { @@ -39,3 +52,5 @@ KVM_DEV_VFIO_GROUP attributes: - @groupfd is a file descriptor for a VFIO group; - @tablefd is a file descriptor for a TCE table allocated via KVM_CREATE_SPAPR_TCE. + + only accepts vfio group file diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 55155e262646..484a8133bc69 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1401,10 +1401,18 @@ struct kvm_device_attr { __u64 addr; /* userspace address of attr data */ }; -#define KVM_DEV_VFIO_GROUP 1 -#define KVM_DEV_VFIO_GROUP_ADD 1 -#define KVM_DEV_VFIO_GROUP_DEL 2 -#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE 3 +#define KVM_DEV_VFIO_FILE 1 + +#define KVM_DEV_VFIO_FILE_ADD 1 +#define KVM_DEV_VFIO_FILE_DEL 2 +#define KVM_DEV_VFIO_FILE_SET_SPAPR_TCE 3 + +/* KVM_DEV_VFIO_GROUP aliases are for compile time uapi compatibility */ +#define KVM_DEV_VFIO_GROUP KVM_DEV_VFIO_FILE + +#define KVM_DEV_VFIO_GROUP_ADD KVM_DEV_VFIO_FILE_ADD +#define KVM_DEV_VFIO_GROUP_DEL KVM_DEV_VFIO_FILE_DEL +#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE KVM_DEV_VFIO_FILE_SET_SPAPR_TCE enum kvm_device_type { KVM_DEV_TYPE_FSL_MPIC_20 = 1, diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c index 857d6ba349e1..d869913baafd 100644 --- a/virt/kvm/vfio.c +++ b/virt/kvm/vfio.c @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev, long attr, int32_t fd; switch (attr) { - case KVM_DEV_VFIO_GROUP_ADD: + case KVM_DEV_VFIO_FILE_ADD: if (get_user(fd, argp)) return -EFAULT; return kvm_vfio_file_add(dev, fd); - case KVM_DEV_VFIO_GROUP_DEL: + case KVM_DEV_VFIO_FILE_DEL: if (get_user(fd, argp)) return -EFAULT; return kvm_vfio_file_del(dev, fd); #ifdef CONFIG_SPAPR_TCE_IOMMU - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: return kvm_vfio_file_set_spapr_tce(dev, arg); #endif } @@ -309,7 +309,7 @@ static int kvm_vfio_set_attr(struct kvm_device *dev, struct kvm_device_attr *attr) { switch (attr->group) { - case KVM_DEV_VFIO_GROUP: + case KVM_DEV_VFIO_FILE: return kvm_vfio_set_file(dev, attr->attr, u64_to_user_ptr(attr->addr)); } @@ -321,12 +321,12 @@ static int kvm_vfio_has_attr(struct kvm_device *dev, struct kvm_device_attr *attr) { switch (attr->group) { - case KVM_DEV_VFIO_GROUP: + case KVM_DEV_VFIO_FILE: switch (attr->attr) { - case KVM_DEV_VFIO_GROUP_ADD: - case KVM_DEV_VFIO_GROUP_DEL: + case KVM_DEV_VFIO_FILE_ADD: + case KVM_DEV_VFIO_FILE_DEL: #ifdef CONFIG_SPAPR_TCE_IOMMU - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: #endif return 0; }
This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*. Old userspace uses KVM_DEV_VFIO_GROUP* works as well. Signed-off-by: Yi Liu <yi.l.liu@intel.com> --- Documentation/virt/kvm/devices/vfio.rst | 45 ++++++++++++++++--------- include/uapi/linux/kvm.h | 16 ++++++--- virt/kvm/vfio.c | 16 ++++----- 3 files changed, 50 insertions(+), 27 deletions(-)