Conflicting parameters on qemu call
Hi Lists, I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use. The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one. Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug? I’m running: # uname -a Linux tiger-v4 5.7.0-1-powerpc64le #1 SMP Debian 5.7.6-1 (2020-06-24) ppc64le GNU/Linux # apt-cache policy libvirt-daemon libvirt-daemon: Installed: 6.5.0-1 Candidate: 6.5.0-1 Version table: *** 6.5.0-1 500 500 http://deb.debian.org/debian testing/main ppc64el Packages # apt-cache policy qemu-system-x86 qemu-system-x86: Installed: 1:5.0-14 Candidate: 1:5.0-14 Version table: *** 1:5.0-14 500 500 http://deb.debian.org/debian testing/main ppc64el Packages Do you need any more information? Feel free to only continue on the list that matters. Greetings, Jan
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available. The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available. For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt. 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 :|
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications. So there’s not even an “I know what I’m Doing”-Switch? I have verified my use case with the manual calling of qemu with the mentioned parameters and my test suite for that use case works fine. Hence I’d like to go with libvirt for that scenario. Greetings, Jan
On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
You could use command line passthrough https://libvirt.org/drvqemu.html#qemucommand <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline> This marks the guest tainted as we consider command line passthrough unsupported, but your use of multi-threaded TCG in QEMU is already unsupported, so no worse.
I have verified my use case with the manual calling of qemu with the mentioned parameters and my test suite for that use case works fine.
It may appear to work fine today but don't be surprised if it fails at any time. The kind of problems exposed by this scenario can be very subtle and only hit if you tickle particular races. So it may work 49 times in 50, and in the other 1 case silently correct your data. 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 :|
Hi Daniel,
On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
[…] <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline>
As I wrote: This is what I’m already doing The Problem is that this conflicts with, libvirt already using the parameter: “-machine ..,accel=tcg” And I can’t get libvirt, to stop passing this parameter.
This marks the guest tainted as we consider command line passthrough unsupported, but your use of multi-threaded TCG in QEMU is already unsupported, so no worse.
exactly. I’m going in for that risk and won’t cry to libvirt if bad things happen ;(
I have verified my use case with the manual calling of qemu with the mentioned parameters and my test suite for that use case works fine.
It may appear to work fine today but don't be surprised if it fails at any time. The kind of problems exposed by this scenario can be very subtle and only hit if you tickle particular races. So it may work 49 times in 50, and in the other 1 case silently correct your data.
Yeah, as I said, I’m aware of the implications. I know what memory-barriers are and how asyncronicity and parallelism can manifest in indeterministic and hard to troubleshoot behaviours. Greetings Jan
On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote:
Hi Daniel,
On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
[…] <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline>
As I wrote: This is what I’m already doing The Problem is that this conflicts with, libvirt already using the parameter: “-machine ..,accel=tcg” And I can’t get libvirt, to stop passing this parameter.
It shouldn't matter. QEMU should aggregate the settings from the multiple args, with latter args overriding earlier args if there is any duplication.. 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 :|
On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote:
Hi Daniel,
On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote:
Hi Lists,
I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform.
It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use.
The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one.
Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
[…] <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline>
As I wrote: This is what I’m already doing The Problem is that this conflicts with, libvirt already using the parameter: “-machine ..,accel=tcg” And I can’t get libvirt, to stop passing this parameter.
It shouldn't matter. QEMU should aggregate the settings from the multiple args, with latter args overriding earlier args if there is any duplication..
That was what I thought to, but: # qemu-system-x86_64 -machine q35,accel=tcg -accel tcg,thread=multi --smp 8 -m 8 Unable to init server: Could not connect: Connection refused qemu-system-x86_64: The -accel and "-machine accel=" options are incompatible # qemu-system-x86_64 --version QEMU emulator version 5.0.0 (Debian 1:5.0-14) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers I’m already discussing that on qemu list: https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html <https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html> But I’d like to track that issue in multiple directions. Greetings, Jan
On Fri, Aug 21, 2020 at 01:38:23PM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote:
Hi Daniel,
On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: > Hi Lists, > > I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > > It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu > when starting an instance, as without that, it will only use one thread > and hence of limited/no use. > > The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to > qemu, which is a different parameter, that conflicts with the other one. > > Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug?
What you're trying todo is intentionally not available.
The memory ordering constraints needed for running x86_64 guests on ppc64 hosts cannot be satisfied, so multi-threaded TCG is not available.
For any guest/host combination where multi-thread TCG is safe to use, QEMU will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
[…] <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline>
As I wrote: This is what I’m already doing The Problem is that this conflicts with, libvirt already using the parameter: “-machine ..,accel=tcg” And I can’t get libvirt, to stop passing this parameter.
It shouldn't matter. QEMU should aggregate the settings from the multiple args, with latter args overriding earlier args if there is any duplication..
That was what I thought to, but:
# qemu-system-x86_64 -machine q35,accel=tcg -accel tcg,thread=multi --smp 8 -m 8 Unable to init server: Could not connect: Connection refused qemu-system-x86_64: The -accel and "-machine accel=" options are incompatible
# qemu-system-x86_64 --version QEMU emulator version 5.0.0 (Debian 1:5.0-14) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
I’m already discussing that on qemu list: https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html <https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html>
But I’d like to track that issue in multiple directions.
Ok, this is an intentionally backwards incompatible change in QEMU 5.0.0. So you're out of luck until libvirt changes to using "-accel" too. 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 :|
On 21. Aug 2020, at 13:55, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Fri, Aug 21, 2020 at 01:38:23PM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 11:20, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Fri, Aug 21, 2020 at 11:19:14AM +0200, Jan Walzer wrote:
Hi Daniel,
On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, Aug 21, 2020 at 11:00:27AM +0200, Jan Walzer wrote:
On 21. Aug 2020, at 10:38, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >> Hi Lists, >> >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >> >> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >> when starting an instance, as without that, it will only use one thread >> and hence of limited/no use. >> >> The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to >> qemu, which is a different parameter, that conflicts with the other one. >> >> Can we discuss, if I either have overlooked something, or is there a workaround, or is this a bug? > > What you're trying todo is intentionally not available. > > The memory ordering constraints needed for running x86_64 guests on ppc64 > hosts cannot be satisfied, so multi-threaded TCG is not available. > > For any guest/host combination where multi-thread TCG is safe to use, QEMU > will enable it automatically, so nothing is required in libvirt.
Hi Daniel, Thanks for the answer. I’ve read (and understand) the warnings and their implications.
So there’s not even an “I know what I’m Doing”-Switch?
[…] <qemu:commandline> <qemu:arg value='-accel'/> <qemu:arg value='tcg,thread=multi'/> </qemu:commandline>
As I wrote: This is what I’m already doing The Problem is that this conflicts with, libvirt already using the parameter: “-machine ..,accel=tcg” And I can’t get libvirt, to stop passing this parameter.
It shouldn't matter. QEMU should aggregate the settings from the multiple args, with latter args overriding earlier args if there is any duplication..
That was what I thought to, but:
# qemu-system-x86_64 -machine q35,accel=tcg -accel tcg,thread=multi --smp 8 -m 8 Unable to init server: Could not connect: Connection refused qemu-system-x86_64: The -accel and "-machine accel=" options are incompatible
# qemu-system-x86_64 --version QEMU emulator version 5.0.0 (Debian 1:5.0-14) Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
I’m already discussing that on qemu list: https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html <https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html><https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html <https://lists.nongnu.org/archive/html/qemu-ppc/2020-08/msg00338.html>>
But I’d like to track that issue in multiple directions.
Ok, this is an intentionally backwards incompatible change in QEMU 5.0.0. So you're out of luck until libvirt changes to using "-accel" too.
So that’s why I’m writing here on the libvirt lists - I assume this means looking for a bug report or creating one. … and for me: probably creating a really dirty workaround, by writing a wrapper, that’s called instead of the binary which adjusts the command line parameters ;( Thanks for your help, Greetings, Jan
participants (2)
-
Daniel P. Berrangé -
Jan Walzer