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
--
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
