Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
On Tue, Dec 02, 2014 at 09:36:40AM -0500, Boris Ostrovsky wrote: > All tests passed. Thanks! > I wonder whether we should prevent all guests (not just paravirt) from > loading microcode driver (and from doing early microcode loading). I don't think the unmodified ones need to. At least I haven't seen any issues so far. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
On 12/01/2014 05:37 PM, Borislav Petkov wrote: On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote: 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. Cool, thanks. All tests passed. I'd still take your patch for 3.19 though because I'm fixing the 32-bit reloading path properly and will remove the ifdef afterwards. And even then, I'd like to prevent loading the module on a paravirt guest if it is totally unneeded there. I wonder whether we should prevent all guests (not just paravirt) from loading microcode driver (and from doing early microcode loading). -boris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote: > 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. Cool, thanks. I'd still take your patch for 3.19 though because I'm fixing the 32-bit reloading path properly and will remove the ifdef afterwards. And even then, I'd like to prevent loading the module on a paravirt guest if it is totally unneeded there. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
On Mon, Dec 01, 2014 at 11:12:38PM +0100, Paolo Bonzini wrote: > We also do not want to load microcode. :) Thanks for the heads-up. You don't need to :P -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
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 --- 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 kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
On 01/12/2014 22:57, Konrad Rzeszutek Wilk 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. > > CC-ing the KVM folks since they use the paravirt interface too. We also do not want to load microcode. :) Thanks for the heads-up. Acked-by: Paolo Bonzini Paolo >> 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 >> --- >> 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) >> return 0; >> >> if (c->x86_vendor == X86_VENDOR_INTEL) >> -- >> 1.7.1 >> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, microcode: Don't initialize microcode code on paravirt
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. CC-ing the KVM folks since they use the paravirt interface too. > > 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 > --- > 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) > return 0; > > if (c->x86_vendor == X86_VENDOR_INTEL) > -- > 1.7.1 > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
