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

Avi Kivity
2008-04-02T09:50:50Z

Andrea Arcangeli wrote:
> On Wed, Apr 02, 2008 at 07:32:35AM +0300, Avi Kivity wrote:
>
>> It ought to work. gfn_to_hfn() (old gfn_to_page) will still need to take a
>> refcount if possible.
>>
>
> This reminds me, that mmu notifiers we could implement gfn_to_hfn only
> with follow_page and skip the refcounting on the struct page.
>
> I'm not suggesting that though, the refcount makes the code more
> robust IMHO, and notably it allows to run on kernels without mmu
> notifiers.
>
>

Isn't it faster though? We don't need to pull in the cacheline
containing the struct page anymore.

We could hack something to make pre mmu notifier kernels work.

>
> I'm unsure if it's good to add struct pages for non-ram, I find it
> slightly confusing and not the right thing, it takes memory for stuff
> that can't happen (refcounting only makes sense if the page finally
> goes in the freelist when count reaches 0, and PG_dirty/referenced
> bits and the like don't make sense either for non-ram or
> reserved-ram). So I'm not sure the vmemmap trick is the best.
>
>

I thought we'd meet with resistance to that idea :) though I'd like to
point out that struct pages to exist for mmio on some machines (those
with >= 4GB).

>> This will increase the potential for type errors, so maybe we need to make
>> gfn_t and hfn_t distinct structures, and use accessors to get the actual
>> values.
>>
>
> That's also a possibility. If we go for this then hfn_t is probably a
> better name as it's less likely to collide with core kernel VM
> code. Otherwise perhaps "pfn" can be used instead of hfn, it's up to
> you ;).
>

I guess we can move to pfn, they're unambiguous enough.

--
error compiling committee.c: too many arguments to function