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

Re: [PATCH v10 05/13] xen/arm: gic-v3: add ITS suspend/resume support


  • To: Mykola Kvach <xakep.amatop@xxxxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Wed, 3 Jun 2026 09:45:12 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=gmail.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; 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=3K04SnNvmuoqXDdseWyzW0mo5KOoIZOSJ89VXARP0bo=; b=m4ytC1cEjeeSbZoMy4x/DJDghY0G/5Gq5rdF5jb5yHMOk5rQr2aS7bAyq1FZ5EmUawqTsz4CPUPx9enFfOLF9vLTgiECyHawOue4B4sJY4MsN2I4Pk9tSnPoZmycGWwQDodkmHwY7ZqY1hEI4RgXntGwlT2K9iTxE4+ZJ4/pp1u01POsaQ+sF0wBqJcXwX+gzuhsSgWSOjoEb9+k3fa1kIukP1DkKNhUMaRONwCWgcgfQAO8xmwh9Mu79N4XMak2MitcwRpekRim5LhEE1vJMXnyARpjXl0lDeLK84WGOj26isOR9fRfaN7J3ZSPMslPEQYEwvus8Ev7NVk24I2DZw==
  • 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=3K04SnNvmuoqXDdseWyzW0mo5KOoIZOSJ89VXARP0bo=; b=VnFsz7Tj7wFAYLomoL/nAMJM40TlcXY24imC2KohW6fA5nMEiORTyWbmgng9LOMQSdLUsb3181XQWoa7ixvc46s3HeTHqInXEckwTKWWmcAdfIrgYeEN1/Acc/T9+FpgFUkBq/funw8u/mfQKqJR172+CxLG89HJlLq3hJuIj0neapILd4ghoGau52TUVA1iTuvT4NPjBg0UDLp8CDDU7/DaRIACZ0hHqk2FRa2CEVZIssC4L1rqe3Wv/3LnxeluXyhwjyJniNSEyAU2cH67I3yv5g5AgiHc4TMjXrHcFe7ficgMlb3iVTDxj00n27Affk1+g8dgpMn0l5mT6vR5Sw==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=IkjDPULBruaBfWkJIWnVpUmDiKyqB9w12YNxfaJpZujhRaL4VtNE8IQXkEQBfKSelntLMSbn7B6aItGqISR7TdlJCZRwWcotBRAtMkprjwR1TwVoR2mkpEXyCCo//WSShJhbTR/jpf+8xpFAeFMtATvbO0FdVGN5+w51NI4RinwkECy0uK5bnmqLLmQO2YFfQwJpzIUDzv9xKmdvBYbFuNLJhzjpcrxZJ4J8hGtjyTftuRrvpRRKJQEZ9n9BFOgBQMtGZY1ftQ7SFpQh7bbYQWYmjGoHoNGW776NHKzsBVuw/k1B00H0uHj+5WMx251WXgaPIEjEOhDMDe+LCBT3fQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PGhDdIlozrCzt70HvWHSjEoHDDjfobjGVQgqAaWgUulWULepHmTk8/9f5fbOnELeWI8EXLQMvgsYGx9Z7qNM71sAWHMumzdF9uzG1dx0bLYOSZib0+BKQ5M+Dk4pN1p8FGEfwcCfe2tMWS0GDPOcViuq7ZminWpjB/5F/HvVX/Rq+j85tQeNk8dpCqaESq6Gngq6Wnkou52N3aKhnKoPUqd1Bl72Rr4Gx+pdvWKSvBPy/OPgKDsbHCMJLMN8hn+TwOpE7aynjRkYybgenYiLdJmRmnaI1qRE/JpUoU2bam3dny+OBhJeYCKuYxa5oYK+7bUydiObiyhn9iDkkaicPg==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Mykola Kvach <mykola_kvach@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Wed, 03 Jun 2026 09:46:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Thread-index: AQHc6UoGT/kfd1Pv6US/NK5RLp1zNLYjx+kAgAig8gCAAD/FAA==
  • Thread-topic: [PATCH v10 05/13] xen/arm: gic-v3: add ITS suspend/resume support

Hi Mykola,

> On 3 Jun 2026, at 06:56, Mykola Kvach <xakep.amatop@xxxxxxxxx> wrote:
> 
> Hi Luca,
> 
> Thank you for the review.
> 
> On Thu, May 28, 2026 at 9:12 PM Luca Fancellu <Luca.Fancellu@xxxxxxx> wrote:
>> 
>> Hi Mykola,
>> 
>>> 
>>> +#ifdef CONFIG_SYSTEM_SUSPEND
>>> +int gicv3_its_suspend(void)
>>> +{
>>> +    struct host_its *its;
>>> +    int ret;
>>> +
>>> +    list_for_each_entry( its, &host_its_list, entry )
>>> +    {
>>> +        unsigned int i;
>>> +        void __iomem *base = its->its_base;
>>> +
>>> +        /*
>>> +         * By the time Xen reaches gic_suspend(), every domain is already 
>>> in
>>> +         * SHUTDOWN_suspend, so ITS-targeting interrupt sources are 
>>> expected
>>> +         * to have been quiesced by the owning OS before SYSTEM_SUSPEND.
>>> +         */
>>> +        /* Preserve saved GITS_CTLR state, excluding read-only QUIESCENT. 
>>> */
>>> +        its->suspend_ctx.ctlr = readl_relaxed(base + GITS_CTLR) &
>>> +                                ~GITS_CTLR_QUIESCENT;
>>> +        ret = gicv3_disable_its(its);
>>> +        if ( ret )
>>> +        {
>>> +            writel_relaxed(its->suspend_ctx.ctlr, base + GITS_CTLR);
>> 
>> This is writing enable from 0 to 1, while quiescent is still 0, which is 
>> unpredictable,
>> however it’s the same happening on Linux, so I would leave it to the 
>> maintainer preference.
> 
> I think you are right, thanks for spotting this.
> 
> After gicv3_disable_its() times out, the ITS has already had
> GITS_CTLR.Enabled cleared, but GITS_CTLR.Quiescent is still 0. Writing back
> the saved CTLR may set Enabled from 0 to 1 while Quiescent is 0, which is
> UNPREDICTABLE according to the spec.
> 
> So restoring GITS_CTLR in this error path does not look safe. We could extend
> the quiesce timeout if the current 100ms is considered too short, but once the
> wait has failed there is no architecturally safe way to restore the ITS state.
> In that case I think the suspend path should panic.

yes might be an option, but because we would diverge from Linux, I would leave 
it
to the maintainers.

Cheers,
Luca



 


Rackspace

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