;
> virtualizat...@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,
su
ntonios Motakis;
> k...@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
> > > &g
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
(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(
ntonios Motakis;
> k...@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
m-ppc@vger.kernel.org; virtualizat...@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. Ho
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 devi
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 ma
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 pe
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 i
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
-V
[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_*_
ntonios Motakis;
> k...@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:
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
[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 Wed, Jul 3, 2013 at 5:07 AM, Alex Williamson
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 proposing a new ioctl VF
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 correl
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 regi
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
20 matches
Mail list logo
