qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 11/22] s390x: allow only 1 CPU with TCG


From: David Hildenbrand
Subject: Re: [Qemu-devel] [PATCH v5 11/22] s390x: allow only 1 CPU with TCG
Date: Fri, 15 Sep 2017 15:36:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 15.09.2017 15:17, Alex Bennée wrote:
> 
> David Hildenbrand <address@hidden> writes:
> 
>> On 13.09.2017 18:13, Alex Bennée wrote:
>>>
>>> David Hildenbrand <address@hidden> writes:
>>>
>>>> Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the
>>>> guest tries to bring these CPUs up but fails), because we don't support
>>>> multiple CPUs on s390x under TCG.
>>>>
>>>> Let's bail out if more than 1 is specified, so we don't raise people's
>>>> hope.
>>>
>>> Why does this restriction exist? Without MTTCG enabled -smp > 1 should
>>> be safe from any races.
>>
>> Because the actual SIGP code (instruction to start/stop ... CPUs) is not
>> implemented yet.
> 
> Ahh OK, I assume something like ARM's PCSI interface then.
> 
> When you do get around to implementing just ensure you use the async
> mechanism to initialise the target processor state to avoid races in
> MTTCG. Essentially you queue the work up on the target and then it is
> run before the powered up vCPU starts running code.

One step at a time, right now I only test with single threaded. MTTCG is
the next step. But I have a good feeling about mttcg, at least speaking
about the SIGP implementation (for the "critical" stuff - start, stop,
initialize - I reuse the KVM code which uses even sync work).

> 
> --
> Alex Bennée
> 


-- 

Thanks,

David



reply via email to

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