Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27/01/2021 13:59, Jürgen Groß wrote:
> On 27.01.21 12:23, Andrew Cooper wrote:
>> On 27/01/2021 10:26, Jürgen Groß wrote:
>>> On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c
> b/arch/x86/xen/enlighten_pv.c
> index 4409306364dc..ca5ac10fcbf7 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
> exc_debug(regs);
> }
> +DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
> +{
> + /* This should never happen and there is no way to handle it. */
> + panic("Unknown trap in Xen PV mode.");
Looks much better. How about including regs->entry_vector here,
just to
short circuit the inevitable swearing which will accompany
encountering
this panic() ?
>>>
>>> You are aware the regs parameter is struct pt_regs *, not the Xen
>>> struct cpu_user_regs *?
>>
>> Yes, but I was assuming that they both contained the same information.
>>
>>>
>>> So I have no idea how I should get this information without creating
>>> a per-vector handler.
>>
>> Oh - that's dull.
>>
>> Fine then. Reviewed-by: Andrew Cooper
>>
>
> I think I'll switch the panic() to printk(); BUG(); in order to have
> more diagnostic data. Can I keep your R-b: with that modification?
Yeah. Sounds good.
~Andrew
Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27.01.21 12:23, Andrew Cooper wrote:
On 27/01/2021 10:26, Jürgen Groß wrote:
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
exc_debug(regs);
}
+DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
+{
+ /* This should never happen and there is no way to handle it. */
+ panic("Unknown trap in Xen PV mode.");
Looks much better. How about including regs->entry_vector here, just to
short circuit the inevitable swearing which will accompany encountering
this panic() ?
You are aware the regs parameter is struct pt_regs *, not the Xen
struct cpu_user_regs *?
Yes, but I was assuming that they both contained the same information.
So I have no idea how I should get this information without creating
a per-vector handler.
Oh - that's dull.
Fine then. Reviewed-by: Andrew Cooper
I think I'll switch the panic() to printk(); BUG(); in order to have
more diagnostic data. Can I keep your R-b: with that modification?
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27/01/2021 10:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/x86/xen/enlighten_pv.c
>>> @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
>>> exc_debug(regs);
>>> }
>>> +DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
>>> +{
>>> + /* This should never happen and there is no way to handle it. */
>>> + panic("Unknown trap in Xen PV mode.");
>>
>> Looks much better. How about including regs->entry_vector here, just to
>> short circuit the inevitable swearing which will accompany encountering
>> this panic() ?
>
> You are aware the regs parameter is struct pt_regs *, not the Xen
> struct cpu_user_regs *?
Yes, but I was assuming that they both contained the same information.
>
> So I have no idea how I should get this information without creating
> a per-vector handler.
Oh - that's dull.
Fine then. Reviewed-by: Andrew Cooper
Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27.01.2021 11:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/x86/xen/enlighten_pv.c
>>> @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
>>> exc_debug(regs);
>>> }
>>>
>>> +DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
>>> +{
>>> + /* This should never happen and there is no way to handle it. */
>>> + panic("Unknown trap in Xen PV mode.");
>>
>> Looks much better. How about including regs->entry_vector here, just to
>> short circuit the inevitable swearing which will accompany encountering
>> this panic() ?
>
> You are aware the regs parameter is struct pt_regs *, not the Xen
> struct cpu_user_regs *?
>
> So I have no idea how I should get this information without creating
> a per-vector handler.
Maybe log _RET_IP_ then (ideally decoded to a symbol), to give at
least some hint as to where this was coming from?
Jan
Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
exc_debug(regs);
}
+DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
+{
+ /* This should never happen and there is no way to handle it. */
+ panic("Unknown trap in Xen PV mode.");
Looks much better. How about including regs->entry_vector here, just to
short circuit the inevitable swearing which will accompany encountering
this panic() ?
You are aware the regs parameter is struct pt_regs *, not the Xen
struct cpu_user_regs *?
So I have no idea how I should get this information without creating
a per-vector handler.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
On 27/01/2021 09:38, Juergen Gross wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4409306364dc..ca5ac10fcbf7 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
> exc_debug(regs);
> }
>
> +DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
> +{
> + /* This should never happen and there is no way to handle it. */
> + panic("Unknown trap in Xen PV mode.");
Looks much better. How about including regs->entry_vector here, just to
short circuit the inevitable swearing which will accompany encountering
this panic() ?
~Andrew
[PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled
When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT
enabled as a Xen pv guest a warning is issued for each processor:
[5.964347] [ cut here ]
[5.968314] WARNING: CPU: 0 PID: 1 at
/home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660 get_trap_addr+0x59/0x90
[5.972321] Modules linked in:
[5.976313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
5.11.0-rc5-default #75
[5.980313] Hardware name: Dell Inc. OptiPlex 9020/0PC5F7, BIOS A05
12/05/2013
[5.984313] RIP: e030:get_trap_addr+0x59/0x90
[5.988313] Code: 42 10 83 f0 01 85 f6 74 04 84 c0 75 1d b8 01 00 00 00 c3
48 3d 00 80 83 82 72 08 48 3d 20 81 83 82 72 0c b8 01 00 00 00 eb db <0f> 0b 31
c0 c3 48 2d 00 80 83 82 48 ba 72 1c c7 71 1c c7 71 1c 48
[5.992313] RSP: e02b:c90040033d38 EFLAGS: 00010202
[5.996313] RAX: 0001 RBX: 82a141d0 RCX: 8222ec38
[6.000312] RDX: 8222ec38 RSI: 0005 RDI: c90040033d40
[6.004313] RBP: 8881003984a0 R08: 0007 R09: 888100398000
[6.008312] R10: 0007 R11: c90040246000 R12: 8884082182a8
[6.012313] R13: 0100 R14: 001d R15: 8881003982d0
[6.016316] FS: () GS:88840820()
knlGS:
[6.020313] CS: e030 DS: ES: CR0: 80050033
[6.024313] CR2: c900020ef000 CR3: 0220a000 CR4: 00050660
[6.028314] Call Trace:
[6.032313] cvt_gate_to_trap.part.7+0x3f/0x90
[6.036313] ? asm_exc_double_fault+0x30/0x30
[6.040313] xen_convert_trap_info+0x87/0xd0
[6.044313] xen_pv_cpu_up+0x17a/0x450
[6.048313] bringup_cpu+0x2b/0xc0
[6.052313] ? cpus_read_trylock+0x50/0x50
[6.056313] cpuhp_invoke_callback+0x80/0x4c0
[6.060313] _cpu_up+0xa7/0x140
[6.064313] cpu_up+0x98/0xd0
[6.068313] bringup_nonboot_cpus+0x4f/0x60
[6.072313] smp_init+0x26/0x79
[6.076313] kernel_init_freeable+0x103/0x258
[6.080313] ? rest_init+0xd0/0xd0
[6.084313] kernel_init+0xa/0x110
[6.088313] ret_from_fork+0x1f/0x30
[6.092313] ---[ end trace be9ecf17dceeb4f3 ]---
Reason is that there is no Xen pv trap entry for X86_TRAP_VC.
Fix that by adding a generic trap handler for unknown traps and wire all
unknown bare metal handlers to this generic handler, which will just
panic the system in case such a trap will ever happen.
Fixes: 0786138c78e793 ("x86/sev-es: Add a Runtime #VC Exception Handler")
Cc: # v5.10
Signed-off-by: Juergen Gross
---
V2:
- use generic handler for unknown traps (Andrew Cooper)
---
arch/x86/include/asm/idtentry.h | 1 +
arch/x86/xen/enlighten_pv.c | 14 +-
arch/x86/xen/xen-asm.S | 1 +
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 247a60a47331..f656aabd1545 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -613,6 +613,7 @@ DECLARE_IDTENTRY_VC(X86_TRAP_VC,exc_vmm_communication);
#ifdef CONFIG_XEN_PV
DECLARE_IDTENTRY_XENCB(X86_TRAP_OTHER, exc_xen_hypervisor_callback);
+DECLARE_IDTENTRY_RAW(X86_TRAP_OTHER, exc_xen_unknown_trap);
#endif
/* Device interrupts common/spurious */
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
exc_debug(regs);
}
+DEFINE_IDTENTRY_RAW(exc_xen_unknown_trap)
+{
+ /* This should never happen and there is no way to handle it. */
+ panic("Unknown trap in Xen PV mode.");
+}
+
struct trap_array_entry {
void (*orig)(void);
void (*xen)(void);
@@ -631,6 +637,7 @@ static bool __ref get_trap_addr(void **addr, unsigned int
ist)
{
unsigned int nr;
bool ist_okay = false;
+ bool found = false;
/*
* Replace trap handler addresses by Xen specific ones.
@@ -645,6 +652,7 @@ static bool __ref get_trap_addr(void **addr, unsigned int
ist)
if (*addr == entry->orig) {
*addr = entry->xen;
ist_okay = entry->ist_okay;
+ found = true;
break;
}
}
@@ -655,9 +663,13 @@ static bool __ref get_trap_addr(void **addr, unsigned int
ist)
nr = (*addr - (void *)early_idt_handler_array[0]) /
EARLY_IDT_HANDLER_SIZE;
*addr = (void *)xen_early_idt_handler_array[nr];
+ found = true;
}
- if (WARN_ON(ist != 0 && !ist_okay))
+ if (!found)
+ *addr = (void *)xen_asm_exc_xen_unknown_trap;
+
+ if (WARN_ON(found && ist != 0 && !ist_okay))
return false;
return true;
diff --git a/arch/x86/xen/xen-asm.S
