Re: [Xen-devel] Xen backports

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel