All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.