All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Julien Grall <julien@xen.org>, Ard Biesheuvel <ardb@kernel.org>,
	Jan Beulich <jbeulich@suse.com>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Rahul Singh <Rahul.Singh@arm.com>,
	Peter Griffin <peter.griffin@linaro.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Julien Grall <jgrall@amazon.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table
Date: Tue, 06 Sep 2022 16:18:54 +0100	[thread overview]
Message-ID: <87mtbcv8dd.wl-maz@kernel.org> (raw)
In-Reply-To: <YxdjlddwusPJ4GTU@leoy-huanghe.lan>

On Tue, 06 Sep 2022 16:13:25 +0100,
Leo Yan <leo.yan@linaro.org> wrote:
> 
> On Tue, Sep 06, 2022 at 08:53:02AM +0100, Marc Zyngier wrote:
> 
> [...]
> 
> > > Okay, I think have two questions for you:
> > > 
> > > - The first question is if we really need to reserve persistent memory
> > >   for RD pending table and configuration table when Linux kernel runs
> > >   in Xen domain?
> > 
> > I have no idea, and really I don't want to know. The architecture
> > doesn't make it safe to reuse that memory, and the driver does the
> > right thing by always reserving that memory when the FW is supposed to
> > support it.
> > 
> > The "oh but it is safe on so and so" approach doesn't scale. If you
> > want to have such a thing, just convince people at ARM that it is
> > possible to implement a GICv3-compliant system without the RD tables,
> > get them to update the architecture to allow this scheme and advertise
> > it in a discoverable register. Xen could then implement it, Linux
> > could check this bit, and we'd all be a happy family.
> 
> I agree that my patch is not based on a scale approach, this is also
> my concern.
> 
> To be honest, convincing Arm GIC team is a bit out of my working scope.
> I am working on automative project, when I saw verbose log with bunch of
> kernel warnings with Xen, it motivated me to chase down, this is the
> main reason I tried to explore some solutions at here.

And it is fine to explore things. But I don't think there is a cheap
option here.

[...]

> > - When the kexec kernel boots, all of the memory except for the
> >   reserved memory is reused. If your RD tables are used for anything,
> >   you'll see memory corruption as the GIC writes pending bits in the
> >   pending table, and you'll be unable to configure interrupts
> >   correctly.
> 
> This gives me impression that when do a power cycle, CPUs are reset
> but GIC is still alive, so for every booting time the same memory
> region should be reserved for RD tables.
>
> To be honest, it's a bit weird for me that if a system cannot reset
> CPUs and GIC together.

There is no reset involved across kexec. That's the whole point.
Nothing is reset, nothing is powered off. This is why kexec is so
fast, and this is why it is so fragile.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2022-09-06 15:19 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 10:57 [PATCH] xen/arm: acpi: Support memory reserve configuration table Leo Yan
2022-08-17 13:17 ` Jan Beulich
2022-08-17 13:49   ` Ard Biesheuvel
2022-08-18  9:15     ` Leo Yan
2022-08-18  9:33       ` Ard Biesheuvel
2022-08-18 10:04         ` Julien Grall
2022-08-18 15:49           ` Leo Yan
2022-08-18 16:24             ` Ard Biesheuvel
2022-08-19 12:10               ` Marc Zyngier
2022-08-25  7:59                 ` Leo Yan
2022-08-25  9:07                   ` Julien Grall
2022-08-25 11:24                     ` Leo Yan
2022-08-25 12:51                       ` Julien Grall
2022-08-25 11:50                     ` Leo Yan
2022-08-25 12:59                       ` Julien Grall
2022-08-25 14:40                         ` Leo Yan
2022-09-06  2:52                           ` Leo Yan
2022-09-06  6:27                             ` Marc Zyngier
2022-09-06  7:17                               ` Leo Yan
2022-09-06  7:22                                 ` Ard Biesheuvel
2022-09-06  7:27                                   ` Leo Yan
2022-09-06  7:43                                     ` Leo Yan
2022-09-06  8:28                                     ` Marc Zyngier
2022-09-06  7:53                                 ` Marc Zyngier
2022-09-06 15:13                                   ` Leo Yan
2022-09-06 15:18                                     ` Marc Zyngier [this message]
2022-08-18  9:40       ` Marc Zyngier
2022-08-18  7:34   ` Leo Yan
2022-08-18  7:47     ` Jan Beulich
2022-08-18  8:46       ` Leo Yan
2022-08-18  8:52         ` Jan Beulich
2022-08-18  7:57     ` Julien Grall
2022-08-18  8:28       ` Leo Yan
2022-08-18 13:24       ` Bertrand Marquis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtbcv8dd.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Rahul.Singh@arm.com \
    --cc=ardb@kernel.org \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.com \
    --cc=julien@xen.org \
    --cc=leo.yan@linaro.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=peter.griffin@linaro.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.