[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzQodrSUCNchdaQs@gao-cwp>
Date: Wed, 28 Sep 2022 18:56:54 +0800
From: Chao Gao <chao.gao@...el.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Kohler, Jon" <jon@...anix.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC v2] KVM: x86/vmx: Suppress posted interrupt notification
when CPU is in host
>> 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.
Powered by blists - more mailing lists