Re: Thoughts about introducing virtio-cpu

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

 



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.

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.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux