On 07/16/2013 05:41:04 PM, Yoder Stuart-B08248 wrote:
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 16, 2013 5:01 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Alex Williamson; Alexander Graf; Bhushan
Bharat-R65777; Sethi Varun-B16395;
> virtualizat...@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 that we would normally use
> vfio_pci for the indivdual PCI devices instead)?
>
> You could say the same thing about ranges -- why expose ranges
instead
> of the individual child node regs after translation?
Hmm...yes, I guess ranges and interrupt-map fall into the same
basic type of resource category. I'm not sure it's realistic
to pass entire bus controllers through to user space vs
just individual devices on a bus, but I guess it's theoretically
possible.
Where "theoretically possible" means "we've done it before in other
contexts". :-)
So the question is whether we future proof by adding flags
for both ranges and interrupt-map, or wait until there is
an actual need for it.
We don't need to actually add a flag for it, but we should have a
flag/type for the resources we do support, so that code written to the
current API would recognize that it doesn't recognize an interrupt-map
entry if it's added later.
> > > > __u8 path[]; /* output: Full path to
associated
> > > > device tree node */
> > >
> > > How does the caller know what size buffer to supply for this?
>
> Ping
This is in the v2 RFC... the caller invokes the ioctl which returns
the complete/full size, then re-allocs the buffer and calls the
ioctl again.
OK.
Or, as Alex suggested, just use a sufficiently large buffer to start
with.
It's fine for a user of the API to simplify things by using a large
fixed buffer, but the API shouldn't force that approach.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
