public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alok Kataria <akataria@vmware.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	Gleb Natapov <gleb@kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	jmattson@vmware.com
Subject: Re: [PATCH v2] KVM: Synthesize G bit for all segments.
Date: Thu, 10 Jul 2014 10:55:56 +0200	[thread overview]
Message-ID: <53BE551C.7090304@siemens.com> (raw)
In-Reply-To: <1404793061.30313.1874.camel@akataria-dtop.eng.vmware.com>

On 2014-07-08 06:17, Alok Kataria wrote:
> Thanks Jan and Paolo for looking at the change, I have added a comment
> in svm_get_segment. Joerg, please consider this for the next merge.
> 
> --
> 
> From: Jim Mattson <jmattson@vmware.com>
> 
> We have noticed that qemu-kvm hangs early in the BIOS when runnning nested
> under some versions of VMware ESXi.
> 
> The problem we believe is because KVM assumes that the platform preserves
> the 'G' but for any segment register. The SVM specification itemizes the
> segment attribute bits that are observed by the CPU, but the (G)ranularity bit
> is not one of the bits itemized, for any segment. Though current AMD CPUs keep
> track of the (G)ranularity bit for all segment registers other than CS, the
> specification does not require it. VMware's virtual CPU may not track the
> (G)ranularity bit for any segment register.
> 
> Since kvm already synthesizes the (G)ranularity bit for the CS segment. It
> should do so for all segments. The patch below does that, and helps get rid of
> the hangs. Patch applies on top of Linus' tree.
> 
> Signed-off-by: Jim Mattson <jmattson@vmware.com>
> Signed-off-by: Alok N Kataria <akataria@vmware.com>
> 
> Index: linux-2.6/arch/x86/kvm/svm.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kvm/svm.c	2014-07-07 15:32:52.724368183 +0530
> +++ linux-2.6/arch/x86/kvm/svm.c	2014-07-08 09:30:29.124431069 +0530
> @@ -1415,7 +1415,13 @@
>  	var->avl = (s->attrib >> SVM_SELECTOR_AVL_SHIFT) & 1;
>  	var->l = (s->attrib >> SVM_SELECTOR_L_SHIFT) & 1;
>  	var->db = (s->attrib >> SVM_SELECTOR_DB_SHIFT) & 1;
> -	var->g = (s->attrib >> SVM_SELECTOR_G_SHIFT) & 1;
> +
> +	/*
> +	 * SVM spec doesn't require the platform to track the G bit for all
> +	 * segments, so similar to CS, let's synthesize this bit for all
> +	 * segments.

Either I misunderstand the reference to CS or it does no longer apply
once the patch is in. I would suggest to remove that part of the sentence.

Jan

> +	 */
> +	var->g = s->limit > 0xfffff;
>  
>  	/*
>  	 * AMD's VMCB does not have an explicit unusable field, so emulate it
> @@ -1424,14 +1430,6 @@
>  	var->unusable = !var->present || (var->type == 0);
>  
>  	switch (seg) {
> -	case VCPU_SREG_CS:
> -		/*
> -		 * SVM always stores 0 for the 'G' bit in the CS selector in
> -		 * the VMCB on a VMEXIT. This hurts cross-vendor migration:
> -		 * Intel's VMENTRY has a check on the 'G' bit.
> -		 */
> -		var->g = s->limit > 0xfffff;
> -		break;
>  	case VCPU_SREG_TR:
>  		/*
>  		 * Work around a bug where the busy flag in the tr selector
> 
> 
> 

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

  reply	other threads:[~2014-07-10  8:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-07 10:38 [RFC PATCH] KVM: Synthesize G bit for all segments Alok Kataria
2014-07-07 10:52 ` Jan Kiszka
2014-07-07 13:04 ` Paolo Bonzini
2014-07-08  4:17   ` [PATCH v2] " Alok Kataria
2014-07-10  8:55     ` Jan Kiszka [this message]
2014-07-10 12:27       ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2014-07-11  7:08 Alok Kataria
2014-07-11  7:09 ` Paolo Bonzini

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=53BE551C.7090304@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=akataria@vmware.com \
    --cc=gleb@kernel.org \
    --cc=jmattson@vmware.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox