Re: [PATCH 1/1] Enble a guest to access a device's memory mapped I/O regions directly.

[Avi Kivity <avi@qumranet.com>]

Muli Ben-Yehuda wrote:
>>>   
>>>       
>> Why avoid rmap on mmio pages?  Sure it's unnecessary work, but
>> having less cases improves overall reliability.
>>     
>
> The rmap functions already have a check to bail out if the pte is not
> an rmap pte, so in that sense, we aren't adding a new case for the
> code to handle, just adding direct MMIO ptes to the existing list of
> non-rmap ptes.
>
>   

I'm worried about the huge chain of direct_mmio parameters passed to 
functions, impact on the audit code (at the end of mmu.c, and the poor 
souls who debug the mmu.

>> You can use pfn_valid() in gfn_to_pfn() and kvm_release_pfn_*() to
>> conditionally update the page refcounts.
>>     
>
> Since rmap isn't useful for direct MMIO ptes, doesn't it make more
> sense to "bail out" early rather than in the bowls of the rmap code?
>   

It does, from a purist point of view (which also favors explicit 
parameters a la direct_mmio rather than indirect parameters like 
pfn_valid()), but I'm looking from the practical point of view now.

With mmu notifiers, we don't need to hold the refcount at all.  So 
presuming we drop the refcounting code completely, are any changes 
actually necessary here?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone