[Qemu-devel] loadvm and APIC

[Qemu-devel] loadvm and APIC

[malc]

Here's the scenario:

1. Start QEMU and boot Linux capable of using APIC
2. Save the VM state
3. Exit QEMU
4. Start QEMU and loadvm

Kernel instantly panics. Here's why:

Upon starting eventually following happens:
... -> pc_init -> ... -> pit_irq_timer_update
   -> qemu_set_irq -> ...
     -> apic_local_deliver -> cpu_interrupt(CPU_INTERRUPT_HARD)

Then qemu_loadvm_state begins executing load handlers eventually coming
to apic_load which loads the state from the storage overriding all the
effects of apic_local_deliver, in the meantime env->interrupt_request
stays the same.

Then cpu_exec is entered and it arrives at line 399 where
cpu_get_pic_interrupt calls apic_get_interrupt which returns -1, this
bogus interrupt number is then passed to do_interrupt and here it is
finally caught by a IDT limit check at line 649, general protection
fault is generated and kernel inside the VM panics.

Hence:

diff --git a/vl.c b/vl.c
index d759fde..11827ba 100644
--- a/vl.c
+++ b/vl.c
@@ -6296,6 +6296,7 @@ void do_loadvm(const char *name)
          goto the_end;
      }
      ret = qemu_loadvm_state(f);
+    first_cpu->interrupt_request = 0;
      qemu_fclose(f);
      if (ret < 0) {
          term_printf("Error %d while loading VM state\n", ret);

Okay to commit?

-- 
mailto:av1474@comtv.ru

[Qemu-devel] Re: loadvm and APIC

[Jan Kiszka]

malc wrote:
> Here's the scenario:
> 
> 1. Start QEMU and boot Linux capable of using APIC
> 2. Save the VM state
> 3. Exit QEMU
> 4. Start QEMU and loadvm
> 
> Kernel instantly panics. Here's why:
> 
> Upon starting eventually following happens:
> ... -> pc_init -> ... -> pit_irq_timer_update
>   -> qemu_set_irq -> ...
>     -> apic_local_deliver -> cpu_interrupt(CPU_INTERRUPT_HARD)
> 
> Then qemu_loadvm_state begins executing load handlers eventually coming
> to apic_load which loads the state from the storage overriding all the
> effects of apic_local_deliver, in the meantime env->interrupt_request
> stays the same.
> 
> Then cpu_exec is entered and it arrives at line 399 where
> cpu_get_pic_interrupt calls apic_get_interrupt which returns -1, this
> bogus interrupt number is then passed to do_interrupt and here it is
> finally caught by a IDT limit check at line 649, general protection
> fault is generated and kernel inside the VM panics.
> 
> Hence:
> 
> diff --git a/vl.c b/vl.c
> index d759fde..11827ba 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -6296,6 +6296,7 @@ void do_loadvm(const char *name)
>          goto the_end;
>      }
>      ret = qemu_loadvm_state(f);
> +    first_cpu->interrupt_request = 0;
>      qemu_fclose(f);
>      if (ret < 0) {
>          term_printf("Error %d while loading VM state\n", ret);
> 
> Okay to commit?

That is basically
http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I
would prefer.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: loadvm and APIC

[malc]

On Tue, 17 Jun 2008, Jan Kiszka wrote:

> malc wrote:
>> Here's the scenario:
>>

[..snip..]

>
> That is basically
> http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I
> would prefer.

Yes, i never paid enough attention to that patch, and it does indeed
look better.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Re: loadvm and APIC

[Fabrice Bellard]

malc wrote:
> On Tue, 17 Jun 2008, Jan Kiszka wrote:
> 
>> malc wrote:
>>> Here's the scenario:
>>>
> 
> [..snip..]
> 
>>
>> That is basically
>> http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I
>> would prefer.
> 
> Yes, i never paid enough attention to that patch, and it does indeed
> look better.

No. This is a hack which does not fix the real problem. At least saving
and restoring "interrupt_pending" would bring us closer to a better
solution.

Fabrice.

[Qemu-devel] Re: loadvm and APIC

[Jan Kiszka]

Fabrice Bellard wrote:
> malc wrote:
>> On Tue, 17 Jun 2008, Jan Kiszka wrote:
>>
>>> malc wrote:
>>>> Here's the scenario:
>>>>
>> [..snip..]
>>
>>> That is basically
>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I
>>> would prefer.
>> Yes, i never paid enough attention to that patch, and it does indeed
>> look better.
> 
> No. This is a hack which does not fix the real problem. At least saving
> and restoring "interrupt_pending" would bring us closer to a better
> solution.

No problem, patch for archs that care about cpu state saving is on the
way. I would just have appreciated receiving some indication how you'd
like to see that bug being addressed earlier.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: loadvm and APIC

[malc]

On Tue, 17 Jun 2008, Fabrice Bellard wrote:

> malc wrote:
>> On Tue, 17 Jun 2008, Jan Kiszka wrote:
>>
>>> malc wrote:
>>>> Here's the scenario:
>>>>
>>
>> [..snip..]
>>
>>>
>>> That is basically
>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I
>>> would prefer.
>>
>> Yes, i never paid enough attention to that patch, and it does indeed
>> look better.
>
> No. This is a hack which does not fix the real problem. At least saving
> and restoring "interrupt_pending" would bring us closer to a better
> solution.

Have you read my mail? It's pit/serlial vs [a]pic init/loadvm interaction
which is broken, real fix would involve fixing this and i don't see clean
way of doing that. When using plain i8259 guest doesn't panic only because
i8259 emits a spurious IRQ (and APIC does not).

-- 
mailto:av1474@comtv.ru