Re: guest reboot error

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>>> 	It is good that I don't need to push the kernel device reset
>>>       
> patch
>   
>>> out that soon, but we still need to do so for a graceful reset
>>> especially kernel devices need to be reseted since
>>>
>>>       
>> Yes, that patch is needed.  I thought of another way to do it: have a
>>     
>
> >From HW point of view, reset is just a signal of RST pin dessert.
> So here we can use a single API indicating dessert of RST pin (i.e.
> RESET)
>
>   
>> single vm ioctl reset, which can set a reset bit in all vcpu->requests
>> and then kick the vcpus.  When the vcpus execute, they'll
>> check the bit
>> and reset the cpu and lapic then; no locking needed.
>>
>>     
>
> The tricky thing is that when kernel is involved in reset, all VPs are
> already
> reseted and no longer execute. Setting the request bit doesn;t help.
>
>   

We wake them up in addition to setting the bit.  They'll reset when they 
see it.

> So far SMP guest reboot doesn't work no matter w/ or w/o kvm-irqchip. 
> I am wondering how we handle SMP reboot in Qemu since we extended
> Qemu SMP from single thread to multiple threads. This change will bring
> big impact to reboot since previously all reset, such as APIC reset,
> happens 
> in a single (own) thread, but now the apic reset may not happen in its 
> own thread.
>   

With -no-kvm-irqchip, the thread that takes the reset takes the big qemu 
lock and resets all vcpus and all lapics.  Last I tested it worked but 
maybe there has been a regression.

> By the way, extending from single thread to multiple thread SMP is a 
> big change to Qemu, is there any progress in Qemu community?
>   

The big issue is emulating read-modify-write instructions.  Once that's 
done there's the question of whether running qemu on smp will actually 
scale.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/