kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Makarand Sonare <makarandsonare@google.com>
Cc: kvm@vger.kernel.org, pshier@google.com, jmattson@google.com
Subject: Re: [PATCH v2 1/2] KVM: nVMX: Fix VMX preemption timer migration
Date: Thu, 21 May 2020 11:06:22 +0200	[thread overview]
Message-ID: <238d656c-df6a-85cd-074b-f4b134b37c6e@redhat.com> (raw)
In-Reply-To: <87mu61smho.fsf@vitty.brq.redhat.com>

On 21/05/20 10:47, Vitaly Kuznetsov wrote:
>>>
>> Yes, please do so.  The header is exactly for cases like this where we
>> have small fields that hold non-architectural pieces of state.
>>
> This can definitely work here (and I'm not at all against this solution)
> but going forward it seems we'll inevitably need a convenient way to
> handle sparse/extensible 'data'. Also, the header is 128 bytes only.

I'd rather cross that bridge when we get there, so:

- for now, add an u32 to the header that indicates the validity of
header fields other than smm.flags (in this case the preemption timer
deadline)

- if we ever add more stuff to the data, we will 1) always include the
first 8k for backwards compatibility 2) use another u32 in the header to
tell you the validity of the data

Addition to the nested state header should be relatively rare, since
it's only for non-architectural (implementation-specific) state.

Paolo

> I'd suggest we add an u32/u64 bit set to the header (which will be separate
> for vmx/svm structures) describing what is and what's not in vmx/svm
> specific 'data', this way we can easily validate the size and get the
> right offsets. Also, we'll start saving bits in arch neutral 'flags' as
> we don't have that many :-)


  reply	other threads:[~2020-05-21  9:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 22:22 [PATCH v2 0/2] Fix VMX preemption timer migration Makarand Sonare
2020-05-19 22:22 ` [PATCH v2 1/2] KVM: nVMX: " Makarand Sonare
2020-05-20 17:08   ` Vitaly Kuznetsov
2020-05-20 18:53     ` Makarand Sonare
2020-05-20 20:53       ` Paolo Bonzini
2020-05-21  8:47         ` Vitaly Kuznetsov
2020-05-21  9:06           ` Paolo Bonzini [this message]
2020-05-19 22:22 ` [PATCH v2 2/2] KVM: selftests: VMX preemption timer migration test Makarand Sonare

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=238d656c-df6a-85cd-074b-f4b134b37c6e@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=makarandsonare@google.com \
    --cc=pshier@google.com \
    --cc=vkuznets@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).