On Thu, Dec 16, 2021 at 05:00:55PM +0100, Mark Burton wrote: > > > > On 16 Dec 2021, at 16:40, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Thu, Dec 16, 2021 at 04:28:29PM +0100, Paolo Bonzini wrote: > >> On 12/16/21 11:24, Markus Armbruster wrote: > >>>> Not really, in particular the startup has been mostly reworked already > >>>> and I disagree that it is messy. softmmu/vl.c is messy, sure: it has > >>>> N different command line parser for command line options, magic > >>>> related to default devices, and complicated ordering of -object > >>>> creation. > >>>> > >>>> But the building of emulator data structures is not messy; only the > >>>> code that transforms the user's instructions into startup commands. > >>>> The messy parts are almost entirely contained within softmmu/vl.c. > >>> > >>> In my opinion, the worst mess is the reordering and the (commonly > >>> unstated, sometimes unknown) dependencies that govern it. > >>> The reordering is part of the stable interface. Its finer points > >>> basically nobody understands, at least not without staring at the code. > >> > >> Then we agree, because that's what I meant by "the messy parts are almost > >> entirely contained within softmmu/vl.c". > >> > >>>> The one (and important, but fixable) exception is backends for > >>>> on-board devices: serial_hd, drive_get, and nd_table. > >>> > >>> Practical ideas on fixing it? > >> > >> What you did with pflash, turned up to 11. > >> > >>>>> * A new binary sidesteps the need to manage incompatible change. > >>>> > >>>> More precisely, a new binary sidesteps the need to integrate an > >>>> existing mechanism with a new transport, and deal with the > >>>> incompatibilities that arise. > >>> > >>> I'm not sure I got this. > >> > >> Configuring the VM part in CLI and part in QMP is not something anybody > >> needs nor should desire. A new binary can use the CLI only for things that > >> really have to be done before QMP is up, for example the configuration of > >> sandboxing or tracing; and even that is only nice-to-have and not > >> absolutely > >> necessary. > > > > I wouldn't special case sandboxing at least. It should be something that > > can be activated via a QMP command too. That way you can blockdev-add > > a bunch of disks and other backends while you are still relatively > > unconfined, and then lock it down with a sandbox before starting vCPUs. > > > > Or you can perhaps start with a coarse sandbox and then switch to > > a stronger sandbox part way through config (though can't remember > > offhand if that's possible with seccomp, or whether the first > > seccomp profile applied, prevents you adding stronger ones later). > > > > Anyway sandboxing doesn't need to be active before QMP IMHO, because > > our primary goal with it is to mitigate guest exploits from untrusted > > code - the initial startup is largely trustworthy. Starting guest CPUs, > > or reading VMState is where it becomes dangerous generally. > > > > I think you can probably argue that even tracing doesn't hugely > > need special casing if you can get QMP started early enough that > > there's little else that can go wrong before you get a chance to > > send a QMP 'trace' command. > > > >> > >>>> The problem is that CLI and HMP, being targeted to humans (and as you > >>>> say below humans matter), are not necessarily trivial transports. If > >>>> people find the trivial transport unusable, we will not be able to > >>>> retire the old CLI. > >>> > >>> Yes, a trivial CLI transport alone may not suffice to retire the old > >>> CLI. By itself, that doesn't mean trivial transports must be avoided. > >>> > >>> Do I have to argue the benefits of a trivial configuration file > >>> transport? > >> > >> I think you do; I'm not sure that a trivial configuration file transport is > >> useful. It's a middle ground in sophistication that I'm not sure would > >> serve many people. The only source of bug reports for -readconfig has been > >> lxd, and I think we agree that they would be served better by QMP. > >> > >>> Do I have to argue the benefits of a trivial CLI transport for use by > >>> relatively unsophisticated programs / relatively sophisticated humans > >>> (such as developers)? Can we agree these benefits are not zero? > >> > >> We can. But again I think you're misunderstanding the pain that the > >> existing CLI inflicts on users. Most users do not find the ordering > >> complicated in practice; they do not even know that the issue exists. The > >> problem that users have is the 100+ character command lines, and that can > >> be > >> fixed in two ways: > >> > >> - with a trivial configuration file transport > >> > >> - with a management tool such as virt-manager or virsh. > >> > >> And I maintain that most users would be better served by the latter. In > >> fact, I constantly wonder how much we're overestimating the amount of > >> people > >> that are using QEMU. In every post (Reddit, HN, wherever) that mentions > >> QEMU being too complex and not having a front-end like VirtualBox, there's > >> always someone that mentions virt-manager. > > I totally agree with Paolo of course - thats what I was saying before. You > can call “libvirt” somebody else’s problem if you wish, but it seems to me a > more sensible route…. > > > > > An important thing to note is that while libvirt is theoretically > > general purpose for any aspect of QEMU, practically speaking our > > coverage of QEMU features is very much skewed to virtualization > > use cases. The emulation use cases don't get anywher near as much > > love & attention, especially for architectures lacking KVM, or for > > machine types not used with KVM. > > Totally agree on this (of course). > > Thats why I’m here - I care about the people who care about emulation :-) > > In general, what we are working on is exactly the ability to service the > ‘complex’ emulation use case. No CLI, nor single ‘config’ file will be good > enough, in all cases we will need to drive directly into QMP.
Can you clarify when you say 'what we are working on' here who & what are you refering to ? Something Greensocs is developing or am I mis-interpreting ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
