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

Re: [XEN v3 3/3] xen/arm: arm32: Add emulation of Debug Data Transfer Registers


  • To: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Mon, 8 Jan 2024 08:04:39 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=dKQtOyRkz5+WPtir3GirxqfxFG9EnfV5sTKwbH5cLf0=; b=CIN+1EED8+7y4VuwVSusfaXPKOiw+AluxQdGWDoKI7JbKsUlQY50SYV5zQfGGQLwkAFhedkbvawocIiKhM0Afz/VLXt/RArDdY66yvMixcjrUS3/qKTbcHtKsWA/aTBeFSkK0G5dtsQKYhM+o0l9b3+/NgB6InxXJDnBlr1sG1MqhKcKEUqZg6LdwvOSk/ie+AJY/wq1XpOjykW2kJc+GVE8z+fReh8WqWzTTyPbjpxinG7MHyX4YknOe8wuUvGq09ReRKuosZCx0vrYBiAtSJFnIJ4+kgTu6Pi5Opr3JKoHBzUZh4MzNwTWg5IR1eT07vy30RrD9K5mEToca1Aryw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D/NfQfHS2wqN+6xs2nJufbnyXKNvH6Q26GiEdCtuMtUdoPfLyTB7ALKr/DPOt7iqPs6j5bvQyOu3OsGx5Jo8EPaFwNnRBO0EaoSN2nvZ9RXz0e4XcR/kM/2XyscorxA5Hy2hUG2yUdxlvsr1E7nS7quCfAtIcE1kLHTzJezlJzUzIznIgUJ6WeQDWRaySZ1OoBPDx4LwS19oNrLYLaHf2FW5oaSbO6HHaRixSFIXPtmJyVpNeYD/QIlWIpd4uMmHYqHmZ6QJiTDg4GTEyYjlazQPTclE2E+5FGe3M6cdemHxfoIS1Q8P/1DgpKCH4IXWLtc7ZnQtHKVwZCsjaBTKpA==
  • Cc: <sstabellini@xxxxxxxxxx>, <stefano.stabellini@xxxxxxx>, <julien@xxxxxxx>, <Volodymyr_Babchuk@xxxxxxxx>, <bertrand.marquis@xxxxxxx>
  • Delivery-date: Mon, 08 Jan 2024 07:05:09 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Ayan,

On 05/01/2024 12:21, Ayan Kumar Halder wrote:
> DBGOSLSR is emulated in the same way as its AArch64 variant (ie OSLSR_EL1).
> This is to ensure that DBGOSLSR.OSLK is 0, thus MDSCR_EL1.TXfull is treated
> as UNK/SBZP.
No need for this dot and yet another thus (it reads difficult).
You explained the OSLK bit, but you are not emulating this reg as ro_raz. 
Instead you
copied the code from AArch64 (ro_read_val) which also sets OSLM[1] bit. Do we 
want the same handling
given that Linux on arm32 does not make use of it?

> Thus only MDCCSR_EL0 can be emulated (which is DBGDSCRINT on arm32).
> DBGDSCRINT can be accessed at EL0 as DBGDSCREXT is emulated as RAZ (as
> DBGOSLSR.OSLK == 0). DBGDSCRINT.TXfull is set to 1.
Even though this patch comes after the one explaining the need of emulating DCC
I would still expect some reasoning here. Someone reading the vcpreg code and 
checking the commit
behind would not know the rationale behind this patch.

Allowing access DBGDSCRINT from EL0 is a fix, so I would make it clear by 
starting a sentence
with "Take the opportunity to fix the minimum EL for DBGDSCRINT ...".

