guest reboot error

guest reboot error

[Dong, Eddie]

I try to implement the guest reboot support, but I found there is an
stranger #PF VM Exit in guest real mode cs:ip=f000:10000 which is 
problemtic and current shadow won;t handle. I then try to 
use -no-kvm-irqchip and get same error. 

Can somebody give me more information if you ever successfully
run it before.
thx,eddie

-------------------------------------------------------------------------
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/

Re: guest reboot error

[Dong, Eddie]

kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> I try to implement the guest reboot support, but I found there is an
> stranger #PF VM Exit in guest real mode cs:ip=f000:10000 which is
> problemtic and current shadow won;t handle. I then try to
> use -no-kvm-irqchip and get same error.
> 
> Can somebody give me more information if you ever successfully
> run it before.
> thx,eddie
> 
correction:  It is GP fault, not #PF fault.

-------------------------------------------------------------------------
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/

Re: guest reboot error

[Avi Kivity]

Dong, Eddie wrote:
> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>   
>> I try to implement the guest reboot support, but I found there is an
>> stranger #PF VM Exit in guest real mode cs:ip=f000:10000 which is
>> problemtic and current shadow won;t handle. I then try to
>> use -no-kvm-irqchip and get same error.
>>
>> Can somebody give me more information if you ever successfully
>> run it before.
>> thx,eddie
>>
>>     
> correction:  It is GP fault, not #PF fault.
>
>   

Looks like the bios code was overwritten. If the reboot vector at
f000:fff0 was zeroed out, kvm would just execute a bunch of two-byte
instructions eventually leading to rip = 10000 which is illegal for
vm8086 mode.


Can you add code to kvmctl.c to dump the contents of that memory region
at the time of failure?


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
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/

Re: guest reboot error

[Dong, Eddie]

Avi Kivity wrote:
> Dong, Eddie wrote:
>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>> 
>>> I try to implement the guest reboot support, but I found there is an
>>> stranger #PF VM Exit in guest real mode cs:ip=f000:10000 which is
>>> problemtic and current shadow won;t handle. I then try to
>>> use -no-kvm-irqchip and get same error.
>>> 
>>> Can somebody give me more information if you ever successfully
>>> run it before.
>>> thx,eddie
>>> 
>>> 
>> correction:  It is GP fault, not #PF fault.
>> 
>> 
> 
> Looks like the bios code was overwritten. If the reboot vector at
> f000:fff0 was zeroed out, kvm would just execute a bunch of two-byte
> instructions eventually leading to rip = 10000 which is illegal for
> vm8086 mode. 
> 
> 
BTW, I downloaded KVM-36 with REHL5U 32e guest, reboot doesn't work
either.
But if I use no-kvm option, it can.
So I would like to know which release is the latest known working tree
for "reboot".

Thanks, eddie
 

-------------------------------------------------------------------------
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/

Re: guest reboot error

[Dong, Eddie]

> BTW, I downloaded KVM-36 with REHL5U 32e guest, reboot doesn't work
> either. But if I use no-kvm option, it can.
> So I would like to know which release is the latest known working
> tree for "reboot". 
> 
More update:
	Using today's master, without any patch, reboot works!!! 
	It could be explained that at reboot time, the eflag.IF is
cleared, 
so no matter how PIC/APIC beahivors at that stage, it doesn't matter. 
Later on, guest will reset those chips and then keep forwarding... 
Some other patches fixed the issue from KVM-36, or anybody has more
finding?

	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
guest OS won't reset it at begining when interrupt is enabled. So I will
push the patch eventually
but can spend more time in NIC issues that is very possible caused by
kernel apic stuff :-)

	BTW, if you know any issues that is highly suspected to kernel
irqchip series, would u
please repost them to me so that I can track clearly ? NIC issue is in
investigation now.

	Thanks, Eddie

-------------------------------------------------------------------------
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/

Re: guest reboot error

[Avi Kivity]

Dong, Eddie wrote:
>> BTW, I downloaded KVM-36 with REHL5U 32e guest, reboot doesn't work
>> either. But if I use no-kvm option, it can.
>> So I would like to know which release is the latest known working
>> tree for "reboot". 
>>
>>     
> More update:
> 	Using today's master, without any patch, reboot works!!! 
> 	It could be explained that at reboot time, the eflag.IF is
> cleared, 
> so no matter how PIC/APIC beahivors at that stage, it doesn't matter. 
> Later on, guest will reset those chips and then keep forwarding... 
> Some other patches fixed the issue from KVM-36, or anybody has more
> finding?
>
> 	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 
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.


-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
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/

Re: guest reboot error

[Dong, Eddie]

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.

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.

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

thx,eddie

-------------------------------------------------------------------------
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/

Re: guest reboot error

[Avi Kivity]

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/

Re: guest reboot error

[Avi Kivity]

Dong, Eddie wrote:
> Avi Kivity wrote:
>   
>> Dong, Eddie wrote:
>>     
>>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>>>
>>>       
>>>> I try to implement the guest reboot support, but I found there is an
>>>> stranger #PF VM Exit in guest real mode cs:ip=f000:10000 which is
>>>> problemtic and current shadow won;t handle. I then try to
>>>> use -no-kvm-irqchip and get same error.
>>>>
>>>> Can somebody give me more information if you ever successfully
>>>> run it before.
>>>> thx,eddie
>>>>
>>>>
>>>>         
>>> correction:  It is GP fault, not #PF fault.
>>>
>>>
>>>       
>> Looks like the bios code was overwritten. If the reboot vector at
>> f000:fff0 was zeroed out, kvm would just execute a bunch of two-byte
>> instructions eventually leading to rip = 10000 which is illegal for
>> vm8086 mode. 
>>
>>
>>     
> BTW, I downloaded KVM-36 with REHL5U 32e guest, reboot doesn't work
> either.
> But if I use no-kvm option, it can.
> So I would like to know which release is the latest known working tree
> for "reboot".
>
>   

Reboot behaves differently for different guests... we have a regression 
for Windows XP ACPI HAL (I'm quite sure kvm-36 used to work), but maybe 
not for RHEL 5 i386.


-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
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/