On Fri, 30 Nov 2018 18:59:21 +0100
David Hildenbrand <david@redhat.com> wrote:
> Let's introduce new types for different kinds of memory blocks and use> them in existing code. As I don't see an easy way to split this up,> do it in one hunk for now.> > acpi:> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.> Properly change the type when trying to add memory that was already> detected and used during boot (so this memory will correctly end up as> "acpi" in user space).> > pseries:> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.> As far as I see, handling like in the acpi case for existing blocks is> not required.> > probed memory from user space:> Use DIMM_UNREMOVABLE as there is no interface to get rid of this code> again.> > hv_balloon,xen/balloon:> Use BALLOON. As simple as that :)> > s390x/sclp:> Use a dedicated type S390X_STANDBY as this type of memory and it's> semantics are very s390x specific.> > powernv/memtrace:> Only allow to use BOOT memory for memtrace. I consider this code in> general dangerous, but we have to keep it working ... most probably just> a debug feature.
I don't think it should be arbitrarily restricted like that.
Thanks
Michal

On 04.12.18 10:44, Michal Suchánek wrote:
> On Fri, 30 Nov 2018 18:59:21 +0100> David Hildenbrand <david@redhat.com> wrote:> >> Let's introduce new types for different kinds of memory blocks and use>> them in existing code. As I don't see an easy way to split this up,>> do it in one hunk for now.>>>> acpi:>> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.>> Properly change the type when trying to add memory that was already>> detected and used during boot (so this memory will correctly end up as>> "acpi" in user space).>>>> pseries:>> Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel.>> As far as I see, handling like in the acpi case for existing blocks is>> not required.>>>> probed memory from user space:>> Use DIMM_UNREMOVABLE as there is no interface to get rid of this code>> again.>>>> hv_balloon,xen/balloon:>> Use BALLOON. As simple as that :)>>>> s390x/sclp:>> Use a dedicated type S390X_STANDBY as this type of memory and it's>> semantics are very s390x specific.>>>> powernv/memtrace:>> Only allow to use BOOT memory for memtrace. I consider this code in>> general dangerous, but we have to keep it working ... most probably just>> a debug feature.> > I don't think it should be arbitrarily restricted like that.>
Well code that "randomly" offlines/onlines/removes/adds memory blocks
that it does not own (hint: nobody else in the kernel does that), should
be restricted to types we can guarantee to work.
> Thanks> > Michal>