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>
Subject: Re: [PATCH 14/14] Nested Virtualization: hap-on-hap
Date: Thu, 19 Aug 2010 17:55:02 +0200 [thread overview]
Message-ID: <201008191755.02546.Christoph.Egger@amd.com> (raw)
In-Reply-To: <20100809131822.GD13291@whitby.uk.xensource.com>
On Monday 09 August 2010 15:18:22 Tim Deegan wrote:
> Hi,
>
> This looks a lot nicer than the last version I reviewed. I'm still
> concerned about TLB and p2m flushes, though.
>
> - I can't see how writes to the 'host' p2m table cause the 'shadow' p2m
> tables to be flushed. I might just have missed it.
The 'shadow' p2m is flushed when
- the l1 guest runs an instruction like INVLPGA (e.g. Windows 7 does so)
- the l1 guest sets up a VMCB where
* the tlb_control is set
* the asid changed
* the nested cr3 changed (and there is no free nestedp2m slot)
> - The p2m_flush operations don't look safe against other vpcus. Mostly
> they're called with v==current, which looks OK, but what if two vcpus
> are running on the same p2m? Also when p2m_get_nestedp2m() flushes
> the domain's LRU p2m, there's no shootdown if that p2m is in use on
> another pcpu. That could happen if the VM has more vcpus than
> MAX_NESTEDP2M. (Actually, that case is probably pretty broken
> generally.)
Yes, this is indeed an issue that needs to be fixed. How do I do
a TLB shootdown across physical cpus which schedule
vcpus bound to the l1 guest ?
The physical cpu must leave the l1/l2 guest on the tlb shootdown.
An optimization is to limit the tlb shootdown to those physical cpus
where "their" vcpus are in guestmode if this is possible to implement.
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
next prev parent reply other threads:[~2010-08-19 15:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-05 15:05 [PATCH 14/14] Nested Virtualization: hap-on-hap Christoph Egger
2010-08-09 13:18 ` Tim Deegan
2010-08-19 15:55 ` Christoph Egger [this message]
2010-08-19 16:33 ` Tim Deegan
2010-09-01 14:27 ` Christoph Egger
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=201008191755.02546.Christoph.Egger@amd.com \
--to=christoph.egger@amd.com \
--cc=Tim.Deegan@citrix.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.