qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from r


From: Jan Kiszka
Subject: [Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from reset handlers
Date: Fri, 11 Sep 2009 14:28:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Glauber Costa wrote:
> On Fri, Sep 11, 2009 at 01:52:05PM +0200, Jan Kiszka wrote:
>> Glauber Costa wrote:
>>> On Fri, Sep 11, 2009 at 01:15:49PM +0200, Jan Kiszka wrote:
>>>> Anthony Liguori wrote:
>>>>> From: Glauber Costa <address@hidden>
>>>>>
>>>>> Doing this will make the vcpu ioctl be issued from the I/O thread, instead
>>>>> of cpu thread. The correct behaviour is to call it from within the cpu 
>>>>> thread,
>>>>> as soon as we are ready to go.
>>>> Note that in the good old days, this used to work properly (in qemu-kvm)
>>>> as registers write-back was routed through on_vcpu.
>>> I believe we should avoid the use of those things, specially at 
>>> initialization. They are
>>> totally racy and fragile. One way to do that, is to do all the reset 
>>> functions inside the
>>> cpu thread.
>> As all this used to work fine in practice in upstream as well as in
>> qemu-kvm, I'm slightly unhappy about the current situation.
>>
>>> I already have something hacked up for this, will send as soon as I finish 
>>> testing.
>> OK, looking forward.
>>
>> BTW, what's the state of the fix for the guest-debug regression under KVM?
> The last proposal I sent for queue_work would fix it, but it is a too big 
> job, for just a fix.
> If you are not using the IO thread, I can do what I did in there: define 
> on_vcpu to be
> conditional to the I/O thread, and in case it is not defined, just call the 
> function
> 
> What do you think?

IIUC, iothread and kvm is still broken in many ways here, so I'm fine
with a temporary workaround. Just make sure that it doesn't cause too
much merging pain downstream.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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