Conflicting parameters on qemu call

[Jan Walzer]

Hi Daniel,
> On 21. Aug 2020, at 11:07, Daniel P. Berrangé <berrange at 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 at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200821/51b21038/attachment-0001.htm>