Anthony Liguori wrote: > Avi Kivity wrote: >> [EMAIL PROTECTED] wrote: >> >>> From: Ben-Ami Yassour <[EMAIL PROTECTED]> >>> >>> Enable a guest to access a device's memory mapped I/O regions directly. >>> Userspace sends the mmio regions that the guest can access. On the >>> first >>> page fault for an access to an mmio address the host translates the >>> gva to hpa, >>> and updates the sptes. >>> >>> >> >> Can you explain why you're not using the regular memory slot >> mechanism? i.e. have userspace mmap(/dev/mem) and create a memslot >> containing that at the appropriate guest physical address? >> > > /dev/mem is often restricted in what memory can be mapped. However, > we can't add something like this to KVM that allows arbitrary HPA's to > be mapped into a guest from userspace. This is just as bad as > /dev/mem and is going to upset a lot of people. > > Regardless of whether we can use /dev/mem, I think we should introduce > a new char device anyway. We only need to mmap() MMIO regions which > are mapped by the PCI bus, presumably, the kernel should know about > these mappings. The driver should only allow mappings that are valid > for a particular PCI device such that it cannot be abused to map > arbitrary regions of memory into a guest. Bonus points if it can > validate that there isn't a valid Linux driver loaded for the given > PCI device.
Which is apparently entirely unnecessary as we already have /sys/bus/pci/.../region. It's just a matter of checking if a vma is VM_IO and then dealing with the subsequent reference counting issues as Avi points out. Regards, Anthony Liguori > Regards, > > Anthony Liguori > >> There are some issues with refcounting, but Andrea has some tricks to >> deal with that. >> >> > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
