[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Live migration leaves page tables read-only?


  • To: "John Byrne" <john.l.byrne@xxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Sun, 14 Jan 2007 08:21:46 -0000
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 14 Jan 2007 00:22:05 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acc3khOhSfQ+km+4Sv6wOaw/qd8ljAAIRIww
  • Thread-topic: [Xen-devel] Live migration leaves page tables read-only?

> I haven't noticed a fix. Is someone working on this bug or should I
open
> a bugzilla for it, so it isn't forgotten?

It's not forgotten, but I'm not aware of anyone actively working on it.
It's a bit fiddly to fix properly.

We need to add an elf note that describes how to identify not-present
PTEs that contain MFNs. For linux this is easy as testing for the
presence of a single bit being set works. In principle, you might need a
more complex scheme, but I'm not aware of any OSes that actually require
this. 

Allowing a mask and value to be specified would be good, something that
could be extended into a list of mask:value,mask:value in future if need
be e.g.:

 np_pte_contains_mfn_flags=c0:80,c0:40

The elf note would need to be pulled out of kernel by the domain
builder, and then we need to figure out how to make the info available
to the save/restore code.

Would be good if someone could pick this up.

Thanks,
Ian

> Ian Pratt wrote:
> >
> >> I finally ran down the problem. SAP is protecting the pages
PROT_NONE,
> >> so the page-present bit in the pte is not set and
> >> canonicalize/uncanonicalize code in save/restore ignore the pte.
I've
> >> attached a patch. It is possible that this change should be made to
> > the
> >> l1e tests in xc_ptrace.c; I'm not sure.
> >
> > That's a good catch, thanks. Interesting that we hadn't seen this
> > before.
> >
> > Although your patch works today, it will break when we add PSE
(super
> > page) support for PV guests as it will confuse PROT_NONE with PSE.
> > Assuming PROT_NONE only makes sense for L1 entries, we can probably
gate
> > the tests on whether the page table page is an L1 or not to fix
this.
> >
> > However, it does point out an issue for other OSes: Taking this
patch
> > effectively makes Linux's PROT_NONE (flags 0x80 for a not present
PTE)
> > part of the Xen API. We need to find out whether this is compatible
with
> > *BSD and Solaris' use of flags for not present ptes.
> >
> > Ian
> >


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.