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

Re: [PATCH v5 4/7] xen/riscv: introduce decode_cause() stuff


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Mar 2023 14:46:18 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=R+nfGpvmEs9pf/rc4mTbuoXpQh49a15/WtCPHhJqB2g=; b=NpC5xjmSzD6Mn5sQxtmhoiou2blZRFwnQhq2HK5OfwFODFa3gBqE30PGmQCtdi1cANoSGn7S48jkq9m/4N0R4y3fAfIPyo35Sciyfa+q9p4N7mXrDQEDnWRvgo1TapQ4P5AzkQ378ew3/omoPXocNoHQQioggoQBBu97Uc6GQYk/ymKxHUp5C9whgyiSVMSKpx3JXx13JZ39an34vN/PfTXvYZ3PYSWiyQCS0/S0oNM9pLkUebiDtHcS6ChFNUVotHwHylANMy1Oe4p2/6G9OgMEDJeS+V9rRRxVRM4LQwKp2+5EG/RakX0SEqpkzuLH3vwYXc+1vWiwU43376mytg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CC2rjLwGJL2y/veXSBJntVfpyatr1kelRzBC3VXJxeYVmKLc6ozelJkiliGXWlh7Cj1uzuwhzHXbq5BfpxLbViEDGandaK9s9vYNdAcvYWJp5/+Q+cpbnMp4jRFO5xQQ3XTPIURsUaz/Rp4IbwPgijq8h0RSNBuCv5eFWL//ZkCzaHtwaNfhlDMN1LgqPEXjfGxEXqd57Z7wqh9Cks4UXaHDGZ01t7mjkNqWNeTSvECWWwMpz5NeYwzY33ENPkosaEtPfvAUBxFXp7EJxVI90lqNw3MpbB/JNkwKdlW22YXKUqsgSycZClh01KdH1bzN10ge8xN2BfR/ptrQ9U9tVw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, Julien Grall <julien@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 22 Mar 2023 13:46:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.03.2023 14:32, Oleksii wrote:
> On Wed, 2023-03-22 at 13:26 +0100, Jan Beulich wrote:
>> But as said before - I'm unconvinced this approach will scale,
>> because
>> you'll need to apply the wrapper to anything which can be reached
>> prior
>> to you enabling the MMU. Whether you can contain this to RISC-V-only
>> code is unclear; I don't think it'll be acceptable to change any part
>> of common code to meet your special needs.
> But it looks like it is only two places where it should be done:
> 1. As you mentioned LINK_TO_LOAD() should be applied for trap_causes.
> 2. And it should be applied inside do_bug_frame() for getting an
> start/end address of bug_frame. I want to note that do_bug_frame() will
> be removed after RISC-V is ready to switch to generic bug
> implementation.
> 
> The next step after the current patch series is merged is to enable
> MMU, so it shouldn't be new use cases where it is needed to use
> LINK_TO_LOAD().

I'm not convinced. You can't stick to using earlyprintk only beyond
very short term. Yet I expect you also don't want to use

    if ( early )
        earlyprintk();
    else
        printk();

everywhere in exception handling code (and anywhere else in code
which is reachable before the MMU is turned on). This extends to
uses of BUG() and alike in such early code, which - when they
trigger - want to use printk() (only). Whether printk(), somehow,
involves an array access similar to the ones you're presently
aware of you simply shouldn't depend on (it's an implementation
detail in a separate subsystem).

> If it is not acceptable to change any part of common code ( as I
> understand in this case it is do_unexpected_trap() and all that is
> called inside it ) have I to introduce two types of function
> do_unexpected_trap() for when MMU is enabled and not?

By "common code" I mean code outside of arch/riscv/. And I
sincerely hope you / we can get away without duplicated functions.

Jan



 


Rackspace

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