Re: [patch] x86/smpboot: Fix the parallel bringup decision
On Wed, May 31, 2023 at 09:44:26AM +0200, Thomas Gleixner wrote:
> The decision to allow parallel bringup of secondary CPUs checks
> CC_ATTR_GUEST_STATE_ENCRYPT to detect encrypted guests. Those cannot use
> parallel bootup because accessing the local APIC is intercepted and raises
> a #VC or #VE, which cannot be handled at that point.
>
> The check works correctly, but only for AMD encrypted guests. TDX does not
> set that flag.
>
> As there is no real connection between CC attributes and the inability to
> support parallel bringup, replace this with a generic control flag in
> x86_cpuinit and let SEV-ES and TDX init code disable it.
>
> Fixes: 0c7ffa32dbd6 ("x86/smpboot/64: Implement
> arch_cpuhp_init_parallel_bringup() and enable it")
> Reported-by: Kirill A. Shutemov
> Signed-off-by: Thomas Gleixner
Tested-by: Kirill A. Shutemov
--
Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch] x86/smpboot: Disable parallel bootup if cc_vendor != NONE
On Tue, May 30, 2023 at 06:00:46PM +0200, Thomas Gleixner wrote: > On Tue, May 30 2023 at 15:29, Kirill A. Shutemov wrote: > > On Tue, May 30, 2023 at 02:09:17PM +0200, Thomas Gleixner wrote: > >> The decision to allow parallel bringup of secondary CPUs checks > >> CC_ATTR_GUEST_STATE_ENCRYPT to detect encrypted guests. Those cannot use > >> parallel bootup because accessing the local APIC is intercepted and raises > >> a #VC or #VE, which cannot be handled at that point. > >> > >> The check works correctly, but only for AMD encrypted guests. TDX does not > >> set that flag. > >> > >> Check for cc_vendor != CC_VENDOR_NONE instead. That might be overbroad, but > >> definitely works for both AMD and Intel. > > > > It boots fine with TDX, but I think it is wrong. cc_get_vendor() will > > report CC_VENDOR_AMD even on bare metal if SME is enabled. I don't think > > we want it. > > Right. Did not think about that. > > But the same way is CC_ATTR_GUEST_MEM_ENCRYPT overbroad for AMD. Only > SEV-ES traps RDMSR if I'm understandig that maze correctly. I don't know difference between SEV flavours that well. I see there's that on SEV-SNP access to x2APIC MSR range (MSR 0x800-0x8FF) is intercepted regardless if MSR_AMD64_SNP_ALT_INJ feature is present. But I'm not sure what the state on SEV or SEV-ES. Tom? -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch] x86/smpboot: Disable parallel bootup if cc_vendor != NONE
On Tue, May 30, 2023 at 02:09:17PM +0200, Thomas Gleixner wrote: > The decision to allow parallel bringup of secondary CPUs checks > CC_ATTR_GUEST_STATE_ENCRYPT to detect encrypted guests. Those cannot use > parallel bootup because accessing the local APIC is intercepted and raises > a #VC or #VE, which cannot be handled at that point. > > The check works correctly, but only for AMD encrypted guests. TDX does not > set that flag. > > Check for cc_vendor != CC_VENDOR_NONE instead. That might be overbroad, but > definitely works for both AMD and Intel. It boots fine with TDX, but I think it is wrong. cc_get_vendor() will report CC_VENDOR_AMD even on bare metal if SME is enabled. I don't think we want it. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Tue, May 30, 2023 at 12:34:45PM +0200, Thomas Gleixner wrote: > On Tue, May 30 2023 at 11:26, Thomas Gleixner wrote: > > On Tue, May 30 2023 at 03:54, Kirill A. Shutemov wrote: > >> On Mon, May 29, 2023 at 11:31:29PM +0300, Kirill A. Shutemov wrote: > >>> Disabling parallel bringup helps. I didn't look closer yet. If you have > >>> an idea let me know. > >> > >> Okay, it crashes around .Lread_apicid due to touching MSRs that trigger > >> #VE. > >> > >> Looks like the patch had no intention to enable parallel bringup on TDX. > >> > >> +* Intel-TDX has a secure RDMSR hypercall, but that needs to be > >> +* implemented seperately in the low level startup ASM code. > >> > >> But CC_ATTR_GUEST_STATE_ENCRYPT that used to filter it out is > >> SEV-ES-specific thingy and doesn't cover TDX. I don't think we have an > >> attribute that fits nicely here. > > > > Bah. That sucks. > > Can we have something consistent in this CC space or needs everything to > be extra magic per CC variant? IIUC, CC_ATTR_GUEST_MEM_ENCRYPT should cover all AMD SEV flavours and Intel TDX. But the name is confusing in this context: memory encryption has nothing to do with the APIC. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch] x86/realmode: Make stack lock work in trampoline_compat()
On Tue, May 30, 2023 at 12:46:22PM +0200, Thomas Gleixner wrote:
> The stack locking and stack assignment macro LOAD_REALMODE_ESP fails to
> work when invoked from the 64bit trampoline entry point:
>
> trampoline_start64
> trampoline_compat
> LOAD_REALMODE_ESP <- lock
>
> Accessing tr_lock is only possible from 16bit mode. For the compat entry
> point this needs to be pa_tr_lock so that the required relocation entry is
> generated. Otherwise it locks the non-relocated address which is
> aside of being wrong never cleared in secondary_startup_64() causing all
> but the first CPU to get stuck on the lock.
>
> Make the macro take an argument lock_pa which defaults to 0 and rename it
> to LOCK_AND_LOAD_REALMODE_ESP to make it clear what this is about.
>
> Fixes: f6f1ae9128d2 ("x86/smpboot: Implement a bit spinlock to protect the
> realmode stack")
> Reported-by: Kirill A. Shutemov
> Signed-off-by: Thomas Gleixner
Tested-by: Kirill A. Shutemov
--
Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Mon, May 29, 2023 at 11:31:29PM +0300, Kirill A. Shutemov wrote: > On Mon, May 29, 2023 at 09:27:13PM +0200, Thomas Gleixner wrote: > > On Mon, May 29 2023 at 05:39, Kirill A. Shutemov wrote: > > > On Sat, May 27, 2023 at 03:40:02PM +0200, Thomas Gleixner wrote: > > > But it gets broken again on "x86/smpboot: Implement a bit spinlock to > > > protect the realmode stack" with > > > > > > [0.554079] node #0, CPUs:#1 #2 > > > [0.738071] Callback from call_rcu_tasks() invoked. > > > [ 10.562065] CPU2 failed to report alive state > > > [ 10.566337] #3 > > > [ 20.570066] CPU3 failed to report alive state > > > [ 20.574268] #4 > > > ... > > > > > > Notably CPU1 is missing from "failed to report" list. So CPU1 takes the > > > lock fine, but seems never unlocks it. > > > > > > Maybe trampoline_lock(%rip) in head_64.S somehow is not the same as > > > _lock in trampoline_64.S. I donno. > > > > It's definitely the same in the regular startup (16bit mode), but TDX > > starts up via: > > > > trampoline_start64 > > trampoline_compat > > LOAD_REALMODE_ESP <- lock > > > > That place cannot work with that LOAD_REALMODE_ESP macro. The untested > > below should cure it. > > Yep, works for me. > > Aaand the next patch that breaks TDX boot is... > > x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable > it > > Disabling parallel bringup helps. I didn't look closer yet. If you have > an idea let me know. Okay, it crashes around .Lread_apicid due to touching MSRs that trigger #VE. Looks like the patch had no intention to enable parallel bringup on TDX. +* Intel-TDX has a secure RDMSR hypercall, but that needs to be + * implemented seperately in the low level startup ASM code. But CC_ATTR_GUEST_STATE_ENCRYPT that used to filter it out is SEV-ES-specific thingy and doesn't cover TDX. I don't think we have an attribute that fits nicely here. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Mon, May 29, 2023 at 09:27:13PM +0200, Thomas Gleixner wrote: > On Mon, May 29 2023 at 05:39, Kirill A. Shutemov wrote: > > On Sat, May 27, 2023 at 03:40:02PM +0200, Thomas Gleixner wrote: > > But it gets broken again on "x86/smpboot: Implement a bit spinlock to > > protect the realmode stack" with > > > > [0.554079] node #0, CPUs:#1 #2 > > [0.738071] Callback from call_rcu_tasks() invoked. > > [ 10.562065] CPU2 failed to report alive state > > [ 10.566337] #3 > > [ 20.570066] CPU3 failed to report alive state > > [ 20.574268] #4 > > ... > > > > Notably CPU1 is missing from "failed to report" list. So CPU1 takes the > > lock fine, but seems never unlocks it. > > > > Maybe trampoline_lock(%rip) in head_64.S somehow is not the same as > > _lock in trampoline_64.S. I donno. > > It's definitely the same in the regular startup (16bit mode), but TDX > starts up via: > > trampoline_start64 > trampoline_compat > LOAD_REALMODE_ESP <- lock > > That place cannot work with that LOAD_REALMODE_ESP macro. The untested > below should cure it. Yep, works for me. Aaand the next patch that breaks TDX boot is... x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it Disabling parallel bringup helps. I didn't look closer yet. If you have an idea let me know. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Sat, May 27, 2023 at 03:40:02PM +0200, Thomas Gleixner wrote: > On Fri, May 26 2023 at 12:14, Thomas Gleixner wrote: > > On Wed, May 24 2023 at 23:48, Kirill A. Shutemov wrote: > >> This patch causes boot regression on TDX guest. The guest crashes on SMP > >> bring up. > > The below should fix that. Sigh... Okay, this gets me fixes the boot for TDX guest: Tested-by: Kirill A. Shutemov But it gets broken again on "x86/smpboot: Implement a bit spinlock to protect the realmode stack" with [0.554079] node #0, CPUs:#1 #2 [0.738071] Callback from call_rcu_tasks() invoked. [ 10.562065] CPU2 failed to report alive state [ 10.566337] #3 [ 20.570066] CPU3 failed to report alive state [ 20.574268] #4 ... Notably CPU1 is missing from "failed to report" list. So CPU1 takes the lock fine, but seems never unlocks it. Maybe trampoline_lock(%rip) in head_64.S somehow is not the same as _lock in trampoline_64.S. I donno. I haven't find the root cause yet. But bypassing locking in LOAD_REALMODE_ESP makes the issue go away. I will look more into it. -- Kiryl Shutsemau / Kirill A. Shutemov
Re: [patch v3 31/36] x86/apic: Provide cpu_primary_thread mask
On Mon, May 08, 2023 at 09:44:17PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Make the primary thread tracking CPU mask based in preparation for simpler
> handling of parallel bootup.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Michael Kelley
>
>
> ---
> arch/x86/include/asm/apic.h |2 --
> arch/x86/include/asm/topology.h | 19 +++
> arch/x86/kernel/apic/apic.c | 20 +---
> arch/x86/kernel/smpboot.c | 12 +++-
> 4 files changed, 27 insertions(+), 26 deletions(-)
> ---
>
...
> @@ -2386,20 +2386,16 @@ bool arch_match_cpu_phys_id(int cpu, u64
> }
>
> #ifdef CONFIG_SMP
> -/**
> - * apic_id_is_primary_thread - Check whether APIC ID belongs to a primary
> thread
> - * @apicid: APIC ID to check
> - */
> -bool apic_id_is_primary_thread(unsigned int apicid)
> +static void cpu_mark_primary_thread(unsigned int cpu, unsigned int apicid)
> {
> - u32 mask;
> -
> - if (smp_num_siblings == 1)
> - return true;
> /* Isolate the SMT bit(s) in the APICID and check for 0 */
> - mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
> - return !(apicid & mask);
> + u32 mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
> +
> + if (smp_num_siblings == 1 || !(apicid & mask))
> + cpumask_set_cpu(cpu, &__cpu_primary_thread_mask);
> }
> +#else
> +static inline void cpu_mark_primary_thread(unsigned int cpu, unsigned int
> apicid) { }
> #endif
>
> /*
This patch causes boot regression on TDX guest. The guest crashes on SMP
bring up.
The change makes use of smp_num_siblings earlier than before: the mask get
constructed in acpi_boot_init() codepath. Later on smp_num_siblings gets
updated in detect_ht().
In my setup with 16 vCPUs, smp_num_siblings is 16 before detect_ht() and
set to 1 in detect_ht().
--
Kiryl Shutsemau / Kirill A. Shutemov
Re: [Xen-devel] [PATCH 0/3] Remove __online_page_set_limits()
On Sun, Sep 08, 2019 at 03:17:01AM +0530, Souptick Joarder wrote: > __online_page_set_limits() is a dummy function and an extra call > to this can be avoided. > > As both of the callers are now removed, __online_page_set_limits() > can be removed permanently. > > Souptick Joarder (3): > hv_ballon: Avoid calling dummy function __online_page_set_limits() > xen/ballon: Avoid calling dummy function __online_page_set_limits() > mm/memory_hotplug.c: Remove __online_page_set_limits() > > drivers/hv/hv_balloon.c| 1 - > drivers/xen/balloon.c | 1 - > include/linux/memory_hotplug.h | 1 - > mm/memory_hotplug.c| 5 - > 4 files changed, 8 deletions(-) Do we really need 3 separate patches to remove 8 lines of code? -- Kirill A. Shutemov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCHv2 0/2] Fixups for LDT remap placement change
On Fri, Nov 30, 2018 at 08:23:26PM +, Kirill A. Shutemov wrote: > There's a couple fixes for the recent LDT remap placement change. Ping? -- Kirill A. Shutemov ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 0/2] Fixups for LDT remap placement change
There's a couple fixes for the recent LDT remap placement change. The first patch fixes crash when kernel booted as Xen dom0. The second patch fixes address space markers in dump_pagetables output. It's purely cosmetic change, backporting to the stable tree is optional. v2: - Fix typo Kirill A. Shutemov (2): x86/mm: Fix guard hole handling x86/dump_pagetables: Fix LDT remap address marker arch/x86/include/asm/pgtable_64_types.h | 5 + arch/x86/mm/dump_pagetables.c | 15 ++- arch/x86/xen/mmu_pv.c | 11 ++- 3 files changed, 17 insertions(+), 14 deletions(-) -- 2.19.2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 2/2] x86/dump_pagetables: Fix LDT remap address marker
The LDT remap placement has been changed. It's now placed before direct
mapping in the kernel virtual address space for both paging modes.
Change address markers order accordingly.
Signed-off-by: Kirill A. Shutemov
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
---
arch/x86/mm/dump_pagetables.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index dad153e5a427..abcb8d00b014 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -55,10 +55,10 @@ struct addr_marker {
enum address_markers_idx {
USER_SPACE_NR = 0,
KERNEL_SPACE_NR,
- LOW_KERNEL_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && defined(CONFIG_X86_5LEVEL)
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
LDT_NR,
#endif
+ LOW_KERNEL_NR,
VMALLOC_START_NR,
VMEMMAP_START_NR,
#ifdef CONFIG_KASAN
@@ -66,9 +66,6 @@ enum address_markers_idx {
KASAN_SHADOW_END_NR,
#endif
CPU_ENTRY_AREA_NR,
-#if defined(CONFIG_MODIFY_LDT_SYSCALL) && !defined(CONFIG_X86_5LEVEL)
- LDT_NR,
-#endif
#ifdef CONFIG_X86_ESPFIX64
ESPFIX_START_NR,
#endif
--
2.19.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCHv2 1/2] x86/mm: Fix guard hole handling
There is a guard hole at the beginning of kernel address space, also
used by hypervisors. It occupies 16 PGD entries.
We do not state the reserved range directly, but calculate it relative
to other entities: direct mapping and user space ranges.
The calculation got broken by recent change in kernel memory layout: LDT
remap range is now mapped before direct mapping and makes the calculation
invalid.
The breakage leads to crash on Xen dom0 boot[1].
State the reserved range directly. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
Signed-off-by: Kirill A. Shutemov
Reported-by: Hans van Kranenburg
Tested-by: Hans van Kranenburg
Reviewed-by: Juergen Gross
Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level
paging")
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/pgtable_64_types.h | 5 +
arch/x86/mm/dump_pagetables.c | 8
arch/x86/xen/mmu_pv.c | 11 ++-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 84bd9bdc1987..88bca456da99 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
*/
#define MAXMEM (1UL << MAX_PHYSMEM_BITS)
+#define GUARD_HOLE_PGD_ENTRY -256UL
+#define GUARD_HOLE_SIZE(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR (GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
#define LDT_PGD_ENTRY -240UL
#define LDT_BASE_ADDR (LDT_PGD_ENTRY << PGDIR_SHIFT)
#define LDT_END_ADDR (LDT_BASE_ADDR + PGDIR_SIZE)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index fc37bbd23eb8..dad153e5a427 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -512,11 +512,11 @@ static inline bool is_hypervisor_range(int idx)
{
#ifdef CONFIG_X86_64
/*
-* 8000 - 87ff is reserved for
-* the hypervisor.
+* A hole in the beginning of kernel address space reserved
+* for a hypervisor.
*/
- return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
- (idx < pgd_index(__PAGE_OFFSET));
+ return (idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+ (idx < pgd_index(GUARD_HOLE_END_ADDR));
#else
return false;
#endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index a5d7ed125337..0f4fe206dcc2 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -648,19 +648,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t
*pgd,
unsigned long limit)
{
int i, nr, flush = 0;
- unsigned hole_low, hole_high;
+ unsigned hole_low = 0, hole_high = 0;
/* The limit is the last byte to be touched */
limit--;
BUG_ON(limit >= FIXADDR_TOP);
+#ifdef CONFIG_X86_64
/*
* 64-bit has a great big hole in the middle of the address
-* space, which contains the Xen mappings. On 32-bit these
-* will end up making a zero-sized hole and so is a no-op.
+* space, which contains the Xen mappings.
*/
- hole_low = pgd_index(USER_LIMIT);
- hole_high = pgd_index(PAGE_OFFSET);
+ hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+ hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
nr = pgd_index(limit) + 1;
for (i = 0; i < nr; i++) {
--
2.19.2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Fri, Nov 30, 2018 at 02:53:50PM +, Hans van Kranenburg wrote:
> On 11/30/18 2:26 PM, Kirill A. Shutemov wrote:
> > On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
> >> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
> >>>> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> >>>>> On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
> >>>>>> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> >>>>>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>>>>>>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >>>>>>>>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> As also seen at:
> >>>>>>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>>>>>>>>
> >>>>>>>>>> Attached there are two serial console output logs. One is starting
> >>>>>>>>>> with
> >>>>>>>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without
> >>>>>>>>>> Xen.
> >>>>>>>>>>
> >>>>>>>>>> [2.085543] BUG: unable to handle kernel paging request at
> >>>>>>>>>> 888d9fffc000
> >>>>>>>>>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>>>>>>>>> [2.085674] Oops: [#1] SMP NOPTI
> >>>>>>>>>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>>>>>>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>>>>>>>>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68
> >>>>>>>>>> 05/21/2018
> >>>>>>>>>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>> The offending stable commit is
> >>>>>>>>> 4074ca7d8a1832921c865d250bbd08f3441b3657
> >>>>>>>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"),
> >>>>>>>>> this
> >>>>>>>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>>>>>>>>
> >>>>>>>>> Current upstream kernel is booting fine under Xen, so in general the
> >>>>>>>>> patch should be fine. Using an upstream kernel built from above
> >>>>>>>>> commit
> >>>>>>>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is
> >>>>>>>>> fine,
> >>>>>>>>> too.
> >>>>>>>>>
> >>>>>>>>> Kirill, are you aware of any prerequisite patch from 4.20 which
> >>>>>>>>> could be
> >>>>>>>>> missing in 4.19.5?
> >>>>>>>>
> >>>>>>>> I'm not.
> >>>>>>>>
> >>>>>>>> Let me look into this.
> >>>>>>>>
> >>>>>>>
> >>>>>>> What is making me suspicious is the failure happening just after
> >>>>>>> releasing the init memory. Maybe there is an access to .init.data
> >>>>>>> segment or similar? The native kernel booting could be related to the
> >>>>>>> usage of 2M mappings not being available in a PV-domain.
> >>>>>>
> >>>>>> Ahh.. Could you test this:
> >>>>>>
> >>>>>> diff --git a/arch/x86/mm/dump_pagetables.c
> >>>>>> b/arch/x86/mm/dump_pagetables.c
> >>>>>> index a12afff146d1..7dec63ec7aab 100644
> >>>>>> --- a/arch/x86/mm/dump_pagetables.c
> >>>>>> +++ b/arch/x86/mm/dump_pagetables.c
> >>>>>> @@ -496,7 +496,7 @@ static inline bool is_hypervisor_range(int idx)
> >>>>>> * 8000 - 87ff is reserved for
> >>>>>> * the hypervisor.
> >>>>>> */
> >>>>>> - return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
> >>>>>> + return (idx >= pgd_index(__PAGE_OFFSET) - 17) &&
> >>>>>>(idx < pgd_index(__PAGE_OFFSET));
> >>>>>> #else
> >>>>>>return false;
> >>>>>
> >>>>> Or, better, this:
> >>>>
> >>>> That makes it boot again!
> >>>>
> >>>> Any idea why upstream doesn't need it?
> >>>
> >>> Nope.
> >>>
> >>> I'll prepare a proper fix.
> >>>
> >>
> >> Thanks for looking into this.
> >>
> >> In the meantime, I applied the "Or, better, this" change, and my dom0
> >> boots again.
> >>
> >> FYI, boot log now: (paste 90d valid)
> >> https://paste.debian.net/plainh/48940826
> >
> > I forgot to CC you:
> >
> > https://lkml.kernel.org/r/20181130121131.g3xvlvixv7mvl...@black.fi.intel.com
> >
> > Please give it a try.
>
> I'm not in that thread, so my response here...
>
> You paste a v2-like patch into 'Re: [PATCH 1/2]'. Juergen says:
> s/LDT_PGD_ENTRY/GUARD_HOLE_PGD_ENTRY/, then you say Ughh.., change it to
> GUARD_HOLE_ENTRY, which does not exist, and then get a Reviewed-by from
> Juergen.
>
> I guess it has to be GUARD_HOLE_PGD_ENTRY after all...
>
> arch/x86/include/asm/pgtable_64_types.h:116:31: error:
> 'GUARD_HOLE_ENTRY' undeclared (first use in this function); did you mean
> 'GUARD_HOLE_PGD_ENTRY'?
>
> I'll test that instead.
Yes, thank you. It was a long week... :/
Let me know if it works. I'll repost the fixed version with your
Tested-by.
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Fri, Nov 30, 2018 at 01:11:56PM +, Hans van Kranenburg wrote:
> On 11/29/18 4:06 PM, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
> >> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
> >>>> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> >>>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>>>>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >>>>>>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> As also seen at:
> >>>>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>>>>>>
> >>>>>>>> Attached there are two serial console output logs. One is starting
> >>>>>>>> with
> >>>>>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without
> >>>>>>>> Xen.
> >>>>>>>>
> >>>>>>>> [2.085543] BUG: unable to handle kernel paging request at
> >>>>>>>> 888d9fffc000
> >>>>>>>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>>>>>>> [2.085674] Oops: [#1] SMP NOPTI
> >>>>>>>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>>>>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>>>>>>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68
> >>>>>>>> 05/21/2018
> >>>>>>>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>>>>>>> [...]
> >>>>>>>
> >>>>>>> The offending stable commit is
> >>>>>>> 4074ca7d8a1832921c865d250bbd08f3441b3657
> >>>>>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >>>>>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>>>>>>
> >>>>>>> Current upstream kernel is booting fine under Xen, so in general the
> >>>>>>> patch should be fine. Using an upstream kernel built from above commit
> >>>>>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >>>>>>> too.
> >>>>>>>
> >>>>>>> Kirill, are you aware of any prerequisite patch from 4.20 which could
> >>>>>>> be
> >>>>>>> missing in 4.19.5?
> >>>>>>
> >>>>>> I'm not.
> >>>>>>
> >>>>>> Let me look into this.
> >>>>>>
> >>>>>
> >>>>> What is making me suspicious is the failure happening just after
> >>>>> releasing the init memory. Maybe there is an access to .init.data
> >>>>> segment or similar? The native kernel booting could be related to the
> >>>>> usage of 2M mappings not being available in a PV-domain.
> >>>>
> >>>> Ahh.. Could you test this:
> >>>>
> >>>> diff --git a/arch/x86/mm/dump_pagetables.c
> >>>> b/arch/x86/mm/dump_pagetables.c
> >>>> index a12afff146d1..7dec63ec7aab 100644
> >>>> --- a/arch/x86/mm/dump_pagetables.c
> >>>> +++ b/arch/x86/mm/dump_pagetables.c
> >>>> @@ -496,7 +496,7 @@ static inline bool is_hypervisor_range(int idx)
> >>>> * 8000 - 87ff is reserved for
> >>>> * the hypervisor.
> >>>> */
> >>>> -return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
> >>>> +return (idx >= pgd_index(__PAGE_OFFSET) - 17) &&
> >>>> (idx < pgd_index(__PAGE_OFFSET));
> >>>> #else
> >>>> return false;
> >>>
> >>> Or, better, this:
> >>
> >> That makes it boot again!
> >>
> >> Any idea why upstream doesn't need it?
> >
> > Nope.
> >
> > I'll prepare a proper fix.
> >
>
> Thanks for looking into this.
>
> In the meantime, I applied the "Or, better, this" change, and my dom0
> boots again.
>
> FYI, boot log now: (paste 90d valid)
> https://paste.debian.net/plainh/48940826
I forgot to CC you:
https://lkml.kernel.org/r/20181130121131.g3xvlvixv7mvl...@black.fi.intel.com
Please give it a try.
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Thu, Nov 29, 2018 at 03:00:45PM +, Juergen Gross wrote:
> On 29/11/2018 15:32, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 02:24:47PM +0000, Kirill A. Shutemov wrote:
> >> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> >>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >>>>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> As also seen at:
> >>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>>>>
> >>>>>> Attached there are two serial console output logs. One is starting with
> >>>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >>>>>>
> >>>>>> [2.085543] BUG: unable to handle kernel paging request at
> >>>>>> 888d9fffc000
> >>>>>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>>>>> [2.085674] Oops: [#1] SMP NOPTI
> >>>>>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>>>>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> >>>>>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>>>>> [...]
> >>>>>
> >>>>> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> >>>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >>>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>>>>
> >>>>> Current upstream kernel is booting fine under Xen, so in general the
> >>>>> patch should be fine. Using an upstream kernel built from above commit
> >>>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >>>>> too.
> >>>>>
> >>>>> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> >>>>> missing in 4.19.5?
> >>>>
> >>>> I'm not.
> >>>>
> >>>> Let me look into this.
> >>>>
> >>>
> >>> What is making me suspicious is the failure happening just after
> >>> releasing the init memory. Maybe there is an access to .init.data
> >>> segment or similar? The native kernel booting could be related to the
> >>> usage of 2M mappings not being available in a PV-domain.
> >>
> >> Ahh.. Could you test this:
> >>
> >> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
> >> index a12afff146d1..7dec63ec7aab 100644
> >> --- a/arch/x86/mm/dump_pagetables.c
> >> +++ b/arch/x86/mm/dump_pagetables.c
> >> @@ -496,7 +496,7 @@ static inline bool is_hypervisor_range(int idx)
> >> * 8000 - 87ff is reserved for
> >> * the hypervisor.
> >> */
> >> - return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
> >> + return (idx >= pgd_index(__PAGE_OFFSET) - 17) &&
> >>(idx < pgd_index(__PAGE_OFFSET));
> >> #else
> >>return false;
> >
> > Or, better, this:
>
> That makes it boot again!
>
> Any idea why upstream doesn't need it?
Nope.
I'll prepare a proper fix.
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Thu, Nov 29, 2018 at 02:24:47PM +, Kirill A. Shutemov wrote:
> On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> > On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> > >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> > >>> Hi,
> > >>>
> > >>> As also seen at:
> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> > >>>
> > >>> Attached there are two serial console output logs. One is starting with
> > >>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> > >>>
> > >>> [2.085543] BUG: unable to handle kernel paging request at
> > >>> 888d9fffc000
> > >>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> > >>> [2.085674] Oops: [#1] SMP NOPTI
> > >>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> > >>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> > >>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> > >>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> > >>> [...]
> > >>
> > >> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> > >> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> > >> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> > >>
> > >> Current upstream kernel is booting fine under Xen, so in general the
> > >> patch should be fine. Using an upstream kernel built from above commit
> > >> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> > >> too.
> > >>
> > >> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> > >> missing in 4.19.5?
> > >
> > > I'm not.
> > >
> > > Let me look into this.
> > >
> >
> > What is making me suspicious is the failure happening just after
> > releasing the init memory. Maybe there is an access to .init.data
> > segment or similar? The native kernel booting could be related to the
> > usage of 2M mappings not being available in a PV-domain.
>
> Ahh.. Could you test this:
>
> diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
> index a12afff146d1..7dec63ec7aab 100644
> --- a/arch/x86/mm/dump_pagetables.c
> +++ b/arch/x86/mm/dump_pagetables.c
> @@ -496,7 +496,7 @@ static inline bool is_hypervisor_range(int idx)
>* 8000 - 87ff is reserved for
>* the hypervisor.
>*/
> - return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
> + return (idx >= pgd_index(__PAGE_OFFSET) - 17) &&
> (idx < pgd_index(__PAGE_OFFSET));
> #else
> return false;
Or, better, this:
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a12afff146d1..8c04fadc4423 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -496,8 +496,8 @@ static inline bool is_hypervisor_range(int idx)
* 8000 - 87ff is reserved for
* the hypervisor.
*/
- return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
- (idx < pgd_index(__PAGE_OFFSET));
+ return (idx >= pgd_index(LDT_BASE_ADDR) - 16) &&
+ (idx < pgd_index(LDT_BASE_ADDR));
#else
return false;
#endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2c84c6ad8b50..b078a5b0ac91 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -652,7 +652,7 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
* will end up making a zero-sized hole and so is a no-op.
*/
hole_low = pgd_index(USER_LIMIT);
- hole_high = pgd_index(PAGE_OFFSET);
+ hole_high = pgd_index(LDT_BASE_ADDR);
nr = pgd_index(limit) + 1;
for (i = 0; i < nr; i++) {
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>
> >>> Attached there are two serial console output logs. One is starting with
> >>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >>>
> >>> [2.085543] BUG: unable to handle kernel paging request at
> >>> 888d9fffc000
> >>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>> [2.085674] Oops: [#1] SMP NOPTI
> >>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> >>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>> [...]
> >>
> >> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> >> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>
> >> Current upstream kernel is booting fine under Xen, so in general the
> >> patch should be fine. Using an upstream kernel built from above commit
> >> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >> too.
> >>
> >> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> >> missing in 4.19.5?
> >
> > I'm not.
> >
> > Let me look into this.
> >
>
> What is making me suspicious is the failure happening just after
> releasing the init memory. Maybe there is an access to .init.data
> segment or similar? The native kernel booting could be related to the
> usage of 2M mappings not being available in a PV-domain.
Ahh.. Could you test this:
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a12afff146d1..7dec63ec7aab 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -496,7 +496,7 @@ static inline bool is_hypervisor_range(int idx)
* 8000 - 87ff is reserved for
* the hypervisor.
*/
- return (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
+ return (idx >= pgd_index(__PAGE_OFFSET) - 17) &&
(idx < pgd_index(__PAGE_OFFSET));
#else
return false;
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Thu, Nov 29, 2018 at 01:35:17PM +, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>
> >>> Attached there are two serial console output logs. One is starting with
> >>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >>>
> >>> [2.085543] BUG: unable to handle kernel paging request at
> >>> 888d9fffc000
> >>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>> [2.085674] Oops: [#1] SMP NOPTI
> >>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> >>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>> [...]
> >>
> >> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> >> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>
> >> Current upstream kernel is booting fine under Xen, so in general the
> >> patch should be fine. Using an upstream kernel built from above commit
> >> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >> too.
> >>
> >> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> >> missing in 4.19.5?
> >
> > I'm not.
> >
> > Let me look into this.
> >
>
> What is making me suspicious is the failure happening just after
> releasing the init memory. Maybe there is an access to .init.data
> segment or similar? The native kernel booting could be related to the
> usage of 2M mappings not being available in a PV-domain.
Sounds like a valid hypothesis.
[ 2.085616] Code: 00 00 00 00 40 00 00 49 83 c5 08 48 01 04 24 4c 3b 6c 24 48
0f 84 83 02 00 00 48 8b 04 24 48 c1 f8
10 48 89 84 24 88 00 00 00 <49> 8b 7d 00 48 f7 c7 9f ff ff ff 0f 85 36 ff ff
ff 41 b8 03 00 00
All code
0: 00 00 add%al,(%rax)
2: 00 00 add%al,(%rax)
4: 40 00 00add%al,(%rax)
7: 49 83 c5 08 add$0x8,%r13
b: 48 01 04 24 add%rax,(%rsp)
f: 4c 3b 6c 24 48 cmp0x48(%rsp),%r13
14: 0f 84 83 02 00 00 je 0x29d
1a: 48 8b 04 24 mov(%rsp),%rax
1e: 48 c1 f8 10 sar$0x10,%rax
22: 48 89 84 24 88 00 00mov%rax,0x88(%rsp)
29: 00
2a:* 49 8b 7d 00 mov0x0(%r13),%rdi <-- trapping
instruction
2e: 48 f7 c7 9f ff ff fftest $0xff9f,%rdi
35: 0f 85 36 ff ff ff jne0xff71
3b: 41 rex.B
3c: b8 .byte 0xb8
3d: 03 00 add(%rax),%eax
...
Code starting with the faulting instruction
===
0: 49 8b 7d 00 mov0x0(%r13),%rdi
4: 48 f7 c7 9f ff ff fftest $0xff9f,%rdi
b: 0f 85 36 ff ff ff jne0xff47
11: 41 rex.B
12: b8 .byte 0xb8
13: 03 00 add(%rax),%eax
...
Reading from %r13 causes the fault.
I don't have a setup to reproduce the issue myself and have hard time
correlate the code with source.
What is ptdump_walk_pgd_level_core+0x1fd/0x490 for you?
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0
On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> > Hi,
> >
> > As also seen at:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >
> > Attached there are two serial console output logs. One is starting with
> > Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >
> > [2.085543] BUG: unable to handle kernel paging request at
> > 888d9fffc000
> > [2.085610] PGD 200c067 P4D 200c067 PUD 0
> > [2.085674] Oops: [#1] SMP NOPTI
> > [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> > 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> > [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> > [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> > [...]
>
> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
>
> Current upstream kernel is booting fine under Xen, so in general the
> patch should be fine. Using an upstream kernel built from above commit
> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> too.
>
> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> missing in 4.19.5?
I'm not.
Let me look into this.
--
Kirill A. Shutemov
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
