On Thu, 2007-09-13 at 22:46 +0800, Peter Teoh wrote:
> Thank you Ian, Pradeep, and Keir for all the answers. Just a few
> more questions to confirm my understanding:
>
> On 9/13/07, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > > Thank you for the answer. In the first place, we
> will not
> > know what is
> > > pagetable or non-pagetable memory. For example,
> during
> > dom0/domU
> > > initialisation, the guest OS will query the e820
> bios
> > mechanism for physical
> > > memory availability, and the guest OS (paravirt
> or HVM)
> > will then assign
> > > different parts of the physical memory for
> pagetable
> > construction.
>
> I guessed this part is wrong - ie, PV will not have the luxury of
> having the entire range of contiguous physical memory. Since the
> actual pagetable to be used will be stored in guest memory, to
> minimize copying, what the guest see in the pagetable, will also be
> the real value to be used in MMU operation. Correct?
Yes -- in PV mode the exact cr3 value the guest wants to load is loaded
into the MMU, there is no shadow mode at all for PV guests and hence no
second set of page tables.
> You need to make it clear whether you are talking about
> paravirutalised
> (PV) or fully-virtualised (HVM) mode guests, they are very
> different in
> this regard.
>
> Apologies for this deep probing again. I don't quite understand why
> it has to be PV or HVM.
Because page tables are handled in two different and separate ways
depending on whether the guest is a PV or HVM guest. The key difference
is that PV uses "direct page tables" and HVM uses "shadow page tables".
Your failure to understand this seems to underlie most of your
confusion.
> As the "load cr3" instruction is a privileged insn, running it at
> ring1 (PV) will trigger a exception condition,
True, although we actually use an explicit "load cr3" hypercall instead
for PV guests, in theory that could have been done via emulation of the
mov to cr3 instruction but it isn't.
> which can be used to update the hypervisor shadow table, if it is
> implemented, irregardless of HVM (which is SVM or VMX) available or
> not. Similarly for guest readonly pagetable enforcement - no HVM
> features is needed here, because it is still running at ring1, and
> subject to ring0's host control. Please englighten :-).
Guest readonly page table enforcement is used with PV guests, not HVM
guests so I don't get what you are trying to say here, of course no HVM
features are needed for this.
If a PV guest was able to setup writable mappings to its own page tables
then it could use these to update the currently active page tables
without trapping via the hypervisor and therefore map memory it is not
allowed to.
There is no hardware feature which stops ring 1 writing to a page (even
a page table page) if a writable mapping exists (the U/S bit only stops
ring 3 writing to a page) hence the hypervisor has to enforce additional
constraints on the mappings of page table pages for PV guests.
> Perhaps some other operations subsequent to this make the shadow table
> implementation for PV infeasible?
There is nothing in principle stopping you from implementing a shadow
mode for PV (in fact there used to be one but it went away with
shadow2). However direct paging has lower overheads than shadow paging,
doesn't need an extra copy of the page table (i.e. lower memory
requirements), etc etc.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home