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