All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Wang, Shane" <shane.wang@intel.com>
Cc: Avi Kivity <avi@redhat.com>, Zachary Amsden <zamsden@redhat.com>,
	kvm <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	"Cihula, Joseph" <joseph.cihula@intel.com>
Subject: Re: [PATCH 1/4] Fix tboot enabled macro
Date: Thu, 27 May 2010 11:23:37 +0200	[thread overview]
Message-ID: <4BFE3A19.6060603@siemens.com> (raw)
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A1E858CEE@shsmsx501.ccr.corp.intel.com>

Wang, Shane wrote:
> Jan Kiszka wrote:
>> If TXT is on and VT is locked but KVM sees tboot_enabled == 0, it
>> won't check for FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX during setup
>> and may consider VT unavailable.
> 
> If vt is locked, txt is on, tboot_enabled = 0, then it will check VMXON_OUTSIDE_SMX.
> But at this point, if vt is on (still locked), the fn will return 0, which means vmx is not disabled by bios, correct?
> 
> 
>> Moreover, if VT is not locked in that case, KVM will also not set
>> FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX during hardware_enable,
>> likely leaving VT off then, no? 
> 
> Sure, KVM will not set VMXON_INSIDE_SMX, but will set VMXON_OUTSIDE_SMX.
> In that case, this means vt is on.
> 
>> So my question is: Would it cause any harm to assume TXT being always
>> on, even if it wasn't?
> 
> A bit confused.
> Do you mean hardware TXT always on, i.e. set FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX = 1 always?
> That's fine. No problem. No harm.
> Or, do you mean set tboot_enabled = 1 always? 

The latter. As we have no clue about the actual state (tboot is not
exported on older kernels), we are forced to assume some reasonable state.

> if so, in case that the hardware TXT is disabled
> (FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX = 0), then KVM will think vmx is disabled if feature msr is locked.

Then let's leave it as it was before the tboot changes to VMX: assume
!tboot_enabled().

Thanks for explaining,
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2010-05-27  9:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26  3:33 [PATCH 1/4] Fix tboot enabled macro Zachary Amsden
2010-05-26  7:25 ` Jan Kiszka
2010-05-26  8:38   ` Avi Kivity
2010-05-26  9:23     ` Wang, Shane
2010-05-26 10:39       ` Jan Kiszka
2010-05-27  7:21         ` Wang, Shane
2010-05-27  8:36           ` Jan Kiszka
2010-05-27  9:13             ` Wang, Shane
2010-05-27  9:23               ` Jan Kiszka [this message]
2010-05-27  9:27                 ` Wang, Shane
2010-05-27 10:15                   ` Avi Kivity
2010-05-27 18:22                     ` Cihula, Joseph
2010-05-27  7:25         ` Wang, Shane

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=4BFE3A19.6060603@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=joseph.cihula@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=shane.wang@intel.com \
    --cc=zamsden@redhat.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.