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

[Avi Kivity <avi@qumranet.com>]

Ben-Ami Yassour1 wrote:
>>
>> 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?
>>
>>     
> Our initial approach was to mmap /sys/bus/pci/devices/.../resource#
> and create a memory slot for it. However eventually we realized that for
> mmio we don't need hva mapped to the mmio region, we can map the gpa
> directly to hpa.
>
> As far as I understand, the memory slots mechanism is used to map
> gpa to hva. Then gfn_to_page uses get_user_pages to map hva to hpa.
> However, get_user_pages does not work for mmio, and in addition we
> know the hpa to begin with, so there is no real need to map an hva
> for the mmio region.
>
> In addition there is an assumption in the code that there is a page
> struct for the frame which is not the case for mmio. So it was
> easier to simply add a list of mmio gpa-hpa mapping.
>
> I guess we can use the memory slots array to holds the gpa to hpa
> mapping but it is not necessarily natural, and would probably
> require more hooks in the code to handle an mmio memory slot. BTW,
> note that for a guest that has multiple passthrough devices each
> with a set of mmio regions, it might become a long list, so there
> might be value to keep it separate from that respect as well.
>
> With regards to the potential security issue Anthony pointed out
> (ioctls taking hpa's) we can change the interface so that they will
> take (device, BAR) instead and the kernel will translate to hpa
>
>   

Not enough.  How do you know if this calling process has permissions to 
access that pci device (I retract my previous "pci passthrough is as 
rootish as you get" remark).

> What do you think? Given that the shadow page table code has to be
> modified anyway (due to the struct page issue), is it worthwhile to
> experiment with mmap(...region) or is the current approach sufficient?
>   

As Anthony points out, the advantage to mmap() is that whatever security 
is needed can be applied at that level.  Passing host physical addresses 
from userspace requires a whole new security model.

The issue with gfn_to_page() is real.  We can either try to work around 
it somehow, or we can try to back mmio regions with struct pages.  Now 
that it looks like mem_map is becoming virtually mapped, the cost is 
minimal, but I expect this approach will meet some resistance.

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