All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen backports
Date: Fri, 19 Jul 2019 13:53:19 +0000	[thread overview]
Message-ID: <aefbb38a-430e-e712-e17e-40d6946de5cc@suse.com> (raw)
In-Reply-To: <3f24285c-b984-1dc5-7783-a1604a966bd0@citrix.com>

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

  reply	other threads:[~2019-07-19 13:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 12:27 [Xen-devel] Xen backports Andrew Cooper
2019-07-19 13:53 ` Jan Beulich [this message]
2019-07-19 14:12   ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aefbb38a-430e-e712-e17e-40d6946de5cc@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.