| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] page table question!
> > "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
|
|
|
| |
|
Home