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 user
> > just in case, the main thing we need here is to influence what the
> > kernel does when the user tries to map it. At least on PPC it's
> not up
> > to userspace to select whether a mmap is cacheable.
>
> If user space really can't do anything with the 'cacheable'
> flag, do you think there is good reason to keep it? Will it
> help any decision that user space makes? Maybe we should just
> drop it.
As long as we can be sure all architectures will map things correctly
without any flags needing to be specified, that's fine.
> > > struct vfio_path_info {
> > > __u32 argsz;
> > > __u32 flags;
> > > #define VFIO_DEVTREE_INFO_RANGES (1 << 3) /* the region
> is a
> > > "ranges" property */
> >
> > What about distinguishing a normal interrupt from one found in an
> > interrupt-map?
>
> I'm not sure we need that. The kernel needs to use the interrupt
> map to get interrupts hooked up right, but all user space needs to
> know is that there are N interrupts and possibly device tree
> paths to help user space interpret which interrupt is which.
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?
> > In the case of both ranges and interrupt-maps, we'll also want to
> > decide what the policy is for when to expose them directly, versus
> just
> > using them to translate regs and interrupts of child nodes
>
> Yes, not sure the best approach there...but guess we can cross
> that bridge when we implement this. It doesn't affect this
> interface.
It does affect the interface, because if you allow either of them to be
mapped directly (rather than implicitly used when mapping a child
node), you need a way to indicate which type of resource it is you're
describing (as you already do for reg/ranges).
It also affects how vfio device binding is done, even if only to the
point of specifying default behavior in the absence of knobs which
change whether interrupt maps and/or ranges are mapped.
> > > __u8 path[]; /* output: Full path to associated
> > > device tree node */
> >
> > How does the caller know what size buffer to supply for this?
Ping
-Scott
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
