| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Shadow Code Reorganization
> 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
|
|
|
| |
|
Home