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

[Jan Kiszka <jan.kiszka@siemens.com>]

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

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