On 12/01/2014 05:00 PM, Borislav Petkov wrote:
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()->load_ucode_ap()
->check_loader_disabled_ap())
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
---
arch/x86/kernel/cpu/microcode/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 2ce9051..ebd232d 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -557,7 +557,7 @@ static int __init microcode_init(void)
struct cpuinfo_x86 *c = &cpu_data(0);
int error;
- if (dis_ucode_ldr)
+ if (paravirt_enabled() || dis_ucode_ldr)
Ok, let me make sure I understand this correctly: The early path doesn't
get executed on paravirt, i.e. the path along load_ucode_intel_ap()?
(+KVM folks here as well)
Xen PV doesn't start with startup_32()/startup_32_smp() so for Xen this
is true. Don't know about KVM (or lguest).
And you want to avoid loading of the microcode driver because the only
path we come to load_ucode_ap() on paravirt is the hotplug notifier?
That's my understanding, yes.
Btw, we've applied another fix today for 3.18 final which limits the
microcode reloading to 64-bit only:
http://git.kernel.org/tip/02ecc41abcea4ff9291d548f6f846b29b354ddd2
which should accidentally fix the paravirt issue too, no?
I think so. The problem we have now is __pa() macro that we only use on
32-bit. I'll queue this for overnight tests to make sure and if it
indeed works then 3.19 should be fine.
Thanks.
-boris
Because if so, I'd like to delay your patch for the 3.19 merge window
unless absolutely necessary.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html