| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Cheers,
Tim.
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home