From: Chao Gao <chao.gao@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Kohler, Jon" <jon@nutanix.com>, "Christopherson,,
Sean" <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v2] KVM: x86/vmx: Suppress posted interrupt notification when CPU is in host
Date: Wed, 28 Sep 2022 18:56:54 +0800 [thread overview]
Message-ID: <YzQodrSUCNchdaQs@gao-cwp> (raw)
In-Reply-To: <BL1PR11MB52712631CBBED273F5E4E1828C549@BL1PR11MB5271.namprd11.prod.outlook.com>
>> Changes in v2 (addressed comments from Kevin):
>> - measure/estimate the impact to non-IPC-intensive cases
>> - don't tie PID.SN to vcpu->mode. Instead, clear PID.SN
>> right before VM-entry and set it after VM-exit.
>
>One correction here. My comment in v1 [1] was actually close to Sean's
>suggestion, i.e. opposite to above description:
Hi Kevin,
Yes. The changelog is misleading. You suggested using a dedicate hook.
And I indeed agreed to follow the suggestion. But as you said, what v2
does is the complete opposite of the suggestion.
The reason is when I started v2 recently, the idea of clearing SN right
before VM-entry came to my mind. Since it could also solve some problems
of v1 without a hook (hence, more self-contained), I thought it was
slightly better. But I missed that clearing SN right before VM-entry can
cause unnecessary SN toggling to VM-exit fast-path.
prev parent reply other threads:[~2022-09-28 10:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 8:58 [RFC v2] KVM: x86/vmx: Suppress posted interrupt notification when CPU is in host Chao Gao
2022-09-26 16:19 ` Sean Christopherson
2022-09-27 6:32 ` Chao Gao
2022-09-27 21:43 ` Sean Christopherson
2022-09-28 11:26 ` Chao Gao
2022-09-28 8:29 ` Tian, Kevin
2022-09-28 10:56 ` Chao Gao [this message]
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=YzQodrSUCNchdaQs@gao-cwp \
--to=chao.gao@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jon@nutanix.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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.