similar to: RFC: vfio interface for platform devices

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 as per AlexW's suggestion, defined 1 new flag and

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 as per AlexW's suggestion, defined 1 new flag and

On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote: > The write-up below is the first draft of a proposal for how the kernel can expose > platform devices to user space using vfio. > > In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which > allows user space to correlate regions and interrupts to the corresponding > device tree node structure that is

On Tue, 2013-07-02 at 23:25 +0000, Yoder Stuart-B08248 wrote: > The write-up below is the first draft of a proposal for how the kernel can expose > platform devices to user space using vfio. > > In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which > allows user space to correlate regions and interrupts to the corresponding > device tree node structure that

On Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson <alex.williamson at redhat.com> wrote: > On Tue, 2013-07-02 at 23:25 +0000, Yoder Stuart-B08248 wrote: >> The write-up below is the first draft of a proposal for how the kernel can expose >> platform devices to user space using vfio. >> >> In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which

On Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson <alex.williamson at redhat.com> wrote: > On Tue, 2013-07-02 at 23:25 +0000, Yoder Stuart-B08248 wrote: >> The write-up below is the first draft of a proposal for how the kernel can expose >> platform devices to user space using vfio. >> >> In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which

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

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 >

> -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, July 03, 2013 5:32 PM > To: Yoder Stuart-B08248 > Cc: Alex Williamson; Alexander Graf; Wood Scott-B07421; Bhushan Bharat-R65777; Sethi Varun-B16395; > virtualization at lists.linux-foundation.org; Antonios Motakis; kvm at vger.kernel.org list; kvm- > ppc at vger.kernel.org; kvmarm at

> -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, July 03, 2013 5:32 PM > To: Yoder Stuart-B08248 > Cc: Alex Williamson; Alexander Graf; Wood Scott-B07421; Bhushan Bharat-R65777; Sethi Varun-B16395; > virtualization at lists.linux-foundation.org; Antonios Motakis; kvm at vger.kernel.org list; kvm- > ppc at vger.kernel.org; kvmarm at

On 07/02/2013 06:25:59 PM, Yoder Stuart-B08248 wrote: > The write-up below is the first draft of a proposal for how the > kernel can expose > platform devices to user space using vfio. > > In short, I'm proposing a new ioctl VFIO_DEVICE_GET_DEVTREE_INFO which > allows user space to correlate regions and interrupts to the > corresponding > device tree node structure

On Wed, Aug 28, 2019 at 01:37:12PM +0800, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > > > #1. We expose a VFIO device, so we can reuse the VFIO container/group > > based

On Wed, Aug 28, 2019 at 01:37:12PM +0800, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > > > #1. We expose a VFIO device, so we can reuse the VFIO container/group > > based

Details about this can be found here: https://lwn.net/Articles/750770/ What's new in this version ========================== A new VFIO device type is introduced - vfio-vhost. This addressed some comments from here: https://patchwork.ozlabs.org/cover/984763/ Below is the updated device interface: Currently, there are two regions of this device: 1) CONFIG_REGION

Details about this can be found here: https://lwn.net/Articles/750770/ What's new in this version ========================== A new VFIO device type is introduced - vfio-vhost. This addressed some comments from here: https://patchwork.ozlabs.org/cover/984763/ Below is the updated device interface: Currently, there are two regions of this device: 1) CONFIG_REGION

On 2019/8/28 ??1:37, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > >> #1. We expose a VFIO device, so we can reuse the VFIO container/group >> based DMA API and potentially

On 2019/8/28 ??1:37, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > >> #1. We expose a VFIO device, so we can reuse the VFIO container/group >> based DMA API and potentially

On Tue, Sep 03, 2019 at 07:26:03AM -0400, Michael S. Tsirkin wrote: > On Wed, Aug 28, 2019 at 01:37:12PM +0800, Tiwei Bie wrote: > > Details about this can be found here: > > > > https://lwn.net/Articles/750770/ > > > > What's new in this version > > ========================== > > > > There are three choices based on the discussion [1] in

This patch introduces a mdev (mediated device) based hardware vhost backend. This backend is an abstraction of the various hardware vhost accelerators (potentially any device that uses virtio ring can be used as a vhost accelerator). Some generic mdev parent ops are provided for accelerator drivers to support generating mdev instances. What's this =========== The idea is that we can setup a

This patch introduces a mdev (mediated device) based hardware vhost backend. This backend is an abstraction of the various hardware vhost accelerators (potentially any device that uses virtio ring can be used as a vhost accelerator). Some generic mdev parent ops are provided for accelerator drivers to support generating mdev instances. What's this =========== The idea is that we can setup a