All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>
Subject: Re: Re: [PATCH 12/13] Nested Virtualization: vram
Date: Mon, 13 Sep 2010 15:32:32 +0200	[thread overview]
Message-ID: <201009131532.33648.Christoph.Egger@amd.com> (raw)
In-Reply-To: <20100913131641.GH3844@whitby.uk.xensource.com>

On Monday 13 September 2010 15:16:41 Tim Deegan wrote:
> At 16:47 +0100 on 08 Sep (1283964447), Christoph Egger wrote:
> > On Wednesday 08 September 2010 17:07:35 Tim Deegan wrote:
> > > Hi,
> > >
> > > Is this needed as part of the nested-HVM series or just an independent
> > > interface change?
> >
> > This is an independent interface change.
> > It is not needed to make nested-HVM work in general but it is part of
> > a larger change to make log dirty code nested virtualization aware.
>
> Ah; does the current nested-SVM patchset break logdirty?

I would say hap-on-hap in general does.
I mean that also counts for ept-on-ept.

See below.

>
> 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.

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

  reply	other threads:[~2010-09-13 13:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 15:17 [PATCH 12/13] Nested Virtualization: vram Christoph Egger
2010-09-08 15:07 ` Tim Deegan
2010-09-08 15:47   ` Christoph Egger
2010-09-13 13:16     ` Tim Deegan
2010-09-13 13:32       ` Christoph Egger [this message]
2010-09-13 13:50         ` Tim Deegan
2010-09-13 15:36           ` Christoph Egger
2010-09-13 15:51             ` Tim Deegan
2010-09-13 16:08               ` Christoph Egger
2010-09-13 16:17                 ` Tim Deegan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201009131532.33648.Christoph.Egger@amd.com \
    --to=christoph.egger@amd.com \
    --cc=Tim.Deegan@citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.