All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: "Dong, Eddie" <eddie.dong@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Addback capability check for non-initial features
Date: Fri, 10 Jun 2011 07:58:46 +0100	[thread overview]
Message-ID: <CA177F36.1C036%keir.xen@gmail.com> (raw)
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B256260BAD@shsmsx501.ccr.corp.intel.com>

On 10/06/2011 07:33, "Dong, Eddie" <eddie.dong@intel.com> 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

  reply	other threads:[~2011-06-10  6:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 15:49 Bug in smpboot.c? John McDermott (U.S. Navy Employee)
2011-06-09 22:09 ` Keir Fraser
2011-06-10  5:36   ` Addback capability check for non-initial features Dong, Eddie
2011-06-10  5:50     ` Dong, Eddie
2011-06-10  6:05       ` Keir Fraser
2011-06-10  6:33         ` Dong, Eddie
2011-06-10  6:58           ` Keir Fraser [this message]
2011-06-10  7:33       ` Keir Fraser
2011-06-10  8:05         ` Dong, Eddie
2011-06-10  7:30 ` Bug in smpboot.c? Keir Fraser
2011-06-10 11:31   ` John McDermott CIV

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=CA177F36.1C036%keir.xen@gmail.com \
    --to=keir.xen@gmail.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.