On Fri, Dec 16, 2016 at 09:40:59AM -0500, Boris Ostrovsky wrote:
> It works
Thanks. Added your Tested-by.
> but I think both of the bugs we talked about yesterday still
> need to be fixed, they are not related to Xen.
For the one issue with the eq_id, I have the below cleanup for all the
args pa
On 12/16/2016 08:07 AM, Borislav Petkov wrote:
> On Fri, Dec 16, 2016 at 01:19:03PM +0100, Borislav Petkov wrote:
>>> Okay. Results:
>>>
>>> Xen HVM domain is working.
>>> Xen dom0 is working.
>>> Bare metal is working, microcode has been loaded.
>>>
>>> So you can add my:
>>>
>>> Tested-by: Juerge
On Fri, Dec 16, 2016 at 01:19:03PM +0100, Borislav Petkov wrote:
> > Okay. Results:
> >
> > Xen HVM domain is working.
> > Xen dom0 is working.
> > Bare metal is working, microcode has been loaded.
> >
> > So you can add my:
> >
> > Tested-by: Juergen Gross
> > Acked-by: Juergen Gross
>
> Tha
On Fri, Dec 16, 2016 at 01:15:56PM +0100, Juergen Gross wrote:
> On 16/12/16 11:45, Borislav Petkov wrote:
> > On Fri, Dec 16, 2016 at 11:00:29AM +0100, Juergen Gross wrote:
> >> Should work. I'm happy to test any patch. :-)
> >
> > I'm happy that you're happy to! :-)
>
> That makes me happy. :-D
On 16/12/16 11:45, Borislav Petkov wrote:
> On Fri, Dec 16, 2016 at 11:00:29AM +0100, Juergen Gross wrote:
>> Should work. I'm happy to test any patch. :-)
>
> I'm happy that you're happy to! :-)
That makes me happy. :-D
> Let's try this below.
Okay. Results:
Xen HVM domain is working.
Xen dom
On Fri, Dec 16, 2016 at 11:00:29AM +0100, Juergen Gross wrote:
> Should work. I'm happy to test any patch. :-)
I'm happy that you're happy to! :-)
Let's try this below.
Thanks!
---
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index 6996413c78c3..c4bb
On 16/12/16 10:43, Borislav Petkov wrote:
> On Fri, Dec 16, 2016 at 10:20:42AM +0100, Juergen Gross wrote:
>> Without testing, but I doubt it is working. As pv guests aren't coming
>> through check_loader_disabled_bsp() at all I can't see why your patch
>> would work for dom0.
>
> Do they go throu
On Fri, Dec 16, 2016 at 10:20:42AM +0100, Juergen Gross wrote:
> Without testing, but I doubt it is working. As pv guests aren't coming
> through check_loader_disabled_bsp() at all I can't see why your patch
> would work for dom0.
Do they go through check_loader_disabled_ap() ?
> Additionally I d
On 16/12/16 10:02, Borislav Petkov wrote:
> On Fri, Dec 16, 2016 at 08:28:46AM +0100, Juergen Gross wrote:
>> Not trying to load ucode in _any_ guest is an optimization only.
>
> Does the hunk below work too?
Without testing, but I doubt it is working. As pv guests aren't coming
through check_loa
On 16/12/2016 09:01, Borislav Petkov wrote:
> @@ -91,6 +92,17 @@ static bool __init check_loader_disabled_bsp(void)
> if (cmdline_find_option_bool(cmdline, option))
> *res = true;
>
> + if (!have_cpuid_p())
> + *res = true;
> +
> + a = 1;
> + c = 0;
> +
On Fri, Dec 16, 2016 at 08:28:46AM +0100, Juergen Gross wrote:
> Not trying to load ucode in _any_ guest is an optimization only.
Does the hunk below work too?
I don't want to do hypervisor-specific solutions.
---
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode
On Thu, Dec 15, 2016 at 10:56:25PM -0500, Boris Ostrovsky wrote:
> You can use xen_cpuid_base(), for example. It will prevent microcode loading
Actually I want to do this at the end. CPUID(1).ECX[31] is reserved by
both vendors for hypervisor use.
> True. But I don't think it's clear that the pro
On 15/12/16 18:36, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
>
> Lemme tell you want I want:
On Fri, 16 Dec 2016, Borislav Petkov wrote:
> What for? We don't want to run the microcode loader on xen at all.
Or under KVM, or any other hypervisor, really.
--
Henrique Holschuh
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen
On 12/15/2016 06:04 PM, Borislav Petkov wrote:
On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
call via a pointer, you can see it, for example, if you disassemble
load_ucode_amd_bsp(). And we don't have pagi
On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
> With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
> call via a pointer, you can see it, for example, if you disassemble
> load_ucode_amd_bsp(). And we don't have paging on yet when we call
> load_ucode_amd_bsp (a
On 12/15/2016 03:03 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
>> We are calling find_proper_container(..., &eq_id) and determine result
>> based on eq_id not being zero. If find_proper_container() doesn't find
>> anything it will not modify eq_id
On Thu, Dec 15, 2016 at 02:36:46PM -0500, Boris Ostrovsky wrote:
> We are calling find_proper_container(..., &eq_id) and determine result
> based on eq_id not being zero. If find_proper_container() doesn't find
> anything it will not modify eq_id and so you get back whatever you
> passed in.
The c
On 12/15/2016 02:23 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
>> This fixes my PV boot problem. I am still failing to boot HVM, will
>> need to look at this some more.
> No, no more stabbing in the dark and no more brown paper bags.
This fixes a
On Thu, Dec 15, 2016 at 02:08:50PM -0500, Boris Ostrovsky wrote:
> This fixes my PV boot problem. I am still failing to boot HVM, will
> need to look at this some more.
No, no more stabbing in the dark and no more brown paper bags.
Please check whether CPUID(4) works that early in any xen guest a
On 12/15/2016 12:36 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
>> It will probably fix it but I don't think we want this: it's a
>> build-time solution. Most kernels have XEN on even though they are
>> booted bare-metal.
> Lemme tell you want I wan
On Thu, Dec 15, 2016 at 12:27:49PM -0500, Boris Ostrovsky wrote:
> It will probably fix it but I don't think we want this: it's a
> build-time solution. Most kernels have XEN on even though they are
> booted bare-metal.
Lemme tell you want I want: a way to detect I'm running on xen. Does
CPUID(4)
On 12/15/2016 12:17 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
>> There is an error on AMD as well. We end up being called at
>> load_microcode_amd() with size=0 and crash soon after.
> Does that fix it?
>
> diff --git a/arch/x86/Kconfig b/arch/x86
On Thu, Dec 15, 2016 at 12:00:22PM -0500, Boris Ostrovsky wrote:
> There is an error on AMD as well. We end up being called at
> load_microcode_amd() with size=0 and crash soon after.
Does that fix it?
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dd47e60aabf5..e238119b5dff 100644
--- a/
On Thu, Dec 15, 2016 at 04:59:49PM +, Andrew Cooper wrote:
> Xen has the same logic as Linux does to look for an uncompressed
> microcode blob in the initrd and apply it early in boot.
>
> If dom0 goes looking, it should see the same microcode version as it has
> in its initrd.
So it sounds t
On 15/12/16 17:46, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
>
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode
On 15/12/16 16:53, Jan Beulich wrote:
On 15.12.16 at 17:46, wrote:
>> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>>> with today's kernel the system isn't coming up when booted as Xen dom0:
>> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
>> hyperv
On 12/15/2016 11:46 AM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microco
>>> On 15.12.16 at 17:46, wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
>
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
Yes,
On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
> with today's kernel the system isn't coming up when booted as Xen dom0:
Remind me again pls, is dom0 even supposed to load microcode? Isn't the
hypervisor supposed to apply microcode?
> Looking into the state of cpu 1 I find the fol
Boris,
with today's kernel the system isn't coming up when booted as Xen dom0:
[ 33.575326] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
[swapper/0:1]
[ 33.589795] Modules linked in:
[ 33.596015] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-pv+ #687
[ 33.608844] Hardware name:
31 matches
Mail list logo
