...@lists.linux-foundation.org; Sethi
Varun-B16395;
kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices (v2)
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
@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
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
(sorry for the delayed response, but I've been on PTO)
1. VFIO_GROUP_GET_DEVICE_FD
User space knows by out-of-band means which device it is accessing
and will call VFIO_GROUP_GET_DEVICE_FD passing a specific sysfs path
to get the device information:
fd = ioctl(group,
On 07/16/2013 04:51:12 PM, Yoder Stuart-B08248 wrote:
3. VFIO_DEVICE_GET_REGION_INFO
No changes needed, except perhaps adding a new flag. Freescale
has some
devices with regions that must be mapped cacheable.
While I don't object to making the information available to the
@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
On 07/16/2013 04:51:12 PM, Yoder Stuart-B08248 wrote:
3. VFIO_DEVICE_GET_REGION_INFO
No changes needed, except perhaps adding a new flag. Freescale
has
...@lists.linux-foundation.org; Antonios Motakis;
kvm@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
What if the interrupt map is for devices without explicit nodes,
such
as with a PCI controller (ignore the fact
...@lists.linux-foundation.org; Sethi
Varun-B16395;
kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices (v2)
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
...@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
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
(sorry for the delayed response, but I've been on PTO)
1. VFIO_GROUP_GET_DEVICE_FD
User space knows by out-of-band means which device it is accessing
and will call VFIO_GROUP_GET_DEVICE_FD passing a specific sysfs path
to get the device information:
fd = ioctl(group,
On 07/16/2013 04:51:12 PM, Yoder Stuart-B08248 wrote:
3. VFIO_DEVICE_GET_REGION_INFO
No changes needed, except perhaps adding a new flag. Freescale
has some
devices with regions that must be mapped cacheable.
While I don't object to making the information available to the
...@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
On 07/16/2013 04:51:12 PM, Yoder Stuart-B08248 wrote:
3. VFIO_DEVICE_GET_REGION_INFO
No changes needed, except perhaps adding a new flag. Freescale
has
...@lists.linux-foundation.org; Antonios Motakis;
k...@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
What if the interrupt map is for devices without explicit nodes,
such
as with a PCI controller (ignore the fact
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--
On 04.07.2013, at 16:44, Mario Smarduch wrote:
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?
The same way as you would for emulated devices.
On 04.07.2013, at 16:44, Mario Smarduch wrote:
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?
The same way as you would for emulated devices.
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--
On Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson
alex.william...@redhat.com wrote:
On Tue, 2013-07-02 at 23: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
[cut]
So overall the interface and extension makes sense. My only question is
whether it's better to get complete reuse out of GET_REGION_INFO and
GET_IRQ_INFO and then add another device tree specific ioctl or is it
better to add a device tree index and path to the existing GET_*_INFO
On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
8. Open Issues
-how to handle cases where VFIO is requested to handle
a device where the valid, mappable range for a region
is less than a page size. See example above where an
@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
8. Open Issues
-how to handle cases where VFIO
[cut]
So overall the interface and extension makes sense. My only question is
whether it's better to get complete reuse out of GET_REGION_INFO and
GET_IRQ_INFO and then add another device tree specific ioctl or is it
better to add a device tree index and path to the existing GET_*_INFO
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
On Wed, 2013-07-03 at 21:40 +, 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
On 07/03/2013 05:53:09 PM, Alex Williamson wrote:
Seems like it should work. My only API concern with this model of
appending structs is that a user needs to know the size of each struct
even if they don't otherwise care about it in order to step over it.
In that case, it might be better to
On Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson
alex.william...@redhat.com wrote:
On Tue, 2013-07-02 at 23: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
[cut]
So overall the interface and extension makes sense. My only question is
whether it's better to get complete reuse out of GET_REGION_INFO and
GET_IRQ_INFO and then add another device tree specific ioctl or is it
better to add a device tree index and path to the existing GET_*_INFO
On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
8. Open Issues
-how to handle cases where VFIO is requested to handle
a device where the valid, mappable range for a region
is less than a page size. See example above where an
...@vger.kernel.org list; kvm-
p...@vger.kernel.org; kvm...@lists.cs.columbia.edu
Subject: Re: RFC: vfio interface for platform devices
On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
8. Open Issues
-how to handle cases where VFIO
[cut]
So overall the interface and extension makes sense. My only question is
whether it's better to get complete reuse out of GET_REGION_INFO and
GET_IRQ_INFO and then add another device tree specific ioctl or is it
better to add a device tree index and path to the existing GET_*_INFO
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
On Wed, 2013-07-03 at 21:40 +, 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
On 07/03/2013 05:53:09 PM, Alex Williamson wrote:
Seems like it should work. My only API concern with this model of
appending structs is that a user needs to know the size of each struct
even if they don't otherwise care about it in order to step over it.
In that case, it might be better to
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
On Tue, 2013-07-02 at 23: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
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
On Tue, 2013-07-02 at 23: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
36 matches
Mail list logo
