RE: [PATCH 3/7] Return info for device and its memory regions and interrupts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Antonios Motakis [mailto:a.motakis@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, October 02, 2013 6:22 AM
> To: Yoder Stuart-B08248
> Cc: Alex Williamson; kvm-arm; Linux IOMMU; Linux Samsung SOC; KVM devel
> mailing list; Alexander Graf; VirtualOpenSystems Technical Team
> Subject: Re: [PATCH 3/7] Return info for device and its memory regions
> and interrupts
> 
> On Tue, Oct 1, 2013 at 9:32 PM, Yoder Stuart-B08248
> <B08248@xxxxxxxxxxxxx> wrote:
> >> Antonios Motakis wrote
> >> > Alex Williamson <alex.williamson@xxxxxxxxxx> wrote:
> >> > I notice all the open firmware calls here and I'm curious,
> >> > will all platform devices be making use of open firmware?
> >> > I don't know if this is synonymous with device tree or not.
> >> > Thanks,
> >>
> >> This VFIO driver will support only devices implemented
> >> on the device tree. While there can be platform devices
> >> outside the device tree, I don't think it makes sense
> >> to support them from the same driver. This is why I
> >> originally called the driver VFIO_DT, however I renamed
> >> it to VFIO_PLATFORM after feedback from the first
> >> RFC. However personally, I still think the VFIO_DT name
> >> is more appropriate since we don't support all platform
> >> devices, only those that use the device tree.
> >
> > But there is no 'device tree' bus.  The bus type we're
> > dealing with is a platform bus.
> >
> > vfio for platform devices should be independent of whether
> > the device was discovered in a device tree or not.
> > All you're doing is exposing mappable regions and IRQs
> > to user space and it does not matter where the info originated.
> >
> > You should be using platform bus structs here not
> > reparsing device tree nodes.  The struct
> > platform_device already has resource info in the
> > struct:
> >
> > struct platform_device {
> >         const char      *name;
> >         u32             id;
> >         struct device   dev;
> >         u32             num_resources;
> >         struct resource *resource;
> > };
> >
> > Stuart
> >
> 
> I will look into this. However, can we rely to have access to all
> device resources through platform abstractions, for every type of
> platform device

The only resources we care about in vfio are mappable regions
and irqs.  So, yes I think we can rely on access to those
resources.

> It seems to me that platform devices that are not
> backed by a specific description mechanism (such as device tree) may
> include a lot of hard coded values etc in their drivers.

If the platform device struct does not have reg/irq resources described
then we can't expose them to user space with vfio.

Stuart

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux