Linux Virtualization - Jul 2013 - RFC: vfio interface for platform devices

On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
> 
> On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
> 
> > 8.  Open Issues
> >
> >   -how to handle cases where VFIO is requested to handle
> >    a device where the valid, mappable range for a region
> >    is less than a page size.   See example above where an
> >    advertised region in the DMA node is 4 bytes.  If exposed
> >    to a guest VM, the guest has to be able to map a full page
> >    of I/O space which opens a potential security issue.
> 
> The way we solved this for legacy PCI device assignment was by going  
> through QEMU for emulation and falling back to legacy read/write  
> IIRC. We could probably do the same here. IIRC there was a way for a  
> normal Linux mmap'ed device region to trap individual accesses too,  
> so we could just use that one too.
> 
> The slow path emulation would then happen magically in QEMU, since  
> MMIO writes will get reinjected into the normal QEMU MMIO handling  
> path which will just issue a read/write on the mmap'ed region if
it's
> not declared as emulated.
I agree that's what should happen by default, but there should be a way  
for root to tell vfio that a device is allowed to overmap, in order to  
get the performance benefit of direct access in cases where root knows  
(or explicitly doesn't care) that it is safe.

-Scott

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, July 03, 2013 1:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Alex Williamson; Wood Scott-B07421; Bhushan
Bharat-R65777; Sethi Varun-B16395;
> virtualization at lists.linux-foundation.org; Antonios Motakis; kvm at
vger.kernel.org list; kvm-
> ppc at vger.kernel.org; kvmarm at lists.cs.columbia.edu
> Subject: Re: RFC: vfio interface for platform devices
> 
> On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
> >
> > On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
> >
> > > 8.  Open Issues
> > >
> > >   -how to handle cases where VFIO is requested to handle
> > >    a device where the valid, mappable range for a region
> > >    is less than a page size.   See example above where an
> > >    advertised region in the DMA node is 4 bytes.  If exposed
> > >    to a guest VM, the guest has to be able to map a full page
> > >    of I/O space which opens a potential security issue.
> >
> > The way we solved this for legacy PCI device assignment was by going
> > through QEMU for emulation and falling back to legacy read/write
> > IIRC. We could probably do the same here. IIRC there was a way for a
> > normal Linux mmap'ed device region to trap individual accesses
too,
> > so we could just use that one too.
> >
> > The slow path emulation would then happen magically in QEMU, since
> > MMIO writes will get reinjected into the normal QEMU MMIO handling
> > path which will just issue a read/write on the mmap'ed region if
it's
> > not declared as emulated.
> 
> I agree that's what should happen by default, but there should be a way
> for root to tell vfio that a device is allowed to overmap, in order to
> get the performance benefit of direct access in cases where root knows
> (or explicitly doesn't care) that it is safe.
Perhaps a sysfs mechanism like this:

echo "/sys/bus/platform/devices/ffe210000.usb" >
/sys/bus/platform/drivers/vfio-platform/allow_overmap

Stuart