From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: Re: [PATCH 12/13] Nested Virtualization: vram Date: Mon, 13 Sep 2010 17:36:20 +0200 Message-ID: <201009131736.25935.Christoph.Egger@amd.com> References: <201009011717.34746.Christoph.Egger@amd.com> <201009131532.33648.Christoph.Egger@amd.com> <20100913135040.GJ3844@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100913135040.GJ3844@whitby.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org On Monday 13 September 2010 15:50:40 Tim Deegan wrote: > 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) [] hap_write_p2m_entry+0x3e/0x1cb > > (XEN) [] p2m_set_entry+0x4a7/0x782 > > (XEN) [] set_p2m_entry+0xb3/0x101 > > (XEN) [] p2m_change_type+0x120/0x17a > > (XEN) [] hap_clean_vram_tracking+0x44/0x76 > > (XEN) [] paging_log_dirty_range+0x33/0x8b4 > > (XEN) [] hap_track_dirty_vram+0x109/0x173 > > (XEN) [] do_hvm_op+0xc1a/0x12a5 > > (XEN) [] 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. The instruction emulator also must see the L2 -> L0 p2m - to be more precise it is __hvm_copy() that fetches the instruction - in order to be able to emulate instructions for the L2 guest the L1 guest does not intercept. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632