On 02.04.19 11:49, Samuel Ortiz wrote: > On Tue, Apr 02, 2019 at 11:37:04AM +0200, David Hildenbrand wrote: >> On 02.04.19 11:34, Samuel Ortiz wrote: >>> On Tue, Apr 02, 2019 at 10:12:28AM +0200, Igor Mammedov wrote: >>>> On Tue, 2 Apr 2019 09:56:13 +0200 >>>> David Hildenbrand <david@xxxxxxxxxx> wrote: >>>> >>>>>>> >>>>>>> I guess there will be quite some issues to be sorted out. >>>>>>> >>>>>> >>>>>> That's what I'm getting from the several feedback I got so far. But the >>>>>> more fundamental question is about the need for it. If you think this >>>>>> goes in the right direction to make things more generic and >>>>>> architecture agnostic, it might be worth the effort of trying to design >>>>>> such solution. If instead you think this will be reinventing the wheel >>>>>> and will not benefit any use case, then let's not waste some time on >>>>>> this. >>>>>> >>>>> >>>>> I think, the general cpu hotplug/unplug infrastructure in QEMU is pretty >>>>> much generic. The only special case most probably is hotplugging >>>>> different topologies. But the general "device_add $MODEL-$ARCH-cpu, >>>>> id=$ID..." + device_del $ID is most probably easy to deal with by QEMU >>>>> users. >>>>> >>>>> The main issue I think really is different hot(un)plug support per >>>>> architecture. We heard that there might be a solution for s390x soon. I >>>>> wonder what about other architectures. >>>>> >>>>> Of course, if people want to scrap ACPI completely, then >>>> question is why one would want this and what we would be trying to achieve doing so? >>>> >>>> If ACPI is removed completely then one would need to provide >>>> an alternative means to describe various HW which is main purpose of ACPI >>>> ACPI bytecode methods is just a nice icing on top of that >>>> which helps to abstract drivers from HW/firmware. >>>> >>>> Idea to use non standard DT instead looks like a horrible >>>> alternative instead. >>> The idea is to run without ACPI or DT. The kernel does not need to be >>> custom built. A generic Linux kernel can easily boot without ACPI or DT, >>> or any kind of HW description. Firecracker is an obvious use case for >>> that where there really is no point in having a hw description when you >>> can simply use the kernel command line for describing a set of >>> statically defined and immutable resources. crosvm goes a little >>> further with a more dynamic device model, PCI based, and still without >>> ACPI or DT. >> >> Just wondering, what about things like NUMA or such? > In general those workloads do not need NUMA support. And obviously you > can boot a NUMA enabled kernel on top of those VMMs and it will use a > fake NUMA node with the whole physical RAM used as its single memory > bank. "In general" - this is the interesting bit. Just as I thought, right now people don't need it. Expect it to be requested at one point. Just like memory hotplug of cpus and memory is interesting. Not saying this isn't the right thing to do. If you make simplifications, you have to be prepared to deal with the fallout. This could mean not being able to support a feature even though customers request it. Fair enough. > > Cheers, > Samuel. -- Thanks, David / dhildenb
