> -----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; > virtualizat...@lists.linux-foundation.org; Antonios Motakis; > k...@vger.kernel.org list; kvm- > p...@vger.kernel.org; kvm...@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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
