On Tue, Apr 01, 2008 at 08:03:14PM +0300, Avi Kivity wrote: > 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. > > Please elaborate.
The /dev/mem, /dev/kmem devices have a special SELinux context memory_device_t and very few application domains are allowed to access them. THe KVM/QEMU policy will not allow this for example. Basically on the X server, HAL and dmidecode have access in current policy. It would be undesirable to have to all KVM guests full access to /dev/mem, so a more fine grained access method would have benefits here. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| ------------------------------------------------------------------------- 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