[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS
- To: Julien Grall <julien@xxxxxxx>, Luca Fancellu <Luca.Fancellu@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
- From: "Halder, Ayan Kumar" <ayankuma@xxxxxxx>
- Date: Sat, 18 Apr 2026 08:13:13 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.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=arcselector10001; 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=THLwUhVuLXf0NKR0jU1AkBr69GtDTI4t2rIMBmNEEmI=; b=XCAahBd42h8rsFabIDTjOEfMJLnyZk318nE5onbXTTv7ztaLttChYWN3Q7NRXJ/t/r0zpyDRLvbeOxoxc+lP3nhz+FLfyA/0ieISzA1tchLZOG5k2hLIAfm5xLhLg+BxvG/sM/kBL3jCMViV1c4lOihJMaICiNeYB3QpWA6yVrXhBgt+89gc7PlaQKy0kJFkaG1By0AG7t0zZg3wCuEAnYl5xMOSzywWNdAob/kuVRXJeJGkfUmEzmI2n0VT0hdFWHXSBC6Dx46AOzmaYVqTxZYIB9V+STKiou53ea4ewyCRtUW9Pwbsnl0dbHU/0l8CzkQVMDWwZRhfGRSF4RldvQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yRRgQLRJqskRP9cv4dGaQK1TQLmDlqgQs7TDe75fX2neJE+29bs2+E+hXKMuDRCXK+wy2PjiM6q7ALye7Dqyps9Xz7NbFLd+90gbodY2h2/Em3bTHSA/9QWLAt1b0UTxDjqbvOB2lhg+9QW1AW9/qJv35LlnmmNfbiCVa128Qi2V5pTlqxt81XyQFvcjXzP9dJSU6zSZrsO1dAFU1uHBORtcQKzlIyhxQr+0zpcBFyIqNYOB4atACUlUvpDhM44Z7/pVwxFI5m7UqJUV2vdSZLxvH1Ua0H3sPzh683xj3lYo5VKQqchFywIoVIT/SD3ea3sgxUCcFMRHH1F9w0N1nw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>
- Delivery-date: Sat, 18 Apr 2026 07:13:33 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 14/04/2026 03:10, Julien Grall wrote:
Hi,
Hi Julien,
On 08/04/2026 23:24, Luca Fancellu wrote:
@@ -203,6 +209,10 @@ static uint64_t gicv3_ich_read_lr(int lr)
static void gicv3_ich_write_lr(int lr, uint64_t val)
{
+ /* WI for unsupported LR */
+ if ( lr >= LRS )
+ return;
+
switch ( lr )
{
case 0:
Now, since we are using CONFIG_GICV3_NR_LRS or gicv3_info.nr_lrs in
gicv3_save_lrs/gicv3_restore_lrs,
there are other part of the codebase using nr_lrs (gic_get_nr_lrs()
is one of them), but all the callers of that
function will use the HW nr_lrs and not the CONFIG_GICV3_NR_LRS, so I
think some work needs to be done
to align them or there will be mismatches at runtime with possible
loss of information.
+1. We need a consistent view for the number of LRs. I could also see
a use case where the integrator wants to support less LRs than what
the HW supports (this doesn't seem to be prevented with this patch).
This scenario is ok. In this case, we should use the value provided by
the GICV3_NR_LRS. I don't think this should be something we want to
prevent. Or I might be missing something ?
The issue is with the opposite situation. If GICV3_NR_LRS is greater
than what the hardware supports, we should print a warning. And let Xen
use the value GICV3_NR_LRS.
Note, during Xen boot, we may need to zero the LRs which are unused as
they may potentially contain active interrupts.
Ack.
- Ayan
Cheers,
|
