From: Sean Christopherson <seanjc@google.com>
To: Li Rongqing <lirongqing@baidu.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH] x86/kvm: refine condition for checking vCPU preempted
Date: Wed, 15 Mar 2023 08:26:52 -0700 [thread overview]
Message-ID: <ZBHjNuQhqzTx13wX@google.com> (raw)
In-Reply-To: <01086b8a42ef41659677f7c398109043@baidu.com>
On Wed, Mar 15, 2023, Li,Rongqing wrote:
> > Rather than have the guest rely on host KVM behavior clearing PV_UNHALT
> > when HLT is passed through), would it make sense to add something like
> > KVM_HINTS_HLT_PASSTHROUGH to more explicitly tell the guest that HLT isn't
> > intercepted?
>
> KVM_HINTS_HLT_PASSTHROUGH is more obvious, but it need both kvm and guest support
Yeah, that's the downside. But modifying KVM and/or the userspace VMM shouldn't
be difficult, i.e the only meaningful cost is the rollout of a new kernel/VMM.
On the other hand, establishing the heuristic that !PV_UNHALT == HLT_PASSTHROUGH
could have to subtle issues in the future. It safe-ish in the context of this
patch as userspace is unlikely to set KVM_HINTS_REALTIME, hide PV_UNHALT, and _not_
passthrough HLT. But without the REALTIME side of things, !PV_UNHALT == HLT_PASSTHROUGH
is much less likely to hold true.
next prev parent reply other threads:[~2023-03-15 15:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-15 12:12 [PATCH] x86/kvm: refine condition for checking vCPU preempted lirongqing
2023-03-15 0:15 ` Sean Christopherson
2023-03-15 3:49 ` Li,Rongqing
2023-03-15 15:26 ` Sean Christopherson [this message]
2023-03-16 3:48 ` Li,Rongqing
2023-03-16 17:00 ` Sean Christopherson
2023-03-30 8:15 ` Li,Rongqing
2023-03-30 19:26 ` Sean Christopherson
2023-04-06 7:26 ` Li,Rongqing
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=ZBHjNuQhqzTx13wX@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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 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.