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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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()?
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?
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?
Because if so, I'd like to delay your patch for the 3.19 merge window
unless absolutely necessary.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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 <[email protected]>
> ---
> 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
>
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 <[email protected]>
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 <[email protected]>
>> ---
>> 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
>>
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 <[email protected]>
>> ---
>> 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.
>
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.
--
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.
--
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 <[email protected]>
> ---
> arch/x86/kernel/cpu/microcode/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
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
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.
Commit-ID: a18a0f6850d4b286a5ebf02cd5b22fe496b86349
Gitweb: http://git.kernel.org/tip/a18a0f6850d4b286a5ebf02cd5b22fe496b86349
Author: Boris Ostrovsky <[email protected]>
AuthorDate: Mon, 1 Dec 2014 16:27:44 -0500
Committer: Borislav Petkov <[email protected]>
CommitDate: Sat, 6 Dec 2014 12:59:03 +0100
x86, microcode: Don't initialize microcode code on paravirt
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 <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Borislav Petkov <[email protected]>
---
arch/x86/kernel/cpu/microcode/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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)