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