All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Mattson <jmattson@google.com>
To: KarimAllah Ahmed <karahmed@amazon.de>
Cc: "kvm list" <kvm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [PATCH v2] kvm: nVMX: Introduce KVM_CAP_STATE
Date: Mon, 9 Apr 2018 12:24:34 -0700	[thread overview]
Message-ID: <CALMp9eSAK=k21pPsD_AOiDSWsPO88NE4HLYqNJmt_d10pWd1nw@mail.gmail.com> (raw)
In-Reply-To: <1523263049-31993-1-git-send-email-karahmed@amazon.de>

On Mon, Apr 9, 2018 at 1:37 AM, KarimAllah Ahmed <karahmed@amazon.de> wrote:

> +       /*
> +        * Force a nested exit that guarantees that any state capture
> +        * afterwards by any IOCTLs (MSRs, etc) will not capture a mix of L1
> +        * and L2 state.
> +        *
> +        * One example where that would lead to an issue is the TSC DEADLINE
> +        * MSR vs the guest TSC. If the L2 guest is running, the guest TSC will
> +        * be the L2 TSC while the TSC deadline MSR will contain the L1 TSC
> +        * deadline MSR. That would lead to a very large (and wrong) "expire"
> +        * diff when LAPIC is initialized during instance restore (i.e. the
> +        * instance will appear to have hanged!).
> +        */

This sounds like a bug in the virtualization of IA32_TSC_DEADLINE.
Without involving save/restore, what happens if L2 sets
IA32_TSC_DEADLINE (and L1 permits it via the MSR permission bitmap)?
The IA32_TSC_DEADLINE MSR is always specified with respect to L1's
time domain.

  parent reply	other threads:[~2018-04-09 19:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  8:37 [PATCH v2] kvm: nVMX: Introduce KVM_CAP_STATE KarimAllah Ahmed
2018-04-09 11:26 ` David Hildenbrand
2018-04-10  7:37   ` Raslan, KarimAllah
2018-04-09 18:30 ` Jim Mattson
2018-04-09 19:24 ` Jim Mattson [this message]
2018-04-10  7:11   ` Raslan, KarimAllah

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='CALMp9eSAK=k21pPsD_AOiDSWsPO88NE4HLYqNJmt_d10pWd1nw@mail.gmail.com' \
    --to=jmattson@google.com \
    --cc=hpa@zytor.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --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 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.