[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal: deprecate -readconfig/-writeconfig
From: |
Daniel P . Berrangé |
Subject: |
Re: proposal: deprecate -readconfig/-writeconfig |
Date: |
Thu, 14 May 2020 16:55:40 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
On Thu, May 14, 2020 at 05:51:02PM +0200, Paolo Bonzini wrote:
> On 14/05/20 17:34, Daniel P. Berrangé wrote:
> > Yeah, the key thing is that you really want to be able to provide the
> > whole initial config in one go as an atomic action. I don't want to
> > issue 100 individual QMP commands to load each initial device.
>
> Why? I think if we do something like the qemu-vm-$TARGET that you
> propose below, there's absolutely no difference between the two.
Ok, I should clarify. I don't want to do 100 individual serialized
round-trip request+reply, as that'd create latency on startup.
100 pipelined/parallelized request+reply would be ok, as you'll
not have the synchronization delay for each command.
Today the biggest cause of slow startup in libvirt, is issuing
something like 100+ serialized QMP calls to check status of
individual CPUID features. Possibly this is already just a libvirt
bug we can could just stuff all 100 qom-get queries down the pipe
in one go and have 1 wait for replies to arrive.
> Then you'd have a
>
> qemu-run /some/file.yaml
>
> (notice the lack of $TARGET) that takes care of starting the VM.
>
> > I tend to think we'd be better served by focusing on introducing a new set
> > of binaries, qemu-vm-$TARGET, which exclusively use a new config syntax,
> > free of any legacy baggage present in qemu-system-$TARGET.
> >
> > Work on qemu-vm-$TARGET will involve refactoring, and that will certainly
> > risk causing bugs in qemu-system-$TARGET. The premise though is that this
> > risk is lower, than if we tried to retrofit a new config syuntax directly
> > into qemu-system-$TARGET.
> >
> > In particular I think it is basically impossible to do any meaningful
> > changes in the main() method of softmmu/vl.c, due to the fragile ordering
> > for creation of various different devices/backends, and its interaction
> > with the argv parsing. By using a new qemu-vm-$TARGET we can have a new
> > softmmu/vm.c, instead of vl.c. We'll still likely need to modify parts of
> > vl.c to use new/changed API calls, but that's less distruptive, as we
> > can leave the crazy logic for ordering of device creation untouched.
>
> Agreed.
>
> Paolo
>
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 :|