On Mon, Sep 25, 2023 at 03:53:51PM +0100, Jonathan Cameron wrote: > On Mon, 25 Sep 2023 11:03:28 -0300 > Jason Gunthorpe <j...@nvidia.com> wrote: > > > On Mon, Sep 25, 2023 at 02:54:40PM +0100, Jonathan Cameron wrote: > > > > > Possible the ASWG folk would say this is fine and I'm reading too much > > > into > > > the spec, but I'd definitely suggest asking them via the appropriate path, > > > or throwing in a code first proposal for a comment on this special case > > > and > > > see what response you get - my guess is it will be 'fix Linux' :( > > > > The goal here is for qemu to emulate what the bare metal environment > > is doing. > > > > There may be a legitimate question if what the bare metal FW has done > > is legitimate (though let's face it, there are lots of creative ACPI > > things around), but I don't quite see how this is a qemu question? > > > > Unless you are taking the position that qemu should not emulate this > > HW? > > Ok. I'd failed to register that the bare metal code was doing this though > with hindsight I guess that is obvious. Though without more info or > a bare metal example being given its also possible the BIOS was doing > enumeration etc (like CXL does for all < 2.0 devices) and hence was > building SRAT with the necessary memory ranges in place - even if the > driver then does the hot add dance later.
Ankit, maybe you can share some relavent ACPI dumps from the physical hardware and explain how this compares? > That's dubious and likely to break at some point unless the spec > comprehends this use case, but meh, so are lots of other things and > the hardware vendor gets to pick up the pieces and deal with grumpy > customers. Yes. > I don't currently see this as a safe solution for the proposed other > use cases however that are virtualization only. So, how should that translate into a command line experiance? Sounds like the broad concept is general but this actual specific HW is not? Thanks, Jason
