search for: vfio_group_get_device_fd

Version 2 -VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path -VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1 -deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl -VFIO_DEVICE_GET_REGION_INFO-- updated as per AlexW's suggestion, defined 5 new flags and associated structs -VFIO_DEVICE_GET_IRQ_INFO-- updated...

Version 2 -VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path -VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1 -deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl -VFIO_DEVICE_GET_REGION_INFO-- updated as per AlexW's suggestion, defined 5 new flags and associated structs -VFIO_DEVICE_GET_IRQ_INFO-- updated...

...upts. It's up to user space to work out relationships between devices if it needs to-- this can be determined in the device tree exposed in /proc/device-tree. I think the changes needed for vfio are around some of the device tree related info that needs to be available with the device fd. 1. VFIO_GROUP_GET_DEVICE_FD User space has to know which device it is accessing and will call VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to get the device information: fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at 210000"); (whether the path is a device tree...

...upts. It's up to user space to work out relationships between devices if it needs to-- this can be determined in the device tree exposed in /proc/device-tree. I think the changes needed for vfio are around some of the device tree related info that needs to be available with the device fd. 1. VFIO_GROUP_GET_DEVICE_FD User space has to know which device it is accessing and will call VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to get the device information: fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at 210000"); (whether the path is a device tree...

I'm having trouble understanding how this works where the Guest Device Model != Host. How do you inform the guest where the device is mapped in its physical address space, and handle GPA faults? - Mario On 7/3/2013 11:40 PM, Yoder Stuart-B08248 wrote: > Version 2 > -VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path > -VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1 > -deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl > -VFIO_DEVICE_GET_REGION_INFO-- updated as per AlexW's suggestion, > defined 5 new flags and associated structs > -VFIO_DEVIC...

...work out relationships between devices > if it needs to-- this can be determined in the device tree exposed in > /proc/device-tree. > > I think the changes needed for vfio are around some of the device tree > related info that needs to be available with the device fd. > > 1. VFIO_GROUP_GET_DEVICE_FD > > User space has to know which device it is accessing and will call > VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to > get the device information: > > fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at 210000"); > >...

On Wed, 2013-07-03 at 21:40 +0000, Yoder Stuart-B08248 wrote: > Version 2 > -VFIO_GROUP_GET_DEVICE_FD-- specified that the path is a sysfs path > -VFIO_DEVICE_GET_INFO-- defined 2 flags instead of 1 > -deleted VFIO_DEVICE_GET_DEVTREE_INFO ioctl > -VFIO_DEVICE_GET_REGION_INFO-- updated as per AlexW's suggestion, > defined 5 new flags and associated structs > -VFIO_DEVIC...

...work out relationships between devices > if it needs to-- this can be determined in the device tree exposed in > /proc/device-tree. > > I think the changes needed for vfio are around some of the device tree > related info that needs to be available with the device fd. > > 1. VFIO_GROUP_GET_DEVICE_FD > > User space has to know which device it is accessing and will call > VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to > get the device information: > > fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at 210000"); > &...

...ween devices >> if it needs to-- this can be determined in the device tree exposed in >> /proc/device-tree. >> >> I think the changes needed for vfio are around some of the device tree >> related info that needs to be available with the device fd. >> >> 1. VFIO_GROUP_GET_DEVICE_FD >> >> User space has to know which device it is accessing and will call >> VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to >> get the device information: >> >> fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at...

...ween devices >> if it needs to-- this can be determined in the device tree exposed in >> /proc/device-tree. >> >> I think the changes needed for vfio are around some of the device tree >> related info that needs to be available with the device fd. >> >> 1. VFIO_GROUP_GET_DEVICE_FD >> >> User space has to know which device it is accessing and will call >> VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to >> get the device information: >> >> fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "/soc at ffe000000/usb at...

...work out relationships between devices > if it needs to-- this can be determined in the device tree exposed in > /proc/device-tree. > > I think the changes needed for vfio are around some of the device tree > related info that needs to be available with the device fd. > > 1. VFIO_GROUP_GET_DEVICE_FD > > User space has to know which device it is accessing and will call > VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to > get the device information: > > fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, > "/soc at ffe000000/usb at 210000");...

...vices > > if it needs to-- this can be determined in the device tree exposed in > > /proc/device-tree. > > > > I think the changes needed for vfio are around some of the device tree > > related info that needs to be available with the device fd. > > > > 1. VFIO_GROUP_GET_DEVICE_FD > > > > User space has to know which device it is accessing and will call > > VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to > > get the device information: > > > > fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, > > "/soc at f...

...vices > > if it needs to-- this can be determined in the device tree exposed in > > /proc/device-tree. > > > > I think the changes needed for vfio are around some of the device tree > > related info that needs to be available with the device fd. > > > > 1. VFIO_GROUP_GET_DEVICE_FD > > > > User space has to know which device it is accessing and will call > > VFIO_GROUP_GET_DEVICE_FD passing a specific platform device path to > > get the device information: > > > > fd = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, > > "/soc at f...

...; > How do you think? > > > If my understanding is correct, there will be no VFIO ioctl if we go for > vhost_mdev? Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes in /dev similar to what /dev/vfio/* does to handle the $UUID and open the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And to setup the device, we can try to reuse the ioctls of the existing kernel vhost as much as possible. Thanks, Tiwei > > Thanks > > > > > > Thanks, > > Tiwei > > > Thanks > > >

...; > How do you think? > > > If my understanding is correct, there will be no VFIO ioctl if we go for > vhost_mdev? Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes in /dev similar to what /dev/vfio/* does to handle the $UUID and open the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And to setup the device, we can try to reuse the ioctls of the existing kernel vhost as much as possible. Thanks, Tiwei > > Thanks > > > > > > Thanks, > > Tiwei > > > Thanks > > >

...hink? >> >> If my understanding is correct, there will be no VFIO ioctl if we go for >> vhost_mdev? > Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes > in /dev similar to what /dev/vfio/* does to handle the $UUID and open > the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And > to setup the device, we can try to reuse the ioctls of the existing > kernel vhost as much as possible. Interesting, actually, I've considered something similar. I think there should be no issues other than DMA: - Need to invent new API for DMA mapping other than SET_M...

On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote: > On 2019/7/3 ??9:08, Tiwei Bie wrote: > > On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote: > > > On 2019/7/3 ??7:52, Tiwei Bie wrote: > > > > On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote: > > > > > On 2019/7/3 ??5:13, Tiwei Bie wrote: > > > > > >

On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote: > On 2019/7/3 ??9:08, Tiwei Bie wrote: > > On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote: > > > On 2019/7/3 ??7:52, Tiwei Bie wrote: > > > > On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote: > > > > > On 2019/7/3 ??5:13, Tiwei Bie wrote: > > > > > >

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future