Re: [Xen-devel] page table question!

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > "Writable pagetables" is an interface introduced for Xen 3 PV
> > guests to update
> > their pagetables.  Previous versions of Xen required guests
> > to be modified to
> > make every update to their pagetables explicitly call into Xen (and
> > explicitly batch those operations).  Writeable pagetables
> > replace this by
> > allowing updates to the pagetables to be implemented by the
> > guest as attempts
> > to write directly to them.  This isn't a trusted operation,
> > however, since
> > Xen uses page protections to prevent unvalidated writes going
> > through...
> > Right now this is implemented by trapping each attempt to
> > write to the lower
> > levels of the pagetables and emulating it in Xen.  Previous
> > implementations
> > were a bit more complicated but found to be unnecessary.
>
> Thanks for clarifying. I seem to remember reading about a mode where the
> page-table isn't "read-only" - did I just imagine that, or what?

As far as I know normal Xen doesn't support any mode where the guest can write 
directly to real pagetables without validation... 

I can think of two things you might have read about:

1) on intercepting an attempted write to an L1 pagetable, the wrpt code would 
unhook that from the pagetable hierarchy, and then make it writable.  
Subsequently, the guest could write to it as a normal page.  A fault would 
occur if the CPU tried to translate a VA covered by this pagetable, at which 
point Xen would revalidate that pagetable for safety, then hook it back into 
the hierarchy.  This let batching of pagetable updates be entirely implicit, 
but it later turned out that it performed less well than emulating each 
write, and using explicit batching in the guest.

2) if you compile Xen with the right options, a dom0 kernel (possibly with the 
right bumf compiled in) can run in ring0 and sort-of bypass a load of Xen's 
normal checks.  The intent was to use this to make a kernel bootable both on 
native hardware (eventually using a "minixen" rather than heavyweight Xen) 
and paravirt.  This hasn't been investigated much, since Linux decided to 
pursue the paravirt-ops solution, which allows a kernel to boot native or 
paravirt anyway.


> > One thing I've never been clear on for shadow mode is how
> > accessed / dirty
> > bits get propagated to the guest pagetable from the shadow.
>
> Good question. I have a feeling that the answer is "it doesn't". HAP
> would probably solve this problem.

Don't guests need the dirty bits for their memory management (e.g. mmap) to 
work correctly?  Maybe one could do something scary like trapping reads to 
guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross 
though.

HAP is definitely HAPpier :-)

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel