On 2019/10/1 16:39, Vitaly Kuznetsov wrote:
Zhenzhong Duan<zhenzhong.d...@oracle.com> writes:
On 2019/9/30 23:41, Vitaly Kuznetsov wrote:
Zhenzhong Duan<zhenzhong.d...@oracle.com> writes:
There are cases where a guest tries to switch spinlocks to bare metal
behavior (e.g. by setting "xen_nopvspin" on XEN platform and
"hv_nopvspin" on HYPER_V).
That feature is missed on KVM, add a new parameter "nopvspin" to disable
PV spinlocks for KVM guest.
This new parameter is also intended to replace "xen_nopvspin" and
"hv_nopvspin" in the future.
Any reason to not do it right now? We will probably need to have compat
code to support xen_nopvspin/hv_nopvspin too but emit a 'is deprecated'
warning.
Sorry the description isn't clear, I'll fix it.
I did the compat work in the other two patches.
[PATCH 2/3] xen: Mark "xen_nopvspin" parameter obsolete and map it to "nopvspin"
[PATCH 3/3] x86/hyperv: Mark "hv_nopvspin" parameter obsolete and map it to
"nopvspin"
For some reason I got CCed only on the first one and moreover,
The three patches have different maintainers/reviewers by get_maintainer.pl, I
added
"Cc: maintainers/reviewers" to each patch then git-sendemail picked them
automaticly.
I meaned to not disturb maintainers with the field they aren't in charge of. It
looks
I'm wrong.
So what's the correct way dealing with this? Should I send the whole patchset
to all
the maintainers/reviewers related to all the patches?
I don't see e.g PATCH3 on 'linux-hyperv' mailing list.
Thanks for point out, I'll add it.
Zhenzhong
