On Tue, Apr 02, 2019 at 11:54:01AM +0200, David Hildenbrand wrote: > 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. I agree. Let me clarify that though: Those hypervisors have been designed with a very well defined and restricted set of use cases in mind. For those, for all of those, they don't need ACPI or even hotplug. > Just as I thought, right now > people don't need it. Expect it to be requested at one point. True. I think the point is to experiment and see if some features can be made standalone and not depend on fairly large dependencies like for example (and this is just an example, we're not trying to pick on it) ACPI. If they can then you could build a more flexible VMM able to better support use cases like the Firecracker ones, while being able to enhance it for more complex use cases that would really need e.g. ACPI. Cheers, Samuel. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
