qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH v2 0/11]


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH v2 0/11]
Date: Wed, 02 Dec 2009 13:33:11 +0100
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

Gleb Natapov wrote:
> On Wed, Dec 02, 2009 at 01:25:39PM +0100, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote:
>>>> Gleb Natapov wrote:
>>>>> On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote:
>>>>>> This is a repost of the -smp series. Note that it depends on 
>>>>>> irqchip-in-kernel,
>>>>>> that is already in staging. Also, you'll have to enable the io-thread, 
>>>>>> for the time
>>>>>> being.
>>>>>>
>>>>>> >From the last version, main change is that I am not calling queue_work 
>>>>>> >automatically
>>>>>> from vcpu ioctls. queue_work is only used currently for the gdb stub.
>>>>>>
>>>>>> All other uses were by-passed by the new qemu_register_vcpu_reset(), 
>>>>>> since most
>>>>>> of it uses (all racy) came from the reset handlers.
>>>>>>
>>>>> Looks good to me except one thing. I don't see how you are addressing
>>>>> the problem fixed by commit b8a7857071b477b28d3055e33ff0298fc91f329a
>>>>> in qemu-kvm. The problem is that mp_state can change in kernel between
>>>>> call to kvm_cpu_synchronize_state() and vcpu re-entry. In this case old
>>>>> mp_state will overwrite new one.
>>>> + nmi_pending
>>>> + sipi_vector
>>>>
>>>> These things need to be fixed at kernel level as discussed recently:
>>>> Asynchronous changes done by in-kernel subsystems need to be queued and
>>>> replayed with a higher priority than user space changes. User space need
>>>> to stop the vm if it does not want to be overruled.
>>>>
>>> Long term yes. Short term qemu need to work with existing kernels.
>> Avi's answer was different [1].
>>
>> Jan
>>
>> [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/43288
>>
> I don't think we can realistically fix all older kernels. Anyway if the
> workaround for the bug will not be done in qemu we need to fix it in kernel
> ASAP and start to propagate it to stable releases.
> 

Upstream could still easily deny in-kernel irqchip support if the host
kvm is not recent enough. qemu-kvm currently has a different policy /wrt
old kvm modules, so we may work around the mp_state and vcpu_events
issues there (just cleaner than so far).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux




reply via email to

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