[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table
On Tue, 06 Sep 2022 16:13:25 +0100, Leo Yan <leo.yan@xxxxxxxxxx> 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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |