[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 07/14] xen/riscv: introduce exception handlers implementation


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Mon, 23 Jan 2023 20:09:12 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IMeUOonufG0fr/sflWmj3Tq5wJA/R6PntS6lJh0IYHI=; b=RVGGRVzhUbB5y6rqyBy/OmwoMbN3FXeyRFaNGCtDBDDqFnmi6NlghNGj63WH6BZ6c6EBZbEpMCgq2n9dawA4N0tiMZERpNvm57B0wI34l347JQEPXs+9SyYDASjdBabf4+QX/AS0vMANso7L2th9Dbrwb3snUAOzvQiv1tMNgkZcolTTh2XKrITN0ECF7kS0csLfP8A/xr3NSsCSv1O9cGChZkBTNKLNJASgY+3HSQLUQ4aBWT1FVuobKH933apsvl29zvGrFzFRS3u7UTLh8Y/8hjahOrv7/Ba7aIcUEPzSKUT5qic9RllCPAfKochDc/MPq4T2svPodqNTwebftA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RsmFmCnJFvilSpr7gFM95EFQe17nfM3l0QAVw22Jj0IOclXeCTjk4Kpde+zCz4ge3sfUCBFRhoSrzEXA9uzw5HOO+B3LvE0SAHt918AAMYuZuBscpY8Ns5Y26aivg5QerrMPPbR3shyUXs+0wkgd5RzmhJ9UXxL3z+teLaYval91SBgi8EjrPwTY1NiEOyDFPy3TMxy/WsMZ0tJGltONtO764/8Rw1m5WjJ0nEoALHVskjiSbSBIzLRaDEYyVZYXhe1+qbw4SaFJ+YWAhx+ZBR6uFtwdT2CuX6YsWUe/TCctf/pPbzkAFxvuVBdztul8U2YU9QpBfU/UzCgZOETmjg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>
  • Delivery-date: Mon, 23 Jan 2023 20:09:44 +0000
  • Ironport-data: A9a23:HVDjyq7TWUW+uW33fuXcQwxRtKHGchMFZxGqfqrLsTDasY5as4F+v mpNWWiPaP/YZmWnKt51O4/lpBsGsJfVzt9iGQA6/HhgHi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvynTraBYnoqLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9VU+45wehBtC5gZlPakR5weE/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m+ KUYAg0dREi5ucGY8a20dLRtmp0oI5y+VG8fkikIITDxK98DGMqGZpqQoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6NkkotiNABM/KMEjCObexTklyVu STt+GPhDwtBHNee1SCE4jSngeqncSbTCdlJT+XpqaMCbFu7xjVPCQUaCHeAjdLjtkuXRIkEB Use9X97xUQ13AnxJjXnZDW/pHOHpR8dHdlNCeox6AKK4qXR6gedQGMDS1ZpeNEg8cM7WzEu/ luIhM/yQyxitqWPTnCQ/avSqim9UQAONnMLbyIASQoD4vHgrZs1gxaJScxseIa6j9TzHSz7y hiQrTY5nLQVhogA0KDT1VrAiTi9q4PJSgMw7wP/UWes7wc/b4mgD6Sh7VnA8f9BNsCXVFCHt 3kfs9eS56YFCpTlvCeKRuMKHr2g+feeGDLZiF9rWZIm8lyQF2WLeIlR5HR7Ox1vO8NdIzvxO heP4UVW+YNZO2asYelveYWtBs82zK/mU9P4SvTTadkIaZ90HOOawBxTiYer9ziFuCARfWsXa P93re7E4a4mNJla
  • Ironport-hdrordr: A9a23:bjOue6uh5EzvomGYQAuo/vgB7skDstV00zEX/kB9WHVpm6yj+v xG/c5rsCMc7Qx6ZJhOo7+90cW7L080lqQFg7X5X43DYOCOggLBQL2KhbGI/9SKIVycygcy78 Zdm6gVMqyLMbB55/yKnTVRxbwbsaW6GKPDv5ag8590JzsaD52Jd21Ce36m+ksdfnggObMJUK Cyy+BgvDSadXEefq2AdwI4t7iqnaysqHr+CyR2fiIa1A==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHZLOAVkIPSVA/PBEeRaJXa6cnAQq6r6ACAgAA54ACAAFF9gA==
  • Thread-topic: [PATCH v1 07/14] xen/riscv: introduce exception handlers implementation

On 23/01/2023 3:17 pm, Oleksii wrote:
> On Mon, 2023-01-23 at 11:50 +0000, Andrew Cooper wrote:
>> On 20/01/2023 2:59 pm, Oleksii Kurochko wrote:
>>> +        /* Save context to stack */
>>> +        REG_S   sp, (RISCV_CPU_USER_REGS_OFFSET(sp) -
>>> RISCV_CPU_USER_REGS_SIZE) (sp)
>>> +        addi    sp, sp, -RISCV_CPU_USER_REGS_SIZE
>>> +        REG_S   t0, RISCV_CPU_USER_REGS_OFFSET(t0)(sp)
>> Exceptions on RISC-V don't adjust the stack pointer.  This logic
>> depends
>> on interrupting Xen code, and Xen not having suffered a stack
>> overflow
>> (and actually, that the space on the stack for all registers also
>> doesn't overflow).
>>
>> Which might be fine for now, but I think it warrants a comment
>> somewhere
>> (probably at handle_exception itself) stating the expectations while
>> it's still a work in progress.  So in this case something like:
>>
>> /* Work-in-progress:  Depends on interrupting Xen, and the stack
>> being
>> good. */
>>
>>
>> But, do we want to allocate stemp right away (even with an empty
>> struct), and get tp set up properly?
>>
> I am not sure that I get you here about stemp. Could you please clarify
> a little bit.

Sorry - sscratch, not stemp - I got the name wrong.

All registers are the interrupted context, not Xen's context.  This
includes the stack pointer, global pointer, and thread pointer.

Trap setup is supposed to stash Xen's tp in sscratch so on an
interrupt/exception, it can exchange sscratch with tp and recover the
stack pointer.

Linux plays games with having sscratch be 0 while in kernel and uses
this to determine whether the exception occurred in kernel or user
mode.  This is massive can of re-entrancy bugs that appears to be baked
into the architecture.

I genuinely can't figure out a safe way to cope with a stack overflow,
or a bad tp, because it is not safe to a pagefault until the exception
prologue has completed.  If you do, you'll switch back to the
interrupted task's tp and use that as if it were Xen's.

~Andrew

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.