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

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Ben-Ami Yassour1 wrote:
>   
>>   
>>     
>
> 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.
>   

What about switching the KVM MMU code to use hfn_t instead of struct 
page? The initial conversion is pretty straight forward as the places 
where you actually need a struct page you can always get it from 
pfn_to_page() (like in kvm_release_page_dirty).

We can then teach the MMU to deal with hfn_t's that don't have a 
corresponding page.  IIUC, the implementation of something like 
kvm_release_page_dirty is a nop for pfn's that don't have a 
corresponding page.  We just have to be able to detect a pfn_to_page() 
failure and then assume we're dealing with IO memory.

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