qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] s390x/kvm: fix run_on_cpu sigp conversions


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] s390x/kvm: fix run_on_cpu sigp conversions
Date: Mon, 7 Nov 2016 09:34:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


On 07/11/2016 08:36, Fam Zheng wrote:
> On Fri, 11/04 10:06, Paolo Bonzini wrote:
>>
>>
>> On 02/11/2016 17:21, Cornelia Huck wrote:
>>> Commit 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
>>> attempted to convert all users of run_on_cpu to use the new
>>> run_on_cpu_data type. It missed to change the called sigp_* routines,
>>> however. Fix that.
>>>
>>> Fixes: 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
>>> Signed-off-by: Cornelia Huck <address@hidden>
>>> ---
>>> Peter, Stefan: This fixes building for s390x which is currently
>>> broken (at least with kvm enabled). Two questions:
>>> - Will you pick this up as a build fix, or should I do a pull req?
>>> - Can we do anything more to catch errors like this?
>>
>> Fam, can we use the linux-user support in tests/docker to build QEMU
>> with KVM support on ARM/MIPS/s390?  It would be already much better,
>> even if it obviously cannot run with KVM.
> 
> I suppose you are asking adding coverage to patchew? (If you are asking if
> tests/docker can use linux-user to do that, the answer is yes, as long as 
> there
> is debootstrap support for that platform.)

No, not necessarily---I use tests/docker myself before sending pull
requests, and these days Peter only rejects my pull request for macOS
problems. :)

Paolo

> I think patchew can test a few foreign configurations. The problem with that
> sort of tasks is that each of them can take hours, which is probably too slow
> for patchew, before we have more testers.  But If we're to add testers, it
> probably is much easier if we can just add machines of different platforms
> (either baremetal or virtualized), and build natively.
> 
> Fam
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]