From: Mike Rapoport <rppt@linux.ibm.com>
To: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Mel Gorman <mgorman@techsingularity.net>,
Vlastimil Babka <vbabka@suse.cz>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>, Ard Biesheuvel <ardb@kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Dario Faggioli <dfaggioli@suse.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
Marcelo Cerri <marcelo.cerri@canonical.com>,
tim.gardner@canonical.com,
Khalid ElMously <khalid.elmously@canonical.com>,
philip.cox@canonical.com,
the arch/x86 maintainers <x86@kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-coco@lists.linux.dev, linux-efi <linux-efi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv7 02/14] mm: Add support for unaccepted memory
Date: Thu, 8 Sep 2022 15:11:44 +0300 [thread overview]
Message-ID: <YxncAElGrPEGRYg1@linux.ibm.com> (raw)
In-Reply-To: <CAAH4kHawguTEuDVyz1ysSbH0X_mT=SvxLi=UhwEzXM0abbWefg@mail.gmail.com>
On Tue, Sep 06, 2022 at 10:50:42AM -0700, Dionna Amalie Glaze wrote:
> >
> > It really helps this kind of stuff if you can post the *actual* error.
> > I assume this was a page fault, so there should have been some other
> > stuff before the RIP:...
> >
>
> I posted the error on August 15th. I was bumping in my last post
> since I confirmed with Tom Lendacky that it wasn't AMD's patches at
> fault.
> Here's a new dump below that matches the disassembly:
>
> [ 0.043137] Faking a node at [mem 0x0000000000000000-0x000000403fffffff]
> [ 0.044018] NODE_DATA(0) allocated [mem 0x403fffc000-0x403fffffff]
> [ 0.044922] Zone ranges:
> [ 0.045250] DMA [mem 0x0000000000001000-0x0000000000ffffff]
> [ 0.046039] DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
> [ 0.046828] Normal [mem 0x0000000100000000-0x000000403fffffff]
> [ 0.047657] Movable zone start for each node
> [ 0.048201] Early memory node ranges
> [ 0.048674] node 0: [mem 0x0000000000001000-0x000000000009ffff]
> [ 0.049474] node 0: [mem 0x0000000000100000-0x000000000080cfff
> [ 0.050274] node 0: [mem 0x000000000080f000-0x00000000beceefff]
> [ 0.051074] node 0: [mem 0x00000000befff000-0x00000000bfbb0fff]
> [ 0.051874] node 0: [mem 0x00000000bfbb2000-0x00000000bffdbfff]
> [ 0.052674] node 0: [mem 0x0000000100000000-0x000000403fffffff]
> [ 0.053530] Initmem setup node 0 [mem 0x0000000000001000-0x000000403fffffff]
> PANIC: Unsupported exit-code 0x404 in early #VC exception (IP:
> 0xfffffffface0cdd0)
> [ 0.056667] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.17.0-rc6-173762-gffb12b02c6d7-dirty #1
> [ 0.057744] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [ 0.058920] RIP: 0010:memmap_init_range+0x11d/0x188
> [ 0.059686] Code: 77 16 f6 42 10 02 74 10 48 03 42 08 48 c1 e8 0c
> 48 89 c3 e9 3a ff ff ff 48 89 df 48 c1 e7 06 48 03 3d a4 1e 65 ff 48
> 8d 47 08 <c7> 47 34 01 00 00 00 48 c7 47 38 00 00 00 00 c7 47 30 ff ff
> ff ff
> [ 0.062121] RSP: 0000:ffffffffac603dc0 EFLAGS: 00010082 ORIG_RAX:
> 0000000000000404
> [ 0.063087] RAX: ffffda1ac0000048 RBX: 0000000000000001 RCX: 0000000000000000
> [ 0.063998] RDX: 0300000000000000 RSI: 0000000000000000 RDI: ffffda1ac000004
> [ 0.064944] RBP: 0000000000000000 R08: 0000000000001000 R09: 0000000000000000
> [ 0.065873] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
> [ 0.066782] R13: 00000000000000a0 R14: 0000000000000000 R15: 0000000000000000
> [ 0.067695] FS: 0000000000000000(0000) GS:ffffffffacd88000(0000)
> knlGS:0000000000000000
> [ 0.068727] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.069488] CR2: ffffda1ac0000074 CR3: 00080020b680c000 CR4: 00000000000606b0
> [ 0.070397] Call Trace:
> [ 0.070710] <TASK>
> [ 0.070976] ? free_area_init+0x724/0x7d4
> [ 0.071486] ? zone_sizes_init+0x52/0x6c
> [ 0.071986] ? setup_arch+0xa55/0xb77
> [ 0.072453] ? start_kernel+0x64/0x65f
> [ 0.072931] ? secondary_startup_64_no_verify+0xd6/0xdb
> [ 0.073598] </TASK>
>
> Note this is a crash in SEV-SNP, but I assume we'd get the same #VE in TDX.
>
> > Another thing that's really nice is to do the disassembly of the "Code:"
> > or share disassembly of memmap_init_range.
>
> 0000000000000172 <memmap_init_range>:
> 172: 41 56 push %r14
> 174: 89 f0 mov %esi,%eax
> 176: 45 89 ce mov %r9d,%r14d
> 179: 41 55 push %r13
> 17b: 4c 8d 2c 39 lea (%rcx,%rdi,1),%r13
> 17f: 41 54 push %r12
> 181: 49 89 d4 mov %rdx,%r12
> 184: 49 8d 55 ff lea -0x1(%r13),%rdx
> 188: 48 3b 15 00 00 00 00 cmp 0x0(%rip),%rdx # 18f
> <memmap_init_range+0x1d>
> 18f: 55 push %rbp
> 190: 53 push %rbx
> 191: 48 89 cb mov %rcx,%rbx
> 194: 76 07 jbe 19d <memmap_init_range+0x2b>
> 196: 48 89 15 00 00 00 00 mov %rdx,0x0(%rip) # 19d
> <memmap_init_range+0x2b>
> 19d: 4c 89 e5 mov %r12,%rbp
> 1a0: ba 03 00 00 00 mov $0x3,%edx
> 1a5: 48 c1 e0 3a shl $0x3a,%rax
> 1a9: 48 c1 e5 38 shl $0x38,%rbp
> 1ad: 48 c1 e2 38 shl $0x38,%rdx
> 1b1: 48 21 d5 and %rdx,%rbp
> 1b4: 48 09 c5 or %rax,%rbp
> 1b7: 49 39 dd cmp %rbx,%r13
> 1ba: 0f 86 31 01 00 00 jbe 2f1 <memmap_init_range+0x17f>
> 1c0: 45 85 f6 test %r14d,%r14d
> 1c3: 0f 85 b4 00 00 00 jne 27d <memmap_init_range+0x10b>
> 1c9: 49 83 fc 03 cmp $0x3,%r12
> 1cd: 0f 94 c1 sete %cl
> 1d0: 22 0d 00 00 00 00 and 0x0(%rip),%cl # 1d6
> <memmap_init_range+0x64>
> 1d6: 0f 84 a1 00 00 00 je 27d <memmap_init_range+0x10b>
> 1dc: 48 8b 15 00 00 00 00 mov 0x0(%rip),%rdx # 1e3
> <memmap_init_range+0x71>
> 1e3: 48 85 d2 test %rdx,%rdx
> 1e6: 74 10 je 1f8 <memmap_init_range+0x86>
> 1e8: 48 8b 42 08 mov 0x8(%rdx),%rax
> 1ec: 48 03 02 add (%rdx),%rax
> 1ef: 48 c1 e8 0c shr $0xc,%rax
> 1f3: 48 39 d8 cmp %rbx,%rax
> 1f6: 77 55 ja 24d <memmap_init_range+0xdb>
> 1f8: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 1ff
> <memmap_init_range+0x8d>
> 1ff: 4c 6b 05 00 00 00 00 imul $0x18,0x0(%rip),%r8 #
> 207 <memmap_init_range+0x95>
> 206: 18
> 207: 31 f6 xor %esi,%esi
> 209: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 210
> <memmap_init_range+0x9e>
> 210: 49 01 c0 add %rax,%r8
> 213: 48 89 c7 mov %rax,%rdi
> 216: 4c 39 c0 cmp %r8,%rax
> 219: 73 26 jae 241 <memmap_init_range+0xcf>
> 21b: 48 8b 57 08 mov 0x8(%rdi),%rdx
> 21f: 48 03 17 add (%rdi),%rdx
> 222: 48 83 c0 18 add $0x18,%rax
> 226: 48 c1 ea 0c shr $0xc,%rdx
> 22a: 48 39 da cmp %rbx,%rdx
> 22d: 76 0e jbe 23d <memmap_init_range+0xcb>
> 22f: 40 84 f6 test %sil,%sil
> 232: 74 19 je 24d <memmap_init_range+0xdb>
> 234: 48 89 3d 00 00 00 00 mov %rdi,0x0(%rip) # 23b
> <memmap_init_range+0xc9>
> 23b: eb 10 jmp 24d <memmap_init_range+0xdb>
> 23d: 89 ce mov %ecx,%esi
> 23f: eb d2 jmp 213 <memmap_init_range+0xa1>
> 241: 40 84 f6 test %sil,%sil
> 244: 74 07 je 24d <memmap_init_range+0xdb>
> 246: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 24d
> <memmap_init_range+0xdb>
> 24d: 48 8b 15 00 00 00 00 mov 0x0(%rip),%rdx # 254
> <memmap_init_range+0xe2>
> 254: 48 8b 02 mov (%rdx),%rax
> 257: 48 8d 88 ff 0f 00 00 lea 0xfff(%rax),%rcx
> 25e: 48 c1 e9 0c shr $0xc,%rcx
> 262: 48 39 d9 cmp %rbx,%rcx
> 265: 77 16 ja 27d <memmap_init_range+0x10b>
> 267: f6 42 10 02 testb $0x2,0x10(%rdx)
> 26b: 74 10 je 27d <memmap_init_range+0x10b>
> 26d: 48 03 42 08 add 0x8(%rdx),%rax
> 271: 48 c1 e8 0c shr $0xc,%rax
> 275: 48 89 c3 mov %rax,%rbx
> 278: e9 3a ff ff ff jmp 1b7 <memmap_init_range+0x45>
> 27d: 48 89 df mov %rbx,%rdi
> 280: 48 c1 e7 06 shl $0x6,%rdi
> 284: 48 03 3d 00 00 00 00 add 0x0(%rip),%rdi # 28b
> <memmap_init_range+0x119>
> 28b: 48 8d 47 08 lea 0x8(%rdi),%rax
> 28f: c7 47 34 01 00 00 00 movl $0x1,0x34(%rdi) # Here's
> where the crash RIP is.
> 296: 48 c7 47 38 00 00 00 movq $0x0,0x38(%rdi)
> 29d: 00
> 29e: c7 47 30 ff ff ff ff movl $0xffffffff,0x30(%rdi)
> 2a5: 48 c7 47 28 00 00 00 movq $0x0,0x28(%rdi)
> 2ac: 00
> 2ad: 48 c7 47 20 00 00 00 movq $0x0,0x20(%rdi)
> 2b4: 00
> 2b5: 48 c7 47 18 00 00 00 movq $0x0,0x18(%rdi)
> 2bc: 00
> 2bd: 48 89 2f mov %rbp,(%rdi)
> 2c0: 48 89 47 08 mov %rax,0x8(%rdi)
> 2c4: 48 89 47 10 mov %rax,0x10(%rdi)
> 2c8: 41 83 fe 01 cmp $0x1,%r14d
> 2cc: 75 05 jne 2d3 <memmap_init_range+0x161>
> 2ce: 48 0f ba 2f 0c btsq $0xc,(%rdi)
> 2d3: f7 c3 ff 01 00 00 test $0x1ff,%ebx
> 2d9: 75 0e jne 2e9 <memmap_init_range+0x177>
> 2db: 8b 74 24 38 mov 0x38(%rsp),%esi
> 2df: e8 00 00 00 00 call 2e4 <memmap_init_range+0x172>
> 2e4: e8 00 00 00 00 call 2e9 <memmap_init_range+0x177>
> 2e9: 48 ff c3 inc %rbx
> 2ec: e9 c6 fe ff ff jmp 1b7 <memmap_init_range+0x45>
> 2f1: 5b pop %rbx
> 2f2: 5d pop %rbp
> 2f3: 41 5c pop %r12
> 2f5: 41 5d pop %r13
> 2f7: 41 5e pop %r14
> 2f9: c3 ret
>
> > Even nicer would be to give
> > an faddr2line of the RIP value and track down which C code was actually
> > at fault.
>
> arch_atomic_set
> arch/x86/include/asm/atomic.h:41
>
> of INIT_LIST_HEAD in __init_single_page, called from memmap_init_range.
Looks like the first access to the memory map fails, although I think
it's not in INIT_LIST_HEAD() but rather in init_page_count().
I'd start with making sure that page_alloc::memmap_alloc() actually returns
accepted memory. If you build kernel with CONFIG_DEBUG_VM=y the memory map
will poisoned in this function, so my guess is it'd crash there.
> --
> -Dionna Glaze, PhD (she/her)
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-09-08 12:13 UTC|newest]
Thread overview: 207+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 12:02 [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
2022-06-14 12:02 ` [PATCHv7 01/14] x86/boot: Centralize __pa()/__va() definitions Kirill A. Shutemov
2022-06-23 17:37 ` Dave Hansen
2022-06-14 12:02 ` [PATCHv7 02/14] mm: Add support for unaccepted memory Kirill A. Shutemov
2022-06-14 12:57 ` Gupta, Pankaj
2022-06-17 19:28 ` Tom Lendacky
2022-06-17 20:53 ` Tom Lendacky
2022-07-21 15:14 ` Borislav Petkov
2022-07-21 15:49 ` Dave Hansen
2022-07-22 19:18 ` Borislav Petkov
2022-07-22 19:30 ` Dave Hansen
2022-07-25 12:23 ` Borislav Petkov
2022-07-25 12:38 ` David Hildenbrand
2022-07-25 12:53 ` Borislav Petkov
2022-07-26 14:30 ` David Hildenbrand
2022-07-25 13:00 ` Mike Rapoport
2022-07-25 13:05 ` Borislav Petkov
2022-08-05 11:49 ` Vlastimil Babka
2022-08-05 12:09 ` David Hildenbrand
2022-08-05 13:38 ` Vlastimil Babka
2022-08-05 14:22 ` David Hildenbrand
2022-08-05 14:53 ` Dave Hansen
2022-08-05 14:41 ` Dave Hansen
2022-08-05 18:17 ` Vlastimil Babka
2022-08-08 15:55 ` Dave Hansen
2022-08-10 14:19 ` Mel Gorman
2022-08-15 21:08 ` Dionna Amalie Glaze
2022-08-15 22:02 ` Tom Lendacky
2022-08-29 16:02 ` Dionna Amalie Glaze
2022-08-29 16:19 ` Dave Hansen
2022-09-06 17:50 ` Dionna Amalie Glaze
2022-09-08 12:11 ` Mike Rapoport [this message]
2022-09-08 16:23 ` Dionna Amalie Glaze
2022-09-08 19:28 ` Mike Rapoport
2022-09-22 14:31 ` Tom Lendacky
2022-09-24 1:03 ` Kirill A. Shutemov
2022-09-24 9:36 ` Mike Rapoport
2022-09-26 12:10 ` Kirill A. Shutemov
2022-09-26 13:38 ` Tom Lendacky
2022-09-26 15:42 ` Kirill A. Shutemov
2022-09-26 15:42 ` Tom Lendacky
2022-06-14 12:02 ` [PATCHv7 03/14] mm: Report unaccepted memory in meminfo Kirill A. Shutemov
2022-07-26 14:33 ` David Hildenbrand
2022-06-14 12:02 ` [PATCHv7 04/14] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2022-07-25 13:02 ` Borislav Petkov
2022-06-14 12:02 ` [PATCHv7 05/14] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
2022-06-15 10:19 ` Peter Zijlstra
2022-06-15 15:05 ` Kirill A. Shutemov
2022-07-17 17:16 ` Borislav Petkov
2022-07-25 21:33 ` Borislav Petkov
2022-06-14 12:02 ` [PATCHv7 06/14] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
2022-06-22 19:58 ` Dave Hansen
2022-07-26 8:35 ` Borislav Petkov
2022-06-14 12:02 ` [PATCHv7 07/14] x86/boot/compressed: Handle " Kirill A. Shutemov
2022-06-14 12:02 ` [PATCHv7 08/14] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
2022-07-26 9:07 ` Borislav Petkov
2022-11-30 1:28 ` Kirill A. Shutemov
2022-12-01 9:37 ` Mike Rapoport
2022-12-01 13:47 ` Kirill A. Shutemov
2022-06-14 12:02 ` [PATCHv7 09/14] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
2022-06-14 12:02 ` [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into " Kirill A. Shutemov
2022-06-23 17:19 ` Dave Hansen
2022-07-26 10:21 ` Borislav Petkov
2022-08-02 23:46 ` Dave Hansen
2022-08-03 14:02 ` Dave Hansen
2022-08-11 11:26 ` Borislav Petkov
2022-08-13 16:11 ` Andy Lutomirski
2022-08-13 21:13 ` Kirill A. Shutemov
2022-08-13 16:04 ` Andy Lutomirski
2022-08-13 20:58 ` Kirill A. Shutemov
2022-07-26 17:25 ` Borislav Petkov
2022-07-26 17:46 ` Dave Hansen
2022-07-26 20:17 ` Andy Lutomirski
2022-08-09 11:38 ` Kirill A. Shutemov
2022-08-13 16:03 ` Andy Lutomirski
2022-08-13 21:02 ` Kirill A. Shutemov
2022-06-14 12:02 ` [PATCHv7 11/14] x86: Disable kexec if system has " Kirill A. Shutemov
2022-06-23 17:23 ` Dave Hansen
2022-06-23 17:23 ` Dave Hansen
2022-06-23 21:48 ` Eric W. Biederman
2022-06-23 21:48 ` Eric W. Biederman
2022-06-24 2:00 ` Kirill A. Shutemov
2022-06-24 2:00 ` Kirill A. Shutemov
2022-06-28 23:51 ` Kirill A. Shutemov
2022-06-28 23:51 ` Kirill A. Shutemov
2022-06-29 0:10 ` Dave Hansen
2022-06-29 0:10 ` Dave Hansen
2022-06-29 0:59 ` Kirill A. Shutemov
2022-06-29 0:59 ` Kirill A. Shutemov
2022-07-04 7:18 ` Dave Young
2022-07-04 7:18 ` Dave Young
2022-06-14 12:02 ` [PATCHv7 12/14] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2022-06-23 17:25 ` Dave Hansen
2022-06-14 12:02 ` [PATCHv7 13/14] x86/tdx: Refactor try_accept_one() Kirill A. Shutemov
2022-06-23 17:31 ` Dave Hansen
2022-07-26 10:58 ` Borislav Petkov
2022-06-14 12:02 ` [PATCHv7 14/14] x86/tdx: Add unaccepted memory support Kirill A. Shutemov
2022-06-24 16:22 ` Dave Hansen
2022-06-27 10:42 ` Kirill A. Shutemov
2022-07-26 14:51 ` Borislav Petkov
2022-08-09 11:45 ` Kirill A. Shutemov
2022-08-10 10:27 ` Borislav Petkov
2022-06-24 16:37 ` [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Peter Gonda
2022-06-24 16:57 ` Dave Hansen
2022-06-24 17:06 ` Marc Orr
2022-06-24 17:09 ` Dave Hansen
2022-06-24 17:15 ` Peter Gonda
2022-06-24 17:19 ` Marc Orr
2022-06-24 17:21 ` Peter Gonda
2022-06-24 17:47 ` Dave Hansen
2022-06-24 18:10 ` Peter Gonda
2022-06-24 18:13 ` Dave Hansen
2022-06-24 17:40 ` Michael Roth
2022-06-24 17:58 ` Michael Roth
2022-06-24 18:05 ` Peter Gonda
2022-06-27 11:30 ` Kirill A. Shutemov
2022-06-27 11:54 ` Ard Biesheuvel
2022-06-27 12:22 ` Kirill A. Shutemov
2022-06-27 16:17 ` Peter Gonda
2022-06-27 16:33 ` Ard Biesheuvel
2022-06-27 22:38 ` Kirill A. Shutemov
2022-06-28 17:17 ` Ard Biesheuvel
2022-07-18 17:21 ` Kirill A. Shutemov
2022-07-18 23:32 ` Dionna Amalie Glaze
2022-07-19 0:31 ` Dionna Amalie Glaze
2022-07-19 18:29 ` Dionna Amalie Glaze
2022-07-19 19:13 ` Borislav Petkov
2022-07-19 20:45 ` Ard Biesheuvel
2022-07-19 21:23 ` Borislav Petkov
2022-07-19 21:35 ` Dave Hansen
2022-07-19 21:50 ` Borislav Petkov
2022-07-19 22:01 ` Kirill A. Shutemov
2022-07-19 22:02 ` Dave Hansen
2022-07-19 22:08 ` Tom Lendacky
2022-07-20 0:26 ` Marc Orr
2022-07-20 5:44 ` Borislav Petkov
2022-07-20 17:03 ` Marc Orr
2022-07-22 15:07 ` Borislav Petkov
2022-07-21 17:12 ` Dave Hansen
2022-07-23 11:14 ` Ard Biesheuvel
2022-07-28 22:01 ` Dionna Amalie Glaze
2022-08-09 11:14 ` Kirill A. Shutemov
2022-08-09 11:36 ` Ard Biesheuvel
2022-08-09 11:54 ` Kirill A. Shutemov
2022-08-09 21:09 ` Dionna Amalie Glaze
2022-07-19 2:48 ` Yao, Jiewen
2022-07-29 14:01 ` [PATCH v1 0/2] Provide SEV-SNP " Tom Lendacky
2022-07-29 14:01 ` [PATCH v1 1/2] x86/sev: Use per-CPU PSC structure in prep for unaccepted memory support Tom Lendacky
2022-07-29 14:18 ` Dave Hansen
2022-07-29 14:25 ` Tom Lendacky
2022-07-29 19:08 ` Dave Hansen
2022-07-29 19:22 ` Tom Lendacky
2022-07-29 19:28 ` Dave Hansen
2022-07-29 20:12 ` Tom Lendacky
2022-08-03 18:11 ` [PATCH v1.1 0/2] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2022-08-03 18:11 ` [PATCH v1.1 1/2] x86/sev: Use per-CPU PSC structure in prep for unaccepted memory support Tom Lendacky
2022-08-03 18:17 ` Dave Hansen
2022-08-03 18:21 ` Tom Lendacky
2022-08-03 18:24 ` Dave Hansen
2022-08-03 21:03 ` Tom Lendacky
2022-08-03 21:18 ` Dave Hansen
2022-08-03 21:34 ` Tom Lendacky
2022-08-03 21:48 ` Dave Hansen
2022-08-03 22:17 ` Tom Lendacky
2022-08-03 18:18 ` Tom Lendacky
2022-08-03 18:11 ` [PATCH v1.1 2/2] x86/sev: Add SNP-specific " Tom Lendacky
2022-07-29 14:01 ` [PATCH v1 " Tom Lendacky
2022-08-23 0:24 ` Dionna Amalie Glaze
2022-08-23 14:28 ` Tom Lendacky
2022-08-23 23:28 ` Dionna Amalie Glaze
2022-08-08 17:16 ` [PATCH v2 0/2] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2022-08-08 17:16 ` [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2022-08-08 21:43 ` Dave Hansen
2022-08-08 22:18 ` Tom Lendacky
2022-08-08 22:33 ` Dave Hansen
2022-08-08 22:35 ` Tom Lendacky
2022-08-12 13:03 ` Borislav Petkov
2022-08-12 14:11 ` Tom Lendacky
2022-08-12 14:33 ` Borislav Petkov
2022-08-12 14:51 ` Tom Lendacky
2022-08-13 19:40 ` Borislav Petkov
2022-08-14 13:36 ` Tom Lendacky
2022-08-08 17:16 ` [PATCH v2 2/2] x86/sev: Add SNP-specific " Tom Lendacky
2022-08-15 15:57 ` [PATCH v3 0/2] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2022-08-15 15:57 ` [PATCH v3 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2022-08-17 16:08 ` Borislav Petkov
2022-08-17 21:17 ` Tom Lendacky
2022-08-15 15:57 ` [PATCH v3 2/2] x86/sev: Add SNP-specific " Tom Lendacky
2022-08-18 13:39 ` Borislav Petkov
2022-08-25 14:23 ` [PATCH v4 0/4] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2022-08-25 14:23 ` [PATCH v4 1/4] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2022-09-20 16:15 ` Borislav Petkov
2022-08-25 14:23 ` [PATCH v4 2/4] x86/sev: Allow for use of the early boot GHCB for PSC requests Tom Lendacky
2022-08-25 14:23 ` [PATCH v4 3/4] x86/sev: Use large PSC requests if applicable Tom Lendacky
2022-08-25 14:23 ` [PATCH v4 4/4] x86/sev: Add SNP-specific unaccepted memory support Tom Lendacky
2022-08-25 22:10 ` Dionna Amalie Glaze
2022-08-26 21:29 ` Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 0/6] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 1/6] x86/sev: Fix calculation of end address based on number of pages Tom Lendacky
2022-09-27 17:10 ` Dave Hansen
2022-09-27 20:45 ` Tom Lendacky
2022-09-27 19:04 ` Dionna Amalie Glaze
2022-09-27 17:04 ` [PATCH v5 2/6] " Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 3/6] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 4/6] x86/sev: Allow for use of the early boot GHCB for PSC requests Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 5/6] x86/sev: Use large PSC requests if applicable Tom Lendacky
2022-09-27 17:04 ` [PATCH v5 6/6] x86/sev: Add SNP-specific unaccepted memory support Tom Lendacky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YxncAElGrPEGRYg1@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=dfaggioli@suse.com \
--cc=dionnaglaze@google.com \
--cc=jroedel@suse.de \
--cc=khalid.elmously@canonical.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=marcelo.cerri@canonical.com \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=philip.cox@canonical.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.gardner@canonical.com \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.