* [Xen-devel] Xen backports @ 2019-07-16 12:27 Andrew Cooper 2019-07-19 13:53 ` Jan Beulich 0 siblings, 1 reply; 3+ messages in thread From: Andrew Cooper @ 2019-07-16 12:27 UTC (permalink / raw) To: xen-devel; +Cc: Jan Beulich Hello, After re-syncing the XenServer patchqueue against Xen 4.12, I think the following patches are candidates for backport. Bugfixes: 65c165d6595f - x86/xstate: Don't special case feature collection 013896cb8b2f - x86/msr: Fix handling of MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV 7d161f653755 - x86/svm: Fix svm_vmcb_dump() when used in current context 9b757bdc1794 - x86/boot: Don't leak the module_map allocation in __start_xen() The backport for the microcode MSR is rather tricky to rebase over the x86_vendor bitmap changes. I've already got it locally. Enhancements: 787619a0640e - tools: re-sync CPUID leaf 7 tables (perhaps only the xen-cpuid bits.) 260acc521db4 - x86/clear_page: Update clear_page_sse2() after dropping 32bit Xen 564d261687c0 - x86/ctxt-switch: Document and improve GDT handling Altp2m: While altp2m isn't supported yet, it would be very helpful to two downstreams to take these fixes while we work on getting it fully supported. 44f3c3cdd315 - x86/altp2m: treat view 0 as the hostp2m in p2m_get_mem_access() 8228577ad1ba - x86/hvm: Fix altp2m_op hypercall continuations 9abcac7ff145 - x86/altp2m: cleanup p2m_altp2m_lazy_copy df4e4cafd28d - x86/altp2m: Fix style errors introduced with c/s 9abcac7ff ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] Xen backports 2019-07-16 12:27 [Xen-devel] Xen backports Andrew Cooper @ 2019-07-19 13:53 ` Jan Beulich 2019-07-19 14:12 ` Andrew Cooper 0 siblings, 1 reply; 3+ messages in thread From: Jan Beulich @ 2019-07-19 13:53 UTC (permalink / raw) To: Andrew Cooper; +Cc: xen-devel On 16.07.2019 14:27, Andrew Cooper wrote: > Bugfixes: > > 65c165d6595f - x86/xstate: Don't special case feature collection > 013896cb8b2f - x86/msr: Fix handling of > MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV > 7d161f653755 - x86/svm: Fix svm_vmcb_dump() when used in current context > 9b757bdc1794 - x86/boot: Don't leak the module_map allocation in > __start_xen() > > The backport for the microcode MSR is rather tricky to rebase over the > x86_vendor bitmap changes. I've already got it locally. Not overly tricky I would say, but requiring attention. While doing this I've run into two questions: 1) Was it really a good idea to remove the write to the MSR and the CPUID invocation from the read path? The comment says 'A guest might itself perform the "write 0, CPUID, read" sequence', but that won't help at all if the specific vCPU gets re-scheduled in the middle. And there may not have been any ucode load we've done, which we could then guarantee was followed by a CPUID invocation. 2) We still haven't got confirmation that Hygon behaves the same ucode- wise, have we? > Enhancements: > > 787619a0640e - tools: re-sync CPUID leaf 7 tables (perhaps only the > xen-cpuid bits.) > 260acc521db4 - x86/clear_page: Update clear_page_sse2() after dropping > 32bit Xen > 564d261687c0 - x86/ctxt-switch: Document and improve GDT handling The last one doesn't even come close to applying, due to its dependency on 12dce7ea5a. While I think that's a little too much, I've still decided to pull in both (but for now I'll perhaps do this only for 4.12) in anticipation of us wanting to at least consider a backport of the core scheduling series (assuming it won't take too long to get fully ready). > Altp2m: While altp2m isn't supported yet, it would be very helpful to > two downstreams to take these fixes while we work on getting it fully > supported. > > 44f3c3cdd315 - x86/altp2m: treat view 0 as the hostp2m in > p2m_get_mem_access() > 8228577ad1ba - x86/hvm: Fix altp2m_op hypercall continuations > 9abcac7ff145 - x86/altp2m: cleanup p2m_altp2m_lazy_copy > df4e4cafd28d - x86/altp2m: Fix style errors introduced with c/s 9abcac7ff I'll apply all of these soon. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Xen-devel] Xen backports 2019-07-19 13:53 ` Jan Beulich @ 2019-07-19 14:12 ` Andrew Cooper 0 siblings, 0 replies; 3+ messages in thread From: Andrew Cooper @ 2019-07-19 14:12 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On 19/07/2019 14:53, Jan Beulich wrote: > On 16.07.2019 14:27, Andrew Cooper wrote: >> Bugfixes: >> >> 65c165d6595f - x86/xstate: Don't special case feature collection >> 013896cb8b2f - x86/msr: Fix handling of >> MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV >> 7d161f653755 - x86/svm: Fix svm_vmcb_dump() when used in current context >> 9b757bdc1794 - x86/boot: Don't leak the module_map allocation in >> __start_xen() >> >> The backport for the microcode MSR is rather tricky to rebase over the >> x86_vendor bitmap changes. I've already got it locally. > Not overly tricky I would say, but requiring attention. While doing > this I've run into two questions: > > 1) Was it really a good idea to remove the write to the MSR and the > CPUID invocation from the read path? The comment says 'A guest might > itself perform the "write 0, CPUID, read" sequence', but that won't > help at all if the specific vCPU gets re-scheduled in the middle. And > there may not have been any ucode load we've done, which we could > then guarantee was followed by a CPUID invocation. You asked the same on the original patch. The "write 0, CPUID" is a bodge for the P5 which had to introduce the UCODE_REV MSR in microcode, in a compatible fashion. The write 0 is unnecessary on all subsequent processors. All that matters, for any CPU Xen will boot on, is that a CPUID instruction has executed previously on the current CPU, which is guaranteed by our AP boot logic, even if we haven't explicitly loaded microcode. > 2) We still haven't got confirmation that Hygon behaves the same ucode- > wise, have we? Until we get an answer to the question, I'm trust treating Hygon as "no microcode facilities". > >> Enhancements: >> >> 787619a0640e - tools: re-sync CPUID leaf 7 tables (perhaps only the >> xen-cpuid bits.) >> 260acc521db4 - x86/clear_page: Update clear_page_sse2() after dropping >> 32bit Xen >> 564d261687c0 - x86/ctxt-switch: Document and improve GDT handling > The last one doesn't even come close to applying, due to its dependency > on 12dce7ea5a. While I think that's a little too much, I've still > decided to pull in both (but for now I'll perhaps do this only for 4.12) > in anticipation of us wanting to at least consider a backport of the > core scheduling series (assuming it won't take too long to get fully > ready). > >> Altp2m: While altp2m isn't supported yet, it would be very helpful to >> two downstreams to take these fixes while we work on getting it fully >> supported. >> >> 44f3c3cdd315 - x86/altp2m: treat view 0 as the hostp2m in >> p2m_get_mem_access() >> 8228577ad1ba - x86/hvm: Fix altp2m_op hypercall continuations >> 9abcac7ff145 - x86/altp2m: cleanup p2m_altp2m_lazy_copy >> df4e4cafd28d - x86/altp2m: Fix style errors introduced with c/s 9abcac7ff > I'll apply all of these soon. Thanks, ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-19 14:12 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-07-16 12:27 [Xen-devel] Xen backports Andrew Cooper 2019-07-19 13:53 ` Jan Beulich 2019-07-19 14:12 ` Andrew Cooper
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.