[Xen-devel] Xen backports

[Xen-devel] Xen backports

[Andrew Cooper]

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

Re: [Xen-devel] Xen backports

[Jan Beulich]

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

Re: [Xen-devel] Xen backports

[Andrew Cooper]

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