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


[Xen-devel] RE: Addback capability check for non-initial features

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: [Xen-devel] RE: Addback capability check for non-initial features
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 10 Jun 2011 14:33:05 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Thu, 09 Jun 2011 23:35:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA1772BE.1C02D%keir.xen@xxxxxxxxx>
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: <1A42CE6F5F474C41B63392A5F80372B256260B2A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA1772BE.1C02D%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwm8ei0Bw+DOsTeG0qq3AI37qSa+QAPjT8AAACHkVAAAItBlwAAxALQ
Thread-topic: Addback capability check for non-initial features
> >
> > add back missing capability check of MSR_IA32_VMX_PROCBASED_CTLS.
> >
> > Besides initial configuration, adjust_vmx_controls is responsible for
> > hardware capibility check as well. This patch add back the check.
> I suppose the CPU_BASED_VIRTUAL_INTR_PENDING addition is correct, for
> what
> it's worth (surely every VMX-capable CPU ever has and will support that).
> The change to CR8 detection looks mad and incorrect. You've inverted it so
> that CR8 exits get enabled when TPR_SHADOW is available, rather than
> when it

CR8 exit is removed later on if TPR_SHADOW exist:) 
The only difference is that if there are processors that support TPR_SHADOW 
only, I can check internally if this is the concern.
Current nested vmx is assuming CR8 exiting is presented to emulate L1 guest CR8 
exiting. TPR_SHAOW can't trap CR8 read though cr8 write trap is OK w/ TPR 

Eventually I want to have a minimal common set of capability that is supported 
by all HW and is presented to L1 guest.

> isn't, surely? And that can't be correct. I don't see how the CR8-exit
> detection and enabling is wrong, as it is already.

The original code for CR8 exit is correct too :)

Thx, Eddie

Xen-devel mailing list