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.

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

Device assignment is as rootish as you get.

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

This is a very good idea.

The interface exposed would be the same as /dev/mem, so any kvm 
modifications to get /dev/mem working would be applicable to /dev/pci/*, no?

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


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

Reply via email to