Re: [PATCH 1/1] direct mmio for passthrough - kernel part

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> benami@il.ibm.com wrote:
>>>  
>>>> From: Ben-Ami Yassour <benami@il.ibm.com>
>>>>
>>>> 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.

http://lkml.org/lkml/2008/1/30/473

Ubuntu now carries this and I think Fedora has carried something like 
this for a long time.

It's okay for us because we just need device memory access but who knows 
if it will be restricted more in the future.  If X ever gets their act 
together and gets proper kernel drivers, I think there would be a strong 
case for removing /dev/mem altogether.

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

In an SELinux world, root may still have limited access to the system.  
In an ideal world, we would be able to guarantee that at worst, a guest 
can only harm the device it has access to and nothing else on the 
system.  This probably requires MSI and VT-d.  Even then, you may be 
able to physically damage the system by improperly programming the device.

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

I looked at Andrea's patches and I didn't see any special handling for 
non-RAM pages.  Something Muli mentioned that kept them from doing 
/sys/devices/pci/.../region to begin with was the fact that IO pages do 
not have a struct page backing them so get_user_pages() will fail in 
gfn_to_page().

It's not too hard to modify the code to also try get_user_pages() to 
look up the VMA instead of the struct page.  From the VMA, you can get 
the HPA for an IO mapping.  The problem though is that gfn_to_page() 
wants to return a page, not a HPA.  I haven't looked too deeply yet, but 
my suspicion is that to properly support mapping in VM_IO pages will 
require some general refactoring since we always assume that a struct 
page exists for any HPA.

Regards,

Anthony Liguori


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