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; > > virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; Antonios Motakis; > kvm@xxxxxxxxxxxxxxx list; kvm- > > ppc@xxxxxxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx > > 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
