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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