> 
> Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint
> "If TXfull is set to 1, set DTRTX to UNKNOWN".
> So, DBGDTR[TR]XINT is emulated as RAZ/WI.
> 
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
> ---
> Changes from
> 
> v1 :- 1. DBGDTR_EL0 does not emulate RXfull. This is to avoid giving the OS 
> any
> indication that the RX buffer is full and is waiting to be read.
> 
> 2. In Arm32, DBGOSLSR is emulated. Also DBGDTRTXINT is emulated at EL0 only.
> 
> 3. Fixed the commit message and inline code comments.
> 
> v2 :- 1. Split the patch into two (separate patches for arm64 and arm32).
> 2. Fixed in line comments and style related issues.
> 3. Updated commit message to mention DBGDSCRINT handling.
> 
>  xen/arch/arm/include/asm/cpregs.h |  2 ++
>  xen/arch/arm/vcpreg.c             | 36 ++++++++++++++++++++++---------
>  2 files changed, 28 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/cpregs.h 
> b/xen/arch/arm/include/asm/cpregs.h
> index 6b083de204..aec9e8f329 100644
> --- a/xen/arch/arm/include/asm/cpregs.h
> +++ b/xen/arch/arm/include/asm/cpregs.h
> @@ -75,6 +75,8 @@
>  #define DBGDIDR         p14,0,c0,c0,0   /* Debug ID Register */
>  #define DBGDSCRINT      p14,0,c0,c1,0   /* Debug Status and Control Internal 
> */
>  #define DBGDSCREXT      p14,0,c0,c2,2   /* Debug Status and Control External 
> */
> +#define DBGDTRRXINT     p14,0,c0,c5,0   /* Debug Data Transfer Register, 
> Receive */
> +#define DBGDTRTXINT     p14,0,c0,c5,0   /* Debug Data Transfer Register, 
> Transmit */
>  #define DBGVCR          p14,0,c0,c7,0   /* Vector Catch */
>  #define DBGBVR0         p14,0,c0,c0,4   /* Breakpoint Value 0 */
>  #define DBGBCR0         p14,0,c0,c0,5   /* Breakpoint Control 0 */
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index a2d0500704..474f872b5f 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -493,11 +493,12 @@ void do_cp14_32(struct cpu_user_regs *regs, const union 
> hsr hsr)
>       * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
>       *
>       * Unhandled:
> -     *    DBGOSLSR
>       *    DBGPRCR
>       */
>      case HSR_CPREG32(DBGOSLAR):
>          return handle_wo_wi(regs, regidx, cp32.read, hsr, 1);
> +    case HSR_CPREG32(DBGOSLSR):
> +        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 1, 1U << 3);
>      case HSR_CPREG32(DBGOSDLR):
>          return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>  
> @@ -509,8 +510,6 @@ void do_cp14_32(struct cpu_user_regs *regs, const union 
> hsr hsr)
>       *
>       * Unhandled:
>       *    DBGDCCINT
> -     *    DBGDTRRXint
> -     *    DBGDTRTXint
>       *    DBGWFAR
>       *    DBGDTRTXext
>       *    DBGDTRRXext,
> @@ -549,11 +548,24 @@ void do_cp14_32(struct cpu_user_regs *regs, const union 
> hsr hsr)
>      }
>  
>      case HSR_CPREG32(DBGDSCRINT):
> +    {
>          /*
> -         * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
> -         * is set to 0, which we emulated below.
> +         * Xen doesn't expose a real (or emulated) Debug Communications 
> Channel
> +         * (DCC) to a domain. Yet the Arm ARM implies this is not an optional
> +         * feature. So some domains may start to probe it. For instance, the
> +         * HVC_DCC driver in Linux (since f377775dc083 and at least up to 
> v6.7),
> +         * will try to write some characters and check if the transmit buffer
> +         * has emptied. By setting TX status bit to indicate the transmit 
> buffer
> +         * is full. This we would hint the OS that the DCC is probably not
> +         * working.
> +         *
> +         * Bit 29: TX full
> +         *
> +         * Accessible by EL0 if DBGDSCRext.UDCCdis is set to 0, which we 
> emulate
> +         * as RAZ/WI in the next case.
>           */
> -        return handle_ro_raz(regs, regidx, cp32.read, hsr, 1);
> +        return handle_ro_read_val(regs, regidx, cp32.read, hsr, 0, 1U << 29);
> +    }
>  
>      case HSR_CPREG32(DBGDSCREXT):
>          /*
> @@ -562,6 +574,13 @@ void do_cp14_32(struct cpu_user_regs *regs, const union 
> hsr hsr)
>           */
>          return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
>  
> +#ifdef CONFIG_PARTIAL_EMULATION
> +    /* DBGDTR[TR]XINT share the same encoding */
> +    case HSR_CPREG32(DBGDTRTXINT):
> +        if ( opt_partial_emulation )
> +            return handle_raz_wi(regs, regidx, cp32.read, hsr, 0);
> +#endif
> +
>      case HSR_CPREG32(DBGVCR):
>      case HSR_CPREG32(DBGBVR0):
>      case HSR_CPREG32(DBGBCR0):
> @@ -659,10 +678,7 @@ void do_cp14_dbg(struct cpu_user_regs *regs, const union 
> hsr hsr)
>       * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
>       *
>       * Unhandled:
> -     *    DBGDTRTXint
> -     *    DBGDTRRXint
> -     *
> -     * And all other unknown registers.
> +     * All unknown registers.
>       */
>      gdprintk(XENLOG_ERR,
>               "%s p14, %d, r%d, r%d, cr%d @ 0x%"PRIregister"\n",

Same comments apply as for the arm64 patch.

~Michal




 


Rackspace

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