Message ID | alpine.LRH.2.11.1701251535220.13235@mail.ewheeler.net (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 26/01/2017 00:50, Eric Wheeler wrote: > 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs > 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX > > Thus, we need to either: > 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 > - or - > 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. > > If you choose the latter options, then please see below for the backport > patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). > > What do you believe would be best? The latter is better. Paolo
On Thu, 26 Jan 2017, Paolo Bonzini wrote: > On 26/01/2017 00:50, Eric Wheeler wrote: > > 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs > > 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX > > > > Thus, we need to either: > > 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 > > - or - > > 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. > > > > If you choose the latter options, then please see below for the backport > > patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). > > > > What do you believe would be best? > > The latter is better. > > Paolo Hi Greg, Paolo suggests cherry-picking the dependent commits with the backport patch instead of reverting the original patch. Do you need anything more in this thread to bring this into v4.1.y? Its an "Option 3" according to Documentation/stable_kernel_rules.txt with dependent commits so I'm not sure if you want this formatted any differently to make your merge easy---let me know. Thanks! -- Eric Wheeler
Hello, Am 27.01.2017 um 00:29 schrieb Eric Wheeler: > On Thu, 26 Jan 2017, Paolo Bonzini wrote: >> On 26/01/2017 00:50, Eric Wheeler wrote: >>> 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs >>> 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX >>> >>> Thus, we need to either: >>> 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 >>> - or - >>> 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. >>> >>> If you choose the latter options, then please see below for the backport >>> patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). >>> >>> What do you believe would be best? >> >> The latter is better. >> >> Paolo > > Hi Greg, 4.1 is maintained by Sasha Levin <alexander.levin@verizon.com>, cc-ed. > Paolo suggests cherry-picking the dependent commits with the backport > patch instead of reverting the original patch. Do you need anything more > in this thread to bring this into v4.1.y? > > Its an "Option 3" according to Documentation/stable_kernel_rules.txt with > dependent commits so I'm not sure if you want this formatted any > differently to make your merge easy---let me know. Philipp
On Fri, 27 Jan 2017, Philipp Hahn wrote: > Hello, > > Am 27.01.2017 um 00:29 schrieb Eric Wheeler: > > On Thu, 26 Jan 2017, Paolo Bonzini wrote: > >> On 26/01/2017 00:50, Eric Wheeler wrote: > >>> 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs > >>> 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX > >>> > >>> Thus, we need to either: > >>> 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 > >>> - or - > >>> 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. > >>> > >>> If you choose the latter options, then please see below for the backport > >>> patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). > >>> > >>> What do you believe would be best? > >> > >> The latter is better. > >> > >> Paolo > > > > Hi Greg, > > 4.1 is maintained by Sasha Levin <alexander.levin@verizon.com>, cc-ed. Thank you Philipp! > > Paolo suggests cherry-picking the dependent commits with the backport > > patch instead of reverting the original patch. Do you need anything more > > in this thread to bring this into v4.1.y? Sasha, do you need anything more to pull this into 4.1? Thanks! -- Eric Wheeler > > > > Its an "Option 3" according to Documentation/stable_kernel_rules.txt with > > dependent commits so I'm not sure if you want this formatted any > > differently to make your merge easy---let me know. > > Philipp > >
On Thu, 9 Feb 2017, Eric Wheeler wrote: > On Fri, 27 Jan 2017, Philipp Hahn wrote: > > > Hello, > > > > Am 27.01.2017 um 00:29 schrieb Eric Wheeler: > > > On Thu, 26 Jan 2017, Paolo Bonzini wrote: > > >> On 26/01/2017 00:50, Eric Wheeler wrote: > > >>> 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs > > >>> 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX > > >>> > > >>> Thus, we need to either: > > >>> 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 > > >>> - or - > > >>> 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. > > >>> > > >>> If you choose the latter options, then please see below for the backport > > >>> patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). > > >>> > > >>> What do you believe would be best? > > >> > > >> The latter is better. Continuing on the Redhat Bugzilla thread, Dr. David Alan Gilbert noted that we also need to cherry-pick this commit: b0996ae48 https://bugzilla.redhat.com/show_bug.cgi?id=1408333 To re-summerize, these commits need pulled into 4.1 for KVM migration to be stable: 1. 609e36d372a 2. 81b1b9ca6d5 [see backport patch in the first message of this thread] 3. b0996ae48 -Eric > > >> Paolo > > > > > > Hi Greg, > > > > 4.1 is maintained by Sasha Levin <alexander.levin@verizon.com>, cc-ed. > > Thank you Philipp! > > > > Paolo suggests cherry-picking the dependent commits with the backport > > > patch instead of reverting the original patch. Do you need anything more > > > in this thread to bring this into v4.1.y? > > Sasha, do you need anything more to pull this into 4.1? > > Thanks! > > > -- > Eric Wheeler > > > > > > > > Its an "Option 3" according to Documentation/stable_kernel_rules.txt with > > > dependent commits so I'm not sure if you want this formatted any > > > differently to make your merge easy---let me know. > > > > Philipp > > > > >
On Wed, 2017-01-25 at 15:50 -0800, Eric Wheeler wrote: > Hello All, > > We discovered guests hanging when using the 4.1.y kernel after 4.1.16 with > live migration after CentOS applied this patch to the latest version of > qemu-kvm user space: > https://git.centos.org/blob/rpms!!qemu-kvm.git/34b32196890e2c41b0aee042e600ba422f29db17/SOURCES!kvm-target-i386-get-put-MSR_TSC_AUX-across-reset-and-mig.patch > > Please also see this Bugzilla entry: > https://bugzilla.redhat.com/show_bug.cgi?id=1408333 > > After a bisect, We found this commit to be causing the hang: > 8a3185c54d650a86dafc8d8bcafa124b50944315 KVM: x86: expose MSR_TSC_AUX to userspace > > It turns out that this is not actually the problem, but rather these > commits need to be pulled in as well to support the 8a31 commit: > 609e36d372a KVM: x86: pass host_initiated to functions that read MSRs > 81b1b9ca6d5 KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX > > Thus, we need to either: > 1. Revert commit 8a3185c54d650a86dafc8d8bcafa124b50944315 > - or - > 2. Merge commits 609e36d372a and 81b1b9ca6d5 into 4.1.y. > > If you choose the latter options, then please see below for the backport > patch of 81b1b9ca6d5 (609e36d372a cherry-picks just fine). > > What do you believe would be best? For 3.2 and 3.16, I will revert the change. Thanks for tracking this down. Ben.
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 341ea55..6b219a7 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2697,7 +2697,7 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata) data = vcpu->arch.ia32_xss; break; case MSR_TSC_AUX: - if (!to_vmx(vcpu)->rdtscp_enabled) + if (!to_vmx(vcpu)->rdtscp_enabled && !msr_info->host_initiated) return 1; /* Otherwise falls through */ default: @@ -2804,7 +2804,7 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) clear_atomic_switch_msr(vmx, MSR_IA32_XSS); break; case MSR_TSC_AUX: - if (!vmx->rdtscp_enabled) + if (!vmx->rdtscp_enabled && !msr_info->host_initiated) return 1; /* Check reserved bit, higher 32 bits should be zero */ if ((data >> 32) != 0)