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] [PATCH 14/14] Nested Virtualization: hap-on-hap

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 14/14] Nested Virtualization: hap-on-hap
From: Christoph Egger <Christoph.Egger@xxxxxxx>
Date: Thu, 19 Aug 2010 17:55:02 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 19 Aug 2010 08:55:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100809131822.GD13291@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <201008051705.35018.Christoph.Egger@xxxxxxx> <20100809131822.GD13291@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.10
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.


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

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>