Re: [Xen-devel] page table question!

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:
> > > 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.

When a guest pagetable entry has the Accessed bit clear, its shadow has
the Present bit clear.  This means we will get an extra page fault when
the guest tries to read that area of memory.  In the page-fault handler
we write the Accessed bit into the guest entry, and replace the shadow
entry with one that has the Present bit.  A similar scheme (shadowing
~Dirty with ~Writeable) applies to those entries that have Dirty bits.

The actual moving parts are in the _sh_propagate() function in
arch/x86/mm/shadow/multi.c, which is why that function needs to be told
whether it's handling a read fault, write fault or prefetch operation.

> Don't guests need the dirty bits for their memory management (e.g. mmap) to 
> work correctly? 

Yes, although in fact Xen doesn't quite catch all the cases where those
bits should be set (certain Xen-handled operations that walk the guest
pagetables instead of using the shadows) and it's not tripped us up
yet. :)

> 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.

It was considered. :)  (For good reasons; talk to Michael Fetterman
some time.)

> HAP is definitely HAPpier :-)

Yep, should see a significant performance increase and eliminate a lot
of moving parts.

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

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