On Tue, Jan 30, 2024 at 05:00:43PM +0800, lixianglai wrote:
> > > +static int
> > > +virCPULoongArchUpdate(virCPUDef *guest,
> > > + const virCPUDef *host ATTRIBUTE_UNUSED,
> >
> > G_GNUC_UNUSED
>
> OK!
Please feel free to *not* explicitly acknowledge every single review
comment separately. Unless you disagree with the comment, or want to
clarify something, it is usually assumed that it has been heard and
will be acted upon in the next revision.
This also allows you to liberally drop big chunks of the original
message on reply, just like I've done here, and keep messages short
and focused :)
> > In a later patch, when you actually implement loongarch64 support in
> > the QEMU driver, you can add this logic. When you do, please also set
> >
> > addDefaultUSB = false;
> > addDefaultMemballoon = false;
> >
> > The default behavior, which is to add these devices automatically for
> > all new domains, mainly exists to ensure backwards compatibility in
> > the context of x86, and we've moved away from it for architectures
> > that have been introduced more recently, such as aarch64 and RISC-V.
>
> After I added the following logic to loongarch,
> I found that creating a loongarch virtual machine no longer
> creates a USB keyboard and mouse by default.
>
> addDefaultUSB = false;
>
> I tried to create the aarch64 virt virtual machine and found that it did not create a USB keyboard and mouse and
> did not have spice graphics only serial port. In the case of aarch64,
> I think it is reasonable to have no USB keyboard and mouse,
> but loongarch64 can launch a graphical interface.
aarch64 and riscv64 VMs can also run a GUI just fine. That doesn't
mean that a USB controller should be present in every single VM.
> How do We control a virtual machine without a USB keyboard and mouse in the graphical interface?
> I don't quite understand what's the point of adding it.
If you want a USB controller, you can just add one :)
Back when the libvirt project was started, only the x86 architecture
was really considered and I'm not even sure QEMU provided a way to
fine-tune the virtual hardware configuration to the point where
creating a VM with no USB controller was possible. So every VM would
get one.
Later on, the ability to opt out was implemented via the use of
<controller type='usb' model='none'/>
While that works, it is a bit clunky, and from the semantics point of
view it just feels wrong that you would need to *add* some XML
element to get libvirt to *remove* a device.
With that in mind, when introducing support for aarch64 and riscv64
the choice was made to flip the default around and build very minimal
VMs by default.
Note that virt-manager will still default to adding a bunch of
devices, including the USB controller, for new VMs, even for those
architectures. But at the libvirt level we intentionally keep things
lean.
To that end, I have just pushed the following patch:
commit d583ff601f9f1906b46b5dd38236cdf1aec821ef
Author: Andrea Bolognani <abologna@xxxxxxxxxx>
Date: Tue Jan 16 19:14:56 2024 +0100
qemu: Default to no USB and no memballoon for new architectures
The current defaults, that can be altered on a per-architecture
basis, are derived from the historical x86 behavior.
Every time support for a new architecture is added to libvirt,
care must be taken to override these default: if that doesn't
happen, guests will end up with additional hardware, which is
something that's generally undesirable.
Turn things around, and require architectures to explicitly
ask for the devices to be created by default instead. The
behavior for existing architectures is preserved.
Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
Reviewed-by: Peter Krempa <pkrempa@xxxxxxxxxx>
which makes this intention more explicit.
loongarch64 should follow the example set by aarch64 and riscv64.
> As above, with the following logic, the memory space in guest os will not
> scale.
>
> addDefaultMemballoon = false;
Same as above: using the memballoon will still be possible, it's just
that it will be an opt-in feature instead of an opt-out one.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
