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
