From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7F5BDC44501 for ; Mon, 13 Jul 2026 09:58:05 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1361576.1613763 (Exim 4.92) (envelope-from ) id 1wjDPz-0007bX-14; Mon, 13 Jul 2026 09:57:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1361576.1613763; Mon, 13 Jul 2026 09:57:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wjDPy-0007bQ-To; Mon, 13 Jul 2026 09:57:42 +0000 Received: by outflank-mailman (input) for mailman id 1361576; Mon, 13 Jul 2026 09:57:41 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wjDPx-0007aB-84 for xen-devel@lists.xenproject.org; Mon, 13 Jul 2026 09:57:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wjDPv-00DGit-7Y for xen-devel@lists.xenproject.org; Mon, 13 Jul 2026 11:57:39 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a54b68f-bab6-0a2a0a5309dd-0a2a4503e58a-16 for ; Mon, 13 Jul 2026 11:57:39 +0200 Received: from [209.85.208.171] (helo=mail-lj1-f171.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.2) (envelope-from ) id 6a54b692-f2d2-0a2a45030019-d155d0abc8da-3 for ; Mon, 13 Jul 2026 11:57:39 +0200 Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-39ca300db70so13230001fa.2 for ; Mon, 13 Jul 2026 02:57:39 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b01ca55723sm2715221e87.35.2026.07.13.02.57.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2026 02:57:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783936658; x=1784541458; darn=lists.xenproject.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=E8ZFAs9qXx3g/86C5aQ3vsXA/85ozIDf5zoPqhpvTN4=; b=Ibbrl77Gz1Hl6iZaMYIGVX7tFGBJdEZ5kVTLq3LnHX+Y9AptqFD3+ITVY4rBvX+i/Y BfHlV2bET+PmVUEqcYqDATc5uNGVuER4+XATx7RhaEUO+kLUuA9UcGt1qK8xZDQW4f+X 1Bgy+H+jZPnN12aKeCRIMs0vARWAJiXaMpMZcIbHi0eU+xnX4wvtr9rR90nUTAkY4/TF 2Z2Z72xxPiiqP9x52Ws31GpBvFn0CpZ0k6F6trZGtl5Z9dxbf5Y1q7alz5xTAPm/ev1S QZOUBbCvsQeuII+Nr1zCJY7t98R3mvr7jGjzj8qpvD2IpXrdh91ZsKH3ASwHn6/tRvXD pDJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783936658; x=1784541458; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=E8ZFAs9qXx3g/86C5aQ3vsXA/85ozIDf5zoPqhpvTN4=; b=DTf+C40FWfYOpCNvmlhW/LvZyo/o3n6ol1YvK/yqsJMH0sUCm7gosgT5jTdhYiseLQ F7t6OA0OXRB6TaWLkm2h+iMusSPfMmtm5Lu4DfyeUySHII1+Qi/o2lUspK8SV2uGcQiC +7yPKBIZwF4JPSo296AFo2KJrr7Ov9a8g+4T7DLGDG3Wdp6bVChMhSYObw8Atwmgccym 8t/6XNpG9dhpCFvDDx67MWUZkXetBpXVzCRFk5K8C27w38PjkvxQDC/uSq+65oNuVFaD +nDtPGWuqGaWSO275kehTKnnunBTxMknajoH183wymRRe5NUASvn4i/oGlLKYJ8WobY0 eHww== X-Forwarded-Encrypted: i=1; AHgh+Ro4P95Q2cE4bpGbPrtrmsgHi3Qsbm3FXpjZTT9OEjdtUkuRDDT18YYkhM0ndQ8Ene1RXkV5wZnB/6I=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzq4O67YY4d3cvyHIep+5nEUSXxSlNKOSQ9vgkk835Eyb7DTxNJ +O79UaFBYsWMSYPyRQMo28I5o1ZfakKHMe+FdAi6WJJfLhLL9edIQxYJ X-Gm-Gg: AfdE7cmOicQZSI2kDarqct3Gimt2WZoEzF+gRE+YvQ6WuM+PlullMJsSDw5S0JYA8Pg 6jO3rbCHeB1CL0XgFpBmN7VOFl7YQgV5hiJHe2qTUyx8egdislWeOHGdVGWlm3rmXgb7NtEVGQx LXi0DkWGtZchtWGPMJs7tr/P5q3Ni6PzUgijrMSLa3fl5nf7vq3WftZtr2YWrStTU5NsVnX0dQy ZIT1vXP6EKf6aMME8kbeKBMdSbhaS3BzTzWhyQJWcAovCGtoKhAJ+WcvajAmPaNvw+7/Wq2xsDl ANUO1SGrkLMbaPL5JmJBGi3BP5MVvqmxeS2IL/0er6BisAk2iJSWWsYax9yXA7e6zaL/Ev9LaiY w/TYvYlF4xKBy0kWVwXat3P+ByuTH0wRn6/BGM1el6aMKKaC10OHRR3FswdMlOPynXkMzeN3gKn YcHJ3FX2NvOgzK0/6ySJHqlxnDJZnMCGrROcqQKNM5AwwFV1YgxQbLF6aW56x38YsmCmQvAn5wH zZwEg== X-Received: by 2002:ac2:50d8:0:b0:5ae:b357:1d1a with SMTP id 2adb3069b0e04-5b02356ca07mr1111984e87.8.1783936658234; Mon, 13 Jul 2026 02:57:38 -0700 (PDT) Message-ID: <2d0877f5-2fc1-4f53-b662-c377788e02ca@gmail.com> Date: Mon, 13 Jul 2026 11:57:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 17/26] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure To: Jan Beulich Cc: Romain Caritey , Baptiste Le Duc , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <1f51410c080599a5c80173398d9db837b8718356.1783331040.git.oleksii.kurochko@gmail.com> <6a4adfa7-ec9a-4cbd-a9e2-571293cbb1ed@suse.com> <69d18359-3fae-4618-b46a-ad52bcf1a027@gmail.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-33051d/1783936659-C1359CF4-B2FCC63B/10/73395122804 X-purgate-type: spam X-purgate-size: 3742 On 7/13/26 8:41 AM, Jan Beulich wrote: > On 10.07.2026 17:52, Oleksii Kurochko wrote: >> On 7/9/26 5:39 PM, Jan Beulich wrote: >>> On 06.07.2026 17:57, Oleksii Kurochko wrote: >>>> At the current development stage, only domain vINTC init and deinit >>>> operations are required, so implement those first. >>>> >>>> Initialize vAPLIC's domaincfg to with the interrupt-enable bit set and >>>> MSI delivery mode selected as the current solution is exepcted to have >>>> always IMSIC, and initialize vintc->ops. >>> >>> How would domaincfg be initialized on real hardware? >> >> Xen will initialize that in aplic_init_hw_interrupts(): >> writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); > > I.e. it is very much something the OS should do. > >> I can see that maybe >>> firmware would have to set DM suitably (and you may mean to take firmware's >>> role here). >> >> I don't think that firmware will do that (and OpenSBI for example >> doesn't do that). If firmware can do that we for sure want to control in >> Xen what is written to ->domaincfg. >> >>> But isn't setting at least IE entirely the OSes responsibility? >> >> At least, Linux setups ->domaincfg once at the boot time: >> >> /* Setup APLIC domaincfg register */ >> val = readl(priv->regs + APLIC_DOMAINCFG); >> val |= APLIC_DOMAINCFG_IE; >> if (msi_mode) >> val |= APLIC_DOMAINCFG_DM; >> writel(val, priv->regs + APLIC_DOMAINCFG); >> if (readl(priv->regs + APLIC_DOMAINCFG) != val) >> dev_warn(priv->dev, "unable to write 0x%x in domaincfg\n", val); >> >> And don't touch this register anymore, even for interrupt disablement it >> isn't used. >> >> So Xen can just does once: >> writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); >> >> and then just properly handle access of a guest to domaincfg. > > Xen can do this for itself, sure. But shouldn't domaincfg as seen by guests > start out 0 then? Now I think I understand your point. I agree that it should start from 0 (or from 0x80000000, since bits 31:24 are read-only and fixed to 0x80). All other bits should be set or cleared by the guest and written to vaplic->regs.domaincfg when the guest accesses the vAPLIC domaincfg register. In that case, domain_vaplic_init() should initialize ->domaincfg as: vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; instead of: vaplic->regs.domaincfg = APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM | APLIC_DOMAINCFG_RO; > >>>> --- a/xen/arch/riscv/include/asm/aplic.h >>>> +++ b/xen/arch/riscv/include/asm/aplic.h >>>> @@ -15,6 +15,8 @@ >>>> >>>> #include >>>> >>>> +/* domaincfg bits 31:24 are read-only 0x80 */ >>>> +#define APLIC_DOMAINCFG_RO (0x80U << 24) >>> >>> Bit 7 is also documented as read-only 0. Wouldn't the comment better reflect >>> that as well? >> >> Not sure, bits 31:24 are read-only *0x80* but bit 7 is read-only *0*. > > And would it hurt if the comment said so, to avoid any ambiguity? Of course, it won't I will update the comment. > >>>> #define APLIC_DOMAINCFG_IE BIT(8, U) >>>> #define APLIC_DOMAINCFG_DM BIT(2, U) >>> >>> Wouldn't you better spell out BE as well? >> >> I can add: >> #define APLIC_DOMAINCFG_BE BIT(0, U) >> >> But it isn't used at the moment (Linux also defines it but never >> actually using it). Do you want still to add that now? > > Imo it would be better to have a complete set of definitions. If you > don't allow guests to set this bit, perhaps to emit a sufficiently > informative debug log messages you may want to use the #define? Agree, it make sense. Thanks. ~ Oleksii