* [MODERATED] [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
@ 2018-05-17 3:18 konrad.wilk
2018-05-18 8:20 ` [MODERATED] " Greg KH
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: konrad.wilk @ 2018-05-17 3:18 UTC (permalink / raw)
To: speck
Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
needed to correctly initialize __supported_pte_mask. Doing this so early
in the boot can be dangerous --- while this currently works, there is no
telling what get_cpu_cap() may decide to add in the future. For example,
if it decides to do a printk (which is not something impossible to
imagine) a PV guest will not be able to cope with it.
To avoid these problems check CPUID explicitly for NX support and
open-code setting __supported_pte_mask.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
arch/x86/xen/enlighten_pv.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c36d23aa6c35..f9f892488670 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -88,8 +88,6 @@
#include "multicalls.h"
#include "pmu.h"
-#include "../kernel/cpu/cpu.h" /* get_cpu_cap() */
-
void *xen_initial_gdt;
static int xen_cpu_up_prepare_pv(unsigned int cpu);
@@ -1253,6 +1251,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
/* Prevent unwanted bits from being set in PTEs. */
__supported_pte_mask &= ~_PAGE_GLOBAL;
+ /* Work out if we support NX. */
+ if ((cpuid_eax(0x80000000) >= 0x80000001) &&
+ (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31))))
+ __supported_pte_mask |= _PAGE_NX;
+ else
+ __supported_pte_mask &= ~_PAGE_NX;
+
/*
* Prevent page tables from being allocated in highmem, even
* if CONFIG_HIGHPTE is enabled.
@@ -1268,10 +1273,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
*/
xen_setup_gdt(0);
- /* Work out if we support NX */
- get_cpu_cap(&boot_cpu_data);
- x86_configure_nx();
-
xen_init_irq_ops();
/* Let's presume PV guests always boot on vCPU with id 0. */
--
2.14.3
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-17 3:18 [MODERATED] [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 konrad.wilk
@ 2018-05-18 8:20 ` Greg KH
2018-05-18 9:02 ` Thomas Gleixner
2018-05-18 11:46 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 9:14 ` Thomas Gleixner
2018-05-18 13:21 ` Greg KH
2 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2018-05-18 8:20 UTC (permalink / raw)
To: speck
On Wed, May 16, 2018 at 11:18:10PM -0400, speck for konrad.wilk_at_oracle.com wrote:
> xen: Don't call non-Xen routines early in the boot
>
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> needed to correctly initialize __supported_pte_mask. Doing this so early
> in the boot can be dangerous --- while this currently works, there is no
> telling what get_cpu_cap() may decide to add in the future. For example,
> if it decides to do a printk (which is not something impossible to
> imagine) a PV guest will not be able to cope with it.
>
> To avoid these problems check CPUID explicitly for NX support and
> open-code setting __supported_pte_mask.
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> arch/x86/xen/enlighten_pv.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index c36d23aa6c35..f9f892488670 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -88,8 +88,6 @@
> #include "multicalls.h"
> #include "pmu.h"
>
> -#include "../kernel/cpu/cpu.h" /* get_cpu_cap() */
> -
> void *xen_initial_gdt;
>
> static int xen_cpu_up_prepare_pv(unsigned int cpu);
> @@ -1253,6 +1251,13 @@ asmlinkage __visible void __init xen_start_kernel(void)
> /* Prevent unwanted bits from being set in PTEs. */
> __supported_pte_mask &= ~_PAGE_GLOBAL;
>
> + /* Work out if we support NX. */
> + if ((cpuid_eax(0x80000000) >= 0x80000001) &&
> + (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31))))
> + __supported_pte_mask |= _PAGE_NX;
> + else
> + __supported_pte_mask &= ~_PAGE_NX;
> +
> /*
> * Prevent page tables from being allocated in highmem, even
> * if CONFIG_HIGHPTE is enabled.
> @@ -1268,10 +1273,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
> */
> xen_setup_gdt(0);
>
> - /* Work out if we support NX */
> - get_cpu_cap(&boot_cpu_data);
> - x86_configure_nx();
> -
> xen_init_irq_ops();
>
> /* Let's presume PV guests always boot on vCPU with id 0. */
> --
> 2.14.3
Why is this a part of this series? Shouldn't this just go into the tree
through the "normal" patch process if this really is an issue? And if
so, please cc: stable as the patch you are trying to "fix" here has been
backported already to stable kernel releases.
I really hate the "open coding" here though, it feels odd that the xen
developers feel that it is needed and they can't trust the fact that
since the kernel works fine today with this, it will continue to work ok
in the future (and if it breaks then, great, we can fix it...)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 8:20 ` [MODERATED] " Greg KH
@ 2018-05-18 9:02 ` Thomas Gleixner
2018-05-18 11:46 ` [MODERATED] " Konrad Rzeszutek Wilk
1 sibling, 0 replies; 15+ messages in thread
From: Thomas Gleixner @ 2018-05-18 9:02 UTC (permalink / raw)
To: speck
On Fri, 18 May 2018, speck for Greg KH wrote:
> On Wed, May 16, 2018 at 11:18:10PM -0400, speck for konrad.wilk_at_oracle.com wrote:
>
> Why is this a part of this series? Shouldn't this just go into the tree
> through the "normal" patch process if this really is an issue? And if
> so, please cc: stable as the patch you are trying to "fix" here has been
> backported already to stable kernel releases.
Yes, it's independent of SSB and should go the normal route.
Thanks,
tglx
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-17 3:18 [MODERATED] [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 konrad.wilk
2018-05-18 8:20 ` [MODERATED] " Greg KH
@ 2018-05-18 9:14 ` Thomas Gleixner
2018-05-18 11:43 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 13:21 ` Greg KH
2 siblings, 1 reply; 15+ messages in thread
From: Thomas Gleixner @ 2018-05-18 9:14 UTC (permalink / raw)
To: speck
On Wed, 16 May 2018, speck for konrad.wilk_at_oracle.com wrote:
> xen: Don't call non-Xen routines early in the boot
>
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> needed to correctly initialize __supported_pte_mask. Doing this so early
> in the boot can be dangerous --- while this currently works, there is no
> telling what get_cpu_cap() may decide to add in the future. For example,
> if it decides to do a printk (which is not something impossible to
> imagine) a PV guest will not be able to cope with it.
So this is not an issue today and I don't see a reason why you need to add
open coded hackery.
> + /* Work out if we support NX. */
> + if ((cpuid_eax(0x80000000) >= 0x80000001) &&
> + (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31))))
> + __supported_pte_mask |= _PAGE_NX;
> + else
> + __supported_pte_mask &= ~_PAGE_NX;
> +
And of course this open coded hack is not a 1:1 replacement for
x86_configure_nx().
So can you please explain what kind of problem you are trying to solve?
AFAICT from the changelog it's just the 'someone might add a printk'
fear. Come on, that's silly. If that happens its going to be caught in next
early enough to fix it.
And if it's really an issue, then the proper fix is to have a common
function in the cpu ident code which handles this and not that open coded
hackery just because we can.
Thanks,
tglx
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 9:14 ` Thomas Gleixner
@ 2018-05-18 11:43 ` Konrad Rzeszutek Wilk
2018-05-18 12:03 ` Greg KH
0 siblings, 1 reply; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-05-18 11:43 UTC (permalink / raw)
To: speck
On Fri, May 18, 2018 at 11:14:51AM +0200, speck for Thomas Gleixner wrote:
> On Wed, 16 May 2018, speck for konrad.wilk_at_oracle.com wrote:
>
> > xen: Don't call non-Xen routines early in the boot
> >
> > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> > to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> > needed to correctly initialize __supported_pte_mask. Doing this so early
> > in the boot can be dangerous --- while this currently works, there is no
> > telling what get_cpu_cap() may decide to add in the future. For example,
> > if it decides to do a printk (which is not something impossible to
> > imagine) a PV guest will not be able to cope with it.
>
> So this is not an issue today and I don't see a reason why you need to add
> open coded hackery.
>
> > + /* Work out if we support NX. */
> > + if ((cpuid_eax(0x80000000) >= 0x80000001) &&
> > + (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31))))
> > + __supported_pte_mask |= _PAGE_NX;
> > + else
> > + __supported_pte_mask &= ~_PAGE_NX;
> > +
>
> And of course this open coded hack is not a 1:1 replacement for
> x86_configure_nx().
>
> So can you please explain what kind of problem you are trying to solve?
This SSB patch series makes Xen PV guests crash.
>
> AFAICT from the changelog it's just the 'someone might add a printk'
> fear. Come on, that's silly. If that happens its going to be caught in next
> early enough to fix it.
That is more of a obfuscation in case you would like this particular patch
go through the not-secure-channel.
>
> And if it's really an issue, then the proper fix is to have a common
> function in the cpu ident code which handles this and not that open coded
> hackery just because we can.
Which they had in mind except they expected push back from you. I will relay
your OK with that approach.
>
> Thanks,
>
> tglx
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 8:20 ` [MODERATED] " Greg KH
2018-05-18 9:02 ` Thomas Gleixner
@ 2018-05-18 11:46 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-05-18 11:46 UTC (permalink / raw)
To: speck
> > 2.14.3
>
> Why is this a part of this series? Shouldn't this just go into the tree
> through the "normal" patch process if this really is an issue? And if
> so, please cc: stable as the patch you are trying to "fix" here has been
> backported already to stable kernel releases.
It certainly can; I thought it made more sense to have it as part of this
series as this series is the one that git bisection is going to finger.
>
> I really hate the "open coding" here though, it feels odd that the xen
> developers feel that it is needed and they can't trust the fact that
> since the kernel works fine today with this, it will continue to work ok
> in the future (and if it breaks then, great, we can fix it...)
The open coding was done b/c they expected push back from Thomas on doing
the proper fix and instead ended with band-aid solution in their back-yard.
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 11:43 ` [MODERATED] " Konrad Rzeszutek Wilk
@ 2018-05-18 12:03 ` Greg KH
0 siblings, 0 replies; 15+ messages in thread
From: Greg KH @ 2018-05-18 12:03 UTC (permalink / raw)
To: speck
On Fri, May 18, 2018 at 07:43:45AM -0400, speck for Konrad Rzeszutek Wilk wrote:
> On Fri, May 18, 2018 at 11:14:51AM +0200, speck for Thomas Gleixner wrote:
> > On Wed, 16 May 2018, speck for konrad.wilk_at_oracle.com wrote:
> >
> > > xen: Don't call non-Xen routines early in the boot
> > >
> > > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> > > to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> > > needed to correctly initialize __supported_pte_mask. Doing this so early
> > > in the boot can be dangerous --- while this currently works, there is no
> > > telling what get_cpu_cap() may decide to add in the future. For example,
> > > if it decides to do a printk (which is not something impossible to
> > > imagine) a PV guest will not be able to cope with it.
> >
> > So this is not an issue today and I don't see a reason why you need to add
> > open coded hackery.
> >
> > > + /* Work out if we support NX. */
> > > + if ((cpuid_eax(0x80000000) >= 0x80000001) &&
> > > + (cpuid_edx(0x80000001) & (1U << (X86_FEATURE_NX & 31))))
> > > + __supported_pte_mask |= _PAGE_NX;
> > > + else
> > > + __supported_pte_mask &= ~_PAGE_NX;
> > > +
> >
> > And of course this open coded hack is not a 1:1 replacement for
> > x86_configure_nx().
> >
> > So can you please explain what kind of problem you are trying to solve?
>
> This SSB patch series makes Xen PV guests crash.
Which exact patch causes the crash? Why not fix that one up instead to
not break things.
That seems like a wiser thing to do instead of papering over it later on
in a patch series to be applied at some later date.
> > AFAICT from the changelog it's just the 'someone might add a printk'
> > fear. Come on, that's silly. If that happens its going to be caught in next
> > early enough to fix it.
>
> That is more of a obfuscation in case you would like this particular patch
> go through the not-secure-channel.
As this is a "secure channel", you are causing confusion here :(
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-17 3:18 [MODERATED] [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 konrad.wilk
2018-05-18 8:20 ` [MODERATED] " Greg KH
2018-05-18 9:14 ` Thomas Gleixner
@ 2018-05-18 13:21 ` Greg KH
2018-05-18 18:22 ` Konrad Rzeszutek Wilk
2 siblings, 1 reply; 15+ messages in thread
From: Greg KH @ 2018-05-18 13:21 UTC (permalink / raw)
To: speck
On Wed, May 16, 2018 at 11:18:10PM -0400, speck for konrad.wilk_at_oracle.com wrote:
> xen: Don't call non-Xen routines early in the boot
>
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> needed to correctly initialize __supported_pte_mask. Doing this so early
> in the boot can be dangerous --- while this currently works, there is no
> telling what get_cpu_cap() may decide to add in the future. For example,
> if it decides to do a printk (which is not something impossible to
> imagine) a PV guest will not be able to cope with it.
Wait, how does this break? Does the guest kernel just crash
(hopefully), or does this mess with the host kernel?
confused,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 13:21 ` Greg KH
@ 2018-05-18 18:22 ` Konrad Rzeszutek Wilk
2018-05-18 19:57 ` Thomas Gleixner
0 siblings, 1 reply; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-05-18 18:22 UTC (permalink / raw)
To: speck
On Fri, May 18, 2018 at 03:21:54PM +0200, speck for Greg KH wrote:
> On Wed, May 16, 2018 at 11:18:10PM -0400, speck for konrad.wilk_at_oracle.com wrote:
> > xen: Don't call non-Xen routines early in the boot
> >
> > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") added a call
> > to get_cpu_cap() to properly set boot_cpu_has(X86_FEATURE_NX) which is
> > needed to correctly initialize __supported_pte_mask. Doing this so early
> > in the boot can be dangerous --- while this currently works, there is no
> > telling what get_cpu_cap() may decide to add in the future. For example,
> > if it decides to do a printk (which is not something impossible to
> > imagine) a PV guest will not be able to cope with it.
>
> Wait, how does this break? Does the guest kernel just crash
KABOOM!
> (hopefully), or does this mess with the host kernel?
Trying 192.168.106.3...
Connected to maxsrv3.dumpdata.com.
Escape character is '^]'.
^[[25;8H^[[0;37;40m
^[[25;1H^[[1;33;40mfs0:\> ^[[25;8H^[[0;37;40m
^[[25;1H^[[1;33;40mfs0:\> cd efi\xen^[[25;18H^[[0;37;40m
^[[25;1H^[[1;33;40mfs0:\EFI\Xen> xen^[[25;18H^[[0;37;40m
^[[2J^[[1;1HXen 4.11-rc (c/s Tue May 1 09:03:13 2018 +0100 git:0306a13) EFI loader
Using configuration file 'xen.cfg'
vmlinuz-4.14.35-v15.rc2-06540-gf604286: 0x0000000029045000-0x0000000029765110
initramfs-4.14.35-v15.rc2-06540-gf604286.img: 0x0000000024e99000-0x00000000290444f2
0x0000:0x00:0x02.0x0: ROM: 0x10000 bytes at 0x2d0f1018
0x0000:0x3a:0x00.0x0: ROM: 0x10800 bytes at 0x2d0e0018
0x0000:0x00:0x1f Xen 4.11-rc
(XEN) Xen version 4.11-rc (root@dumpdata.com) (gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)) debug=y Wed May 107 EDT 2018
(XEN) Latest ChangeSet: Tue May 1 09:03:13 2018 +0100 git:0306a13
(XEN) Bootloader: EFI
(XEN) Command line: console=vga,com1 com1=115200,8n1 loglvl=all guest_loglvl=all iommu=verbose dom0_mem=max:8G ucode=scan
(XEN) Xen image load base address: 0x29800000
(XEN) Video information:
(XEN) VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 1 EDD information structures
(XEN) EFI RAM map:
(XEN) 0000000000000000 - 0000000000058000 (usable)
(XEN) 0000000000058000 - 0000000000059000 (reserved)
(XEN) 0000000000059000 - 000000000009f000 (usable)
(XEN) 000000000009f000 - 00000000000a0000 (reserved)
(XEN) 0000000000100000 - 000000002adff000 (usable)
(XEN) 000000002adff000 - 000000002ae00000 (ACPI NVS)
(XEN) 000000002ae00000 - 000000002ae4a000 (reserved)
(XEN) 000000002ae4a000 - 000000002e88d000 (usable)
(XEN) 000000002e88d000 - 000000002ec30000 (reserved)
(XEN) 000000002ec30000 - 000000002edab000 (usable)
(XEN) 000000002edab000 - 000000002f3b7000 (ACPI NVS)
(XEN) 000000002f3b7000 - 000000002ffff000 (reserved)
(XEN) 000000002ffff000 - 0000000030000000 (usable)
(XEN) 0000000030000000 - 0000000038000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fe000000 - 00000000fe011000 (reserved)
(XEN) 00000000fec00000 - 00000000fec01000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ff000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 00000008c3400000 (usable)
(XEN) ACPI: RSDP 2EE33000, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 2EE330B0, 00DC (r1 SUPERM SUPERM 1072009 AMI 10013)
(XEN) N) ACPI: FACS 2F3B5F80, 0040
(XEN) ACPI: APIC 2EE566B8, 00BC (r3 1072009 AMI 10013)
(XEN) ACPI: FPDT 2EE56778, 0044 (r1 1072009 AMI 10013)
(XEN) ACPI: FIDT 2EE567C0, 009C (r1 1072009 AMI 10013)
(XEN) ACPI: MCFG 2EE56860, 003C (r1 SUPERM SMCI--MB 1072009 MSFT 97)
(XEN) ACPI: HPET 2EE568A0, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5000B)
(XEN) ACPI: LPIT 2EE568D8, 0094 (r1 INTEL SKL 0 MSFT 5F)
(XEN) ACPI: SSDT 2EE56970, 0248 (r2 INTEL sensrhub 0 INTL 20120913)
(XEN) ACPI: SSDT 2EE56BB8, 2BAE (r2 INTEL PtidDevc 1000 INTL 20120913)
(XEN) ACPI: SSDT 2EE59768, 0BE3 (r2 INTEL Ther_Rvp 1000 INTL 20120913)
(XEN) ACPI: DBGP 2EE5A350, 0034 (r1 INTEL 0 MSFT 5F)
(XEN) ACPI: DBG2 2EE5A388, 0054 (r0 INTEL 0 MSFT 5F)
(XEN) ACPI: SSDT 2EE5A3E0, 06FD (r2 INTEL xh_rvp08 0 INTL 20120913)
(XEN) ACPI: SSDT 2EE5AAE0, 546C (r2 SaSsdt SaSsdt 3000 INTL 20120913)
(XEN) ACPI: UEFI 2EE5FF50, 0042 (r1 0 0)
(XEN) ACPI: SSDT 2EE5FF98, 0E73 (r2 CpuRef CpuSsdt 3000 INTL 20120913)
(XEN) ACPI: DMAR 2EE60E10, 00A8 (r1 INTEL SKL 1 INTL 1)
(XEN) ACPI: ASF! 2EE60EB8, 00A5 (r32 INTEL HCG 1 TFSM F4240)
(XEN) ACPI: EINJ 2EE60F60, 0130 (r1 AMI AMI.EINJ 0 AMI. 0)
(XEN) ACPI: ERST 2EE61090, 0230 (r1 AMIER AMI.ERST 0 AMI. 0)
(XEN) ACPI: BERT 2EE612C0, 0030 (r1 AMI AMI.BERT 0 AMI. 0)
(XEN) ACPI: HEST 2EE612F0, 027C (r1 AMI AMI.HEST 0 AMI. 0)
(XEN) ACPI: BGRT 2EE61570, 0038 (r1 SUPERM SMCI--MB 1072009 AMI 10013)
(XEN) System RAM: 32541MB (33322352kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-00000008c3400000
(XEN) Domain heap initialised
(XEN) vesafb: framebuffer at 0x90000000, mapped to 0xffff82c000201000, using 1920k, total 1920k
(XEN) vesafb: mode is 800x600x3sent.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 2f3b5f80/0000000000000000, using 32
(XEN) ACPI: wakeup_vec[2f3b5f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D]Host address width 39
(XEN) [VT-D]found ACPI_DMAR_DRHD:
(XEN) [VT-D] dmaru->address = fed90000
(XEN) [VT-D]drhd->address = fed90000 iommu->reg = ffff82c0003fc000
(XEN) [VT-D]cap = 1c0000c40660462 ecap = 7e3ff0505e
(XEN) [VT-D] endpoint: 0000:00:02.0
(XEN) [VT-D]found ACPI_DMAR_DRHD:
(XEN) [VT-D] dmaru->address = fed91000
(XEN) [VT-D]drhd->address = fed91000 iommu->reg = ffff82c0003fe000
(XEN) [VT-D]cap = d2008c40660462 ecap = f050da
(XEN) [VT-D] IOAPIC: 0000:f0:1f.0
(XEN) [VT-D] MSI HPET: 0000:00:1f.0
(XEN) [VT-D] flags: INCLUDE_ALL
(XEN) [VT-D]found ACPI_DMAR_RMRR:
(XEN) [VT-D] endpoint: 0000:00:14.0
(XEN) [VT-D]dmar.c:638: RMRR region: base_addr 2e977000 end_addr 2e996fff
(XEN) [VT-D]found ACPI_DMAR_RMRR:
(XEN) [VT-D] RMRR address range 38400000..3abfffff not in reserved memory; need "iommu_inclusive_mapping=1"?
(XEN) [VT-D] endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:638: RMRR region: base_addr 38400000 end_addr 3abfffff
(XEN) Xen ERST support is initialized.
(XEN) HEST: Table parsing has been initialized
(XEN) ACPI: BGRT: invalidating v1 image at 0x2ca0b018
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X
(XEN) Not enabling x2APIC (upon firmware request)
(XEN) microcode: CPU0 updated from revision 0x84 to 0xc2, date = 2017-11-16
(XEN) xstate: size: 0x440 and states: 0x1f
(XEN) mce_intel.c:782: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, CMCI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: IBRS/IBPB STIBP
(XEN) Compiled-in support: INDIRECT_THUNK
(XEN) BTI mitigations: Thunk JMP, Others: IBRS+ IBPB RSB_NATIVE RSB_VMEXIT
(XEN) XPTI: enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Platform timer is 23.999MHz HPET
(XEN) Detected 3504.097 MHz processor.
(XEN) EFI memory map:
(XEN) 0000000000000-0000000007fff type=3 attr=000000000000000f
(XEN) 0000000008000-0000000057fff type=7 attr=000000000000000f
(XEN) 0000000058000-0000000058fff type=0 attr=000000000000000f
(XEN) 0000000059000-000000005cfff type=7 attr=000000000000000f
(XEN) 000000005d000-000000005efff type=2 attr=000000000000000f
(XEN) 000000005f000-000000005ffff type=4 attr=000000000000000f
(XEN) 0000000060000-000000009efff type=3 attr=000000000000000f
(XEN) 000000009f000-000000009ffff type=0 attr=000000000000000f
(XEN) 0000000100000-0000022eb7fff type=7 attr=000000000000000f
(XEN) 0000022eb8000-0000022ef7fff type=4 attr=000000000000000f
(XEN) 0000022ef8000-0000024e98fff type=7 attr=000000000000000f
(XEN) 0000024e99000-0000029774fff type=2 attr=000000000000000f
(XEN) 0000029775000-000002a974fff type=1 attr=000000000000000f
(XEN) 000002a975000-000002a975fff type=2 attr=000000000000000f
(XEN) 000002a976000-000002a976fff type=7 attr=000000000000000f(XEN) 000002a977000-000002a979fff type=2 attr=000000000000000f
(XEN) 000002a97a000-000002a980fff type=7 attr=000000000000000f(XEN) 000002a981000-000002aa3dfff type=1 attr=000000000000000f
(XEN) 000002aa3e000-000002adfefff type=4 attr=000000000000000f(XEN) 000002adff000-000002adfffff type=10 attr=000000000000000f
(XEN) 000002ae00000-000002ae49fff type=6 attr=800000000000000f
(XEN) 000002ae4a000-000002aea7fff type=4 attr=000000000000000f
(XEN) 000002aea8000-000002aea9fff type=2 attr=000000000000000f
(XEN) 000002aeaa000-000002aeacfff type=7 attr=000000000000000f
(XEN) 000002aead000-000002aeb6fff type=2 attr=000000000000000f
(XEN) 000002aeb7000-000002e28cfff type=4 attr=000000000000000f
(XEN) 000002e28d000-000002e412fff type=7 attr=000000000000000f
(XEN) 000002e413000-000002e88cfff type=3 attr=000000000000000f(XEN) 000002e88d000-000002ec2ffff type=0 attr=000000000000000f
(XEN) 000002ec30000-000002edaafff type=7 attr=000000000000000f
(XEN) 000002edab000-000002f3b6fff type=10 attr=000000000000000f
(XEN) 000002f3b7000-000002fe72fff type=6 attr=800000000000000(XEN) 000002fe73000-000002fffefff type=5 attr=800000000000000f
(XEN) 000002ffff000-000002fffffff type=4 attr=000000000000000f
(XEN) 0000100000000-00008c33fffff type=7 attr=000000000000000f
(XEN) 0000030000000-0000037ffffff type=0 attr=0000000000000000
(XEN) 00000e0000000-00000efffffff type=11 attr=8000000000000001
(XEN) 00000fe000000-00000fe010fff type=11 attr=8000000000000001
(XEN) 00000fec00000-00000fec00fff type=11 attr=8000000000000001
(XEN) 00000fee00000-00000fee00fff type=11 attr=8000000000000001
(XEN) 00000ff000000-00000ffffffff type=11 attr=80000000000000
(XEN) Initing memory sharing.
(XEN) alt table ffff82d0806717f0 -> ffff82d080673674
(XEN) spurious 8259A interrupt: IRQ7.
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) nr_sockets: 1
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x142120
(XEN) mwait-idle: v0.4.1 model 0x5e
(XEN) rocessor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) - Unrestricted Guest
(XEN) - VMCS shadowing
(XEN) - VM Functions
(XEN) - Virtualisation Exceptions
(XEN) - Page Modification Logging
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 8 CPUs
(XEN) build-id: ec82a093ee38f710a239ff8fc3986a9f
(XEN) Running stub recovery selftests...
(XEN) traps.c:1569: GPF (0000): ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803753f2
(XEN) traps.c:754: Trap 12: ffff82d0bffff040 [ffff82d0bffff040] -> ffff82d0803753f2
(XEN) traps.c:1096: Trap 3: ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d0803753f2
(XEN) ACPI sleep modes: S3
(XEN) VPMU: disabled
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Dom0 has maximum 792 PIRQs
(XEN) grant_table.c:1769:IDLEv0 Expanding d0 grant table from 0 to 1 frames
(XEN) NX (Execute Disable) protection active
(XEN) *** Building a PV Dom0 ***
(XEN) ELF: phdr: paddr=0x1000000 memsz=0x10ae000
(XEN) ELF: phdr: paddr=0x2200000 memsz=0x572000
(XEN) ELF: phdr: paddr=0x2772000 memsz=0x239d8
(XEN) ELF: phdr: paddr=0x2796000 memsz=0xd86000
(XEN) ELF: memory: 0x1000000 -> 0x351c000
(XEN) ELF: note: GUEST_OS = "linux"
(XEN) ELF: note: GUEST_VERSION = "2.6"
(XEN) ELF: note: XEN_VERSION = "xen-3.0"
(XEN) ELF: note: VIRT_BASE = 0xffffffff80000000
(XEN) ELF: note: INIT_P2M = 0x8000000000
(XEN) ELF: note: ENTRY = 0xffffffff82796180
(XEN) ELF: note: HYPERCALL_PAGE = 0xffffffff81001000
(XEN) ELF: note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb"
(XEN) ELF: note: SUPPORTED_FEATURES = 0x801
(XEN) ELF: note: PAE_MODE = "yes"
(XEN) ELF: note: LOADER = "generic"
(XEN) ELF: note: unknown (0xd)
(XEN) ELF: note: SUSPEND_CANCELound PVH image
(XEN) ELF: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff81000000
(XEN) virt_kend = 0xffffffff8351c000
(XEN) virt_entry = 0xffffffff82796180
(XEN) p2m_base = 0x8000000000
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x351c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 00000008a0000000->00000008a4000000 (2063956 pages to be allocated)
(XEN) Init. ramdisk: 00000008bf254000->00000008c33ff4f2
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff8351c000
(XEN) Init. ramdisk: 0000000000000000->0000000000000000
(XEN) Phys-Mach map: 0000008000000000->0000008001000000
(XEN) Start info: ffffffff8351c000->ffffffff8351c4b4
(XEN) Xenstore ring: 0000000000000000->0000000000000000
(XEN) Console ring: 0000000000000000->0000000000000000
(XEN) Page tables: ffffffff8351d000->ffffffff8353c000
(XEN) Boot stack: ffffffff8353c000->ffffffff8353d000
(XEN) TOTAL: ffffffff80000000->ffffffff83800000
(XEN) ENTRY ADDRESS: ffffffff82796180
(XEN) Dom0 has maximum 8 VCPUs
(XEN) ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff820ae000
(XEN) ELF: phdr 1 at 0xffffffff82200000 -> 0xffffffff82772000
(XEN) ELF: phdr 2 at 0xffffffff82772000 -> 0xffffffff827959d8
(XEN) ELF: phdr 3 at 0xffffffff82796000 -> 0xffffffff829c8000
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c0003fc000
(XEN) [VT-D]iommu_enable_translation: iommu->reg = ffff82c0003fe000
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 0, iommu reg = ffff82c0003fc000
(XEN) [VT-D]DMAR: reason 01 - Present bit in root entry is clear
(XEN) print_vtd_entries: iommuXEN) context[10] = 2_6acd80001
(XEN) l4[000] = 6acd7f003
(XEN) l3[000] = 6acd7e003
(XEN) l2[000] = 6acd7d003
(XEN) l1[000] = 3
(XEN) [VT-D]INTR-REMAP: Request device [0000:f0:1f.0] fault index 0, iommu reg = ffff82c0003fe000
(XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt request
(XEN) .......................................................................done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 2048kB init memory
(XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=0000]
(XEN) domain_crash_sync called from entry.S: fault at ffff82d08036eab3 x86_64/entry.S#create_bounce_frame+0x143/0x170
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.11-rc x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e033:[<ffffffff81062660>]
(XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (d0v0)
(XEN) rax: 0000000000000246 rbx: 0000000000000000 rcx: 0000000000000000
(XEN) rdx: 0000000000000000 rsi: 00000000ffffffff rdi: 0000000000000000
(XEN) rbp: 0000000000000000 rsp: ffffffff82203da0 r8: ffffffff81f727a8
(XEN) r9: ffffffff82203e58 r10: 00000000ffffffff r11: ffffffff82203e7c
(XEN) r12: ffffffff82203efc r13: ffffffff82203e58 r14: 0000000000000000
(XEN) r15: 00000000ffffffff cr0: 000000008005003b cr4: 00000000003526e0
(XEN) cr3: 00000008a351d000 cr2: 0000000000000000
(XEN) fsb: 0000000000000000 gsb: ffffffff82772000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
(XEN) Guest stack trace from rsp=ffffffff82203da0:
(XEN) 0000000000000000 ffffffff82203e7c 0000000000000000 ffffffff81062660
(XEN) 000000010000e030 0000000000010046 ffffffff82203de8 000000000000e02b
(XEN) 0000000000000246 ffffffff810df7dc 0000000000000000 0000000000000000
(XEN) ffffffff81f727a8 0000000000000246 0000000000000000 0000000000000000
(XEN) ffffffff82433cc0 ffffffff82203ea8 ffffffff82203efc ffffffff82203ef4
(XEN) ffffffff82203ef0 ffffffff82203f0c ffffffff810e06c5 ffffffff00000008
(XEN) ffffffff82203eb8 ffffffff82203e78 0000000000000000 0000000000000000
(XEN) 0000000000000001 0000000000000000 0000000000000000 0000000000000000
(XEN) ffffffff82203e78 0000000000000001 ffffffff8103cb53 ffffffff82433cc0
(XEN) ffffffff82203ef8 ffffffff8103cda8 ffffffff82203f00 ffffffff82203f04
(XEN) ffffffff82203f08 0000000100000000 0000100000003027 0000000000000000
(XEN) 0000000080000008 0000000000000000 ffffffff82203f58 ffffffff82203f54
(XEN) ffffffff82203f50 ffffffff82203f4c 0000000000000000 0000000000000000
(XEN) ffffffff8279f2ec 0000000000000000 0000012100000000 0000000020101800
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0f00000060c0c748 ccccccccccccc305 cccccccccccccccc cccccccccccccccc
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
(XEN) APIC error on CPU0: 40(00)
telnet> Connection closed.
[Connecting to system 63 ]
>
> confused,
>
> greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 18:22 ` Konrad Rzeszutek Wilk
@ 2018-05-18 19:57 ` Thomas Gleixner
2018-05-18 20:34 ` [MODERATED] " Konrad Rzeszutek Wilk
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Gleixner @ 2018-05-18 19:57 UTC (permalink / raw)
To: speck
On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
> On Fri, May 18, 2018 at 03:21:54PM +0200, speck for Greg KH wrote:
> (XEN) Std. Loglevel: All
> (XEN) Guest Loglevel: All
> (XEN) Xen is relinquishing VGA console.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) Freed 2048kB init memory
> (XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=0000]
> (XEN) domain_crash_sync called from entry.S: fault at ffff82d08036eab3 x86_64/entry.S#create_bounce_frame+0x143/0x170
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.11-rc x86_64 debug=y Not tainted ]----
> (XEN) CPU: 0
> (XEN) RIP: e033:[<ffffffff81062660>]
> (XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (d0v0)
> (XEN) rax: 0000000000000246 rbx: 0000000000000000 rcx: 0000000000000000
> (XEN) rdx: 0000000000000000 rsi: 00000000ffffffff rdi: 0000000000000000
> (XEN) rbp: 0000000000000000 rsp: ffffffff82203da0 r8: ffffffff81f727a8
> (XEN) r9: ffffffff82203e58 r10: 00000000ffffffff r11: ffffffff82203e7c
> (XEN) r12: ffffffff82203efc r13: ffffffff82203e58 r14: 0000000000000000
> (XEN) r15: 00000000ffffffff cr0: 000000008005003b cr4: 00000000003526e0
> (XEN) cr3: 00000008a351d000 cr2: 0000000000000000
> (XEN) fsb: 0000000000000000 gsb: ffffffff82772000 gss: 0000000000000000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
> (XEN) Guest stack trace from rsp=ffffffff82203da0:
> (XEN) 0000000000000000 ffffffff82203e7c 0000000000000000 ffffffff81062660
> (XEN) 000000010000e030 0000000000010046 ffffffff82203de8 000000000000e02b
> (XEN) 0000000000000246 ffffffff810df7dc 0000000000000000 0000000000000000
> (XEN) ffffffff81f727a8 0000000000000246 0000000000000000 0000000000000000
> (XEN) ffffffff82433cc0 ffffffff82203ea8 ffffffff82203efc ffffffff82203ef4
> (XEN) ffffffff82203ef0 ffffffff82203f0c ffffffff810e06c5 ffffffff00000008
> (XEN) ffffffff82203eb8 ffffffff82203e78 0000000000000000 0000000000000000
> (XEN) 0000000000000001 0000000000000000 0000000000000000 0000000000000000
> (XEN) ffffffff82203e78 0000000000000001 ffffffff8103cb53 ffffffff82433cc0
> (XEN) ffffffff82203ef8 ffffffff8103cda8 ffffffff82203f00 ffffffff82203f04
> (XEN) ffffffff82203f08 0000000100000000 0000100000003027 0000000000000000
> (XEN) 0000000080000008 0000000000000000 ffffffff82203f58 ffffffff82203f54
> (XEN) ffffffff82203f50 ffffffff82203f4c 0000000000000000 0000000000000000
> (XEN) ffffffff8279f2ec 0000000000000000 0000012100000000 0000000020101800
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN) 0f00000060c0c748 ccccccccccccc305 cccccccccccccccc cccccccccccccccc
> (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> (XEN) APIC error on CPU0: 40(00)
The above is pretty useless and undecodable. So what makes Dom0 crash in a
way that the machine needs to be rebooted? The call to get_cpu_cap()?
If so, then I really want to understand what makes it particularly explode.
Thanks,
tglx
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 19:57 ` Thomas Gleixner
@ 2018-05-18 20:34 ` Konrad Rzeszutek Wilk
2018-05-18 20:40 ` Linus Torvalds
2018-05-19 8:33 ` Thomas Gleixner
0 siblings, 2 replies; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-05-18 20:34 UTC (permalink / raw)
To: speck
On Fri, May 18, 2018 at 09:57:47PM +0200, speck for Thomas Gleixner wrote:
> On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
> > On Fri, May 18, 2018 at 03:21:54PM +0200, speck for Greg KH wrote:
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) Xen is relinquishing VGA console.
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> > (XEN) Freed 2048kB init memory
> > (XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=0000]
> > (XEN) domain_crash_sync called from entry.S: fault at ffff82d08036eab3 x86_64/entry.S#create_bounce_frame+0x143/0x170
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.11-rc x86_64 debug=y Not tainted ]----
> > (XEN) CPU: 0
> > (XEN) RIP: e033:[<ffffffff81062660>]
> > (XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (d0v0)
> > (XEN) rax: 0000000000000246 rbx: 0000000000000000 rcx: 0000000000000000
> > (XEN) rdx: 0000000000000000 rsi: 00000000ffffffff rdi: 0000000000000000
> > (XEN) rbp: 0000000000000000 rsp: ffffffff82203da0 r8: ffffffff81f727a8
> > (XEN) r9: ffffffff82203e58 r10: 00000000ffffffff r11: ffffffff82203e7c
> > (XEN) r12: ffffffff82203efc r13: ffffffff82203e58 r14: 0000000000000000
> > (XEN) r15: 00000000ffffffff cr0: 000000008005003b cr4: 00000000003526e0
> > (XEN) cr3: 00000008a351d000 cr2: 0000000000000000
> > (XEN) fsb: 0000000000000000 gsb: ffffffff82772000 gss: 0000000000000000
> > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
> > (XEN) Guest stack trace from rsp=ffffffff82203da0:
> > (XEN) 0000000000000000 ffffffff82203e7c 0000000000000000 ffffffff81062660
> > (XEN) 000000010000e030 0000000000010046 ffffffff82203de8 000000000000e02b
> > (XEN) 0000000000000246 ffffffff810df7dc 0000000000000000 0000000000000000
> > (XEN) ffffffff81f727a8 0000000000000246 0000000000000000 0000000000000000
> > (XEN) ffffffff82433cc0 ffffffff82203ea8 ffffffff82203efc ffffffff82203ef4
> > (XEN) ffffffff82203ef0 ffffffff82203f0c ffffffff810e06c5 ffffffff00000008
> > (XEN) ffffffff82203eb8 ffffffff82203e78 0000000000000000 0000000000000000
> > (XEN) 0000000000000001 0000000000000000 0000000000000000 0000000000000000
> > (XEN) ffffffff82203e78 0000000000000001 ffffffff8103cb53 ffffffff82433cc0
> > (XEN) ffffffff82203ef8 ffffffff8103cda8 ffffffff82203f00 ffffffff82203f04
> > (XEN) ffffffff82203f08 0000000100000000 0000100000003027 0000000000000000
> > (XEN) 0000000080000008 0000000000000000 ffffffff82203f58 ffffffff82203f54
> > (XEN) ffffffff82203f50 ffffffff82203f4c 0000000000000000 0000000000000000
> > (XEN) ffffffff8279f2ec 0000000000000000 0000012100000000 0000000020101800
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0f00000060c0c748 ccccccccccccc305 cccccccccccccccc cccccccccccccccc
> > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > (XEN) APIC error on CPU0: 40(00)
>
> The above is pretty useless and undecodable. So what makes Dom0 crash in a
> way that the machine needs to be rebooted? The call to get_cpu_cap()?
Yup. B/c there is no early callback installed yet and it ends up using 'cli'
>
> If so, then I really want to understand what makes it particularly explode.
It would be best if you and Boris chatted. Let me poke him to get his GPG key in order.
>
> Thanks,
>
> tglx
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 20:34 ` [MODERATED] " Konrad Rzeszutek Wilk
@ 2018-05-18 20:40 ` Linus Torvalds
2018-05-18 21:05 ` Konrad Rzeszutek Wilk
2018-05-19 8:33 ` Thomas Gleixner
1 sibling, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2018-05-18 20:40 UTC (permalink / raw)
To: speck
On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
>
> Yup. B/c there is no early callback installed yet and it ends up using 'cli'
Why isn't the default callback for cli (and restore-flags) just a no-op?
Interrupts had better not be enabled before the callbacks are done, so
they *should* default to not doing anything.
Linus
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 20:40 ` Linus Torvalds
@ 2018-05-18 21:05 ` Konrad Rzeszutek Wilk
2018-05-18 21:10 ` Linus Torvalds
0 siblings, 1 reply; 15+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-05-18 21:05 UTC (permalink / raw)
To: speck
On Fri, May 18, 2018 at 01:40:39PM -0700, speck for Linus Torvalds wrote:
>
>
> On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
> >
> > Yup. B/c there is no early callback installed yet and it ends up using 'cli'
>
> Why isn't the default callback for cli (and restore-flags) just a no-op?
The paravirt code hadn't yet run.
>
> Interrupts had better not be enabled before the callbacks are done, so
> they *should* default to not doing anything.
>
> Linus
^ permalink raw reply [flat|nested] 15+ messages in thread
* [MODERATED] Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 21:05 ` Konrad Rzeszutek Wilk
@ 2018-05-18 21:10 ` Linus Torvalds
0 siblings, 0 replies; 15+ messages in thread
From: Linus Torvalds @ 2018-05-18 21:10 UTC (permalink / raw)
To: speck
On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
> On Fri, May 18, 2018 at 01:40:39PM -0700, speck for Linus Torvalds wrote:
> >
> > Why isn't the default callback for cli (and restore-flags) just a no-op?
>
> The paravirt code hadn't yet run.
de·fault
dəˈfôlt/
noun
...
2. a preselected option adopted by a computer program or other mechanism
when no alternative is specified by the user or programmer.
The whole point of "default" is that it is the choice that is taken before
the paravirt code has initialized.
Why the hell does it oops? Just make it ignore the situation.
Linus
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2
2018-05-18 20:34 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 20:40 ` Linus Torvalds
@ 2018-05-19 8:33 ` Thomas Gleixner
1 sibling, 0 replies; 15+ messages in thread
From: Thomas Gleixner @ 2018-05-19 8:33 UTC (permalink / raw)
To: speck
On Fri, 18 May 2018, speck for Konrad Rzeszutek Wilk wrote:
> On Fri, May 18, 2018 at 09:57:47PM +0200, speck for Thomas Gleixner wrote:
> > > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > (XEN) 0f00000060c0c748 ccccccccccccc305 cccccccccccccccc cccccccccccccccc
> > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > (XEN) APIC error on CPU0: 40(00)
> >
> > The above is pretty useless and undecodable. So what makes Dom0 crash in a
> > way that the machine needs to be rebooted? The call to get_cpu_cap()?
>
> Yup. B/c there is no early callback installed yet and it ends up using 'cli'
Sigh, 'using CLI' is not helpful either. The callchain and where the CLI is
invoked, is the interesting information.
But well, as you say its get_cpu_cap() I went and stared at it for while,
but there is absolutely NOTHING which might invoke CLI. It was nothing
before SSB and SSB did not add anything either.
So this patch is voodoo and makes exactly zero sense, unless you come up
with some sensible explanation.
Thanks,
tglx
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-05-19 8:33 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-17 3:18 [MODERATED] [PATCH v17.1 2/2] [PATCH v17.1 2/2] SSB Fix #2 konrad.wilk
2018-05-18 8:20 ` [MODERATED] " Greg KH
2018-05-18 9:02 ` Thomas Gleixner
2018-05-18 11:46 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 9:14 ` Thomas Gleixner
2018-05-18 11:43 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 12:03 ` Greg KH
2018-05-18 13:21 ` Greg KH
2018-05-18 18:22 ` Konrad Rzeszutek Wilk
2018-05-18 19:57 ` Thomas Gleixner
2018-05-18 20:34 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-05-18 20:40 ` Linus Torvalds
2018-05-18 21:05 ` Konrad Rzeszutek Wilk
2018-05-18 21:10 ` Linus Torvalds
2018-05-19 8:33 ` Thomas Gleixner
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.