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

Re: [Xen-devel] Shadow Code Reorganization



"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> writes:

> The shadow32.c file (formerly shadow.c) still exists because it's had
> more testing than the new file, and we want both in the tree until we're
> convinced there's been no regression between the two. We'll then delete
> shadow32 and compile shadow.c in 32 bit mode. Base any new development
> on the new shadow.c

While we are at it and I'll go work on shadow mode as well soon some
followup questions ;)

 * "normal" shadow mode is almost identical to shadow mode off,
   i.e. the guest does machine<=>phys translations.  The guest hasn't
   to mark pages containing page tables r/o because xen can do that in
   the shadow tables.

 * In "translated" shadow mode the guest kernel handles a linear
   physical address space starting at addr zero and xen does the
   machine<=>phys translations when copying guest tables into the
   shadow page tables.

 * "external" is translated shadow mode + separated address space,
   i.e. no hypervisor window in the address space, used for vt.

Correct so far?

Enabling/switching shadow modes works by dropping all shadow tables,
start with a zero-ed toplevel page directory (almost, except
hypervisor window) and update the shadow pagetable tree as faults are
coming in.  Correct?

But it's not clear to me how the transition between "normal" and
"translated" shadow mode works.  Does that need support by the guest
os?

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

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