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

Anthony Liguori
2008-04-01T20:04:43Z

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