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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: [Xen-devel] Re: Addback capability check for non-initial features
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Fri, 10 Jun 2011 07:58:46 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Jun 2011 00:01:08 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=cxBAN5zHzmP4xGI3gEFiQht9JeFI10x0CLgcBxmy23c=; b=qb/K+Dzedxu1dBN4jVEdD0g9wRxujdhAGtMt6jnFi2y1njzvVD0j5qeA2bW1hUx66n 3VekhTJyCSVLT9A7fcAhwbbRPDObeodVnWQ5N/Zc2IJLZqS/qTzgjY+7aue01k1BEYrC /kw13NemwWQO4qaaYPrHQ6gyRMmyHmj/5m2NI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=qslcE5kgPmL4iW1UxOiKLnSOT5yK9pgnvj03wJwdN95vnVtR1RBT2uW5LlT0D4sJRg BMm7VJOaFNlNNes9yKNg2lKL0LnvXd2eMkwnUvmnImSJVVFfV/DK6PoHa6QV2Lnl5s7r j/fw8AeIOIVvFmOTieldoG1/qczO6mbAB2gnw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B256260BAD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwm8ei0Bw+DOsTeG0qq3AI37qSa+QAPjT8AAACHkVAAAItBlwAAxALQAAEXpDQ=
Thread-topic: Addback capability check for non-initial features
User-agent: Microsoft-Entourage/
On 10/06/2011 07:33, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

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

Not in your patch. You remove it later if TPR_SHADOW *doesn't* 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
> shadow.

Hmm okay.

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

More correct than yours :)

 -- Keir

> Thx, Eddie

Xen-devel mailing list