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

Re: Conflicting parameters on qemu call



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



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