RE: [Xen-devel] Shadow Code Reorganization

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

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

Depends what you mean by "normal". The mode that we need for migration
of a paravirtualized guest is log_dity but with refcounts in the *guest*
pages i.e. SHM_refcounts is not set. The guest still has to mark
pagetable pages RO and use the normal paravirtualized interface.
 
>  * 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.

Yes. SHM_refcounts is typically set.

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

Yes, this is used by VT-x.
 
> 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?

Only in modes where SHM_refcounts is set. For so-called "lightweight
shadow mode" (as used by migration) we continue using the guest
refcounts.

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

Guests typically don't make this transition -- it's currently a guest
compile time option whether to use the paravirtualized or translated
shadow mode interface. This isn't strictly necessary.

Ian

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