RE: [Xen-devel] Shadow Code Reorganization

Ian Pratt
Tue, 26 Jul 2005 21:15:28 -0000

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