This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 12/13] Nested Virtualization: vram

At 14:32 +0100 on 13 Sep (1284388352), Christoph Egger wrote:
> > I don't think making the vram structures per-P2M is the best approach.
> > We're never going to have more than one vram area to track per guest so
> > it can just operate on the host-p2m, like it does already.
> >
> > In general, the log-dirty code operates on N1 pfns, and we won't want a
> > per-p2m log-dirty bitmap either; we'd only have to fold them together to
> > use them in the tools.
> Look at this trace:
> (XEN)    [<ffff82c4801f953e>] hap_write_p2m_entry+0x3e/0x1cb
> (XEN)    [<ffff82c4801cf285>] p2m_set_entry+0x4a7/0x782
> (XEN)    [<ffff82c4801c88e1>] set_p2m_entry+0xb3/0x101
> (XEN)    [<ffff82c4801cba46>] p2m_change_type+0x120/0x17a
> (XEN)    [<ffff82c4801f94ce>] hap_clean_vram_tracking+0x44/0x76
> (XEN)    [<ffff82c4801c7a6e>] paging_log_dirty_range+0x33/0x8b4
> (XEN)    [<ffff82c4801f9420>] hap_track_dirty_vram+0x109/0x173
> (XEN)    [<ffff82c4801a7afe>] do_hvm_op+0xc1a/0x12a5
> (XEN)    [<ffff82c4802000d2>] syscall_enter+0xf2/0x14c
> The problem is in paging_write_p2m_entry():
>      struct vcpu *v = current;
>      if ( v->domain != d )
>          v = d->vcpu ? d->vcpu[0] ? NULL;
> The chosen vcpu can be in guest mode and fill the vram / logdirty
> host p2m with l2 guest related data.

OK.  That's certainly confusing.  I think the fix is to have all the
outward-facing interfaces to the p2m code always operate on the host
(L1->L0) p2m.  None of their callers would know what to do with an L2
pfn anyway.  Only code that explicitly asks for it (e.g. the NPF
handler) should see the L2->L0 p2m.



Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Xen-devel mailing list