qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v6 1/2] qom: new object to associate device to numa node


From: Ankit Agrawal
Subject: Re: [PATCH v6 1/2] qom: new object to associate device to numa node
Date: Tue, 16 Jan 2024 14:02:44 +0000

>> >
>> > Given that, an alternative proposal that I think would work
>> > for you would be to add a 'placeholder' memory node definition
>> > in SRAT (so allow 0 size explicitly - might need a new SRAT
>> > entry to avoid backwards compat issues).
>>
>> Putting all the PCI/GI/... complexity aside, I'll just raise again that
>> for virtio-mem something simple like that might be helpful as well, IIUC.
>>
>>       -numa node,nodeid=2 \
>>       ...
>>       -device virtio-mem-pci,node=2,... \
>>
>> All we need is the OS to prepare for an empty node that will get
>> populated with memory later.
>>
>> So if that's what a "placeholder" node definition in srat could achieve
>> as well, even without all of the other acpi-generic-initiator stuff,
>> that would be great.
>
> Please no "placeholder" definitions in SRAT. One of the main thrusts of
> CXL is to move away from static ACPI tables describing vendor-specific
> memory topology, towards an industry standard device enumeration.

So I suppose we go with the original suggestion that aligns with the
current spec description pointed by Jonathan, which is the following:

A separate acpi-generic-initiator object that links only one node to the
device. For each such association, a new object would be created.

A previously mentioned example from Jonathan:
  -object acpi-generic-initiator,id=gi1,pci-dev=dev1,nodeid=10
  -object acpi-generic-initiator,id=gi2,pci-dev=dev1,nodeid=11

> It is strictly OS policy about how many NUMA nodes it imagines it wants
> to define within that playground. The current OS policy is one node per
> "window". If a solution believes Linux should be creating more than that
> I submit that's a discussion with OS policy developers, not a trip to
> the BIOS team to please sprinkle in more placeholders. Linux can fully
> own the policy here. The painful bit is just that it never had to
> before.

Whilst I agree that Linux kernel solution would be nice as a long term
solution, such change could be quite involved and intrusive.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]