Re: [PATCH] i386: For debugging, make the initial page table setup less forgiving.

[Jeremy Fitzhardinge <jeremy@goop.org>]

Eric W. Biederman wrote:
>> The issue is not a matter of avoiding duplicate work, but making sure
>> all the pagetables are consistent from Xen's perspective.
>>
>> Specifically, you may not ever, at any time, create a writable mapping
>> of a page which is currently part of an active pagetable.  This means
>> that when we're creating mappings of physical memory, the pages which
>> are part of the current pagetable must be mapped RO.  The easiest way I
>> found to guarantee that is to copy the Xen-provided pagetable as a
>> template, and only update pages which are missing.
>>     
>
> Hmm.  I now see your problem.
>
>   
>> The other way I could do this is to have special-purpose init-time
>> version of xen_set_pte which checks to see if it's making a RO mapping
>> RW, and refuse to do it.  That would minimize the changes to mm/init.c,
>> but give init-time set_pte rather unexpected hidden semantics.
>>     
>
> Yes.  However how do we handle attempting to create this kind
> of mapping when mmap /dev/mem?  or /dev/kmem?
>   

Hm, I hadn't thought about that. I'm not sure that /dev/k?mem is very
useful in an unprivileged guest, but I guess its useful for debugging or
stats or something. It's tricky to tell whether an arbitrary pfn is part
of a pagetable or not; there's a PG_PINNED page flag to tell you if its
active, but iff you've already determined its a pagetable page.

> I'm pretty certain there are other paths through the kernel where
> we can get page table mapping.
>
> Right now by leaving things read-only you are hiding from the kernel 
> what you are really trying to do.  That makes me distinctly
> uncomfortable.  In general when things get swept under the rug
> we can never handle the properly.  Although this issue may be small
> enough it doesn't matter.
>   

Well, the general idea is that in a paravirtualized environment
pagetable pages need special handling. Different hypervisors need
different handling, but they all need something special. The paravirt
hooks are intended to capture all the interesting events, without
over-constraining what special thing the hypervisor wants to do at that
point.

That's why I went for the "allow the hypervisor to provide a prototype
pagetable, and avoid the bits it has already set up"; it allows it to do
whatever it wants, without getting too specific about what that is, and
retains a fairly straightforward interface.

> I suspect what we want to do is come up with a function to call
> to test to see if a page should be read-only and map such pages
> _PAGE_KERNEL_RO, or _PAGE_KERNEL_RO_EXEC if it's code.
>   

Hm, I think that's a hard function to write in general. For the special
case of pagetable_init it wouldn't be too hard, but it doesn't seem like
a big improvement over the current state of affairs.

> Speaking of things what are paravirt_alloc_pd and parafirt_alloc_pd 
> supposed to do?
>   
(alloc_pd and alloc_pt)

Broadly speaking, they tell the hypevisor that there's a new page about
to be attached to the pagetable. Xen uses it as the hook to map those
pages RO if the pagetable is active. VMI (and lguest?) use it to tell
the hypervisor's shadow pagetable machinery that there's something new
to track.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/