[Qemu-devel] Bug report - Windows XP guest failure

[Qemu-devel] Bug report - Windows XP guest failure

[Programmingkid]

Just wanted to note that for the i386 target, Windows XP as a guest fails to boot. When it safe mode, loading always stops at  Windows\System32\Drivers\Mup.sys. The guest boots in QEMU 2.2.0, so this seems to indicate a bug with the May 5th or earlier patch set. 

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Michael Tokarev]

06.05.2015 08:41, Programmingkid wrote
> Just wanted to note that for the i386 target, Windows XP as a guest fails to boot. When it safe mode, loading always stops at  Windows\System32\Drivers\Mup.sys. The guest boots in QEMU 2.2.0, so this seems to indicate a bug with the May 5th or earlier patch set. 

Please be a bit more specific, what do you run,
with which options etc.  Current git master works
just fine with winXP guest, be it i386 or x86_64.

Thanks,

/mjt

Re: [Qemu-devel] Bug report - Windows XP guest failure

[G 3]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Did you boot Windows XP to the desktop? I have tested Windows 95, Windows
2000, and Windows XP. All of them fail to boot to the desktop.

Command used:
./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img"

On Wed, May 6, 2015 at 2:44 PM, Programmingkid <programmingkidx@gmail.com>
wrote:

>
> On May 6, 2015, at 3:35 AM, Michael Tokarev wrote:
>
> 06.05.2015 08:41, Programmingkid wrote
>
> Just wanted to note that for the i386 target, Windows XP as a guest fails
> to boot. When it safe mode, loading always stops at
>  Windows\System32\Drivers\Mup.sys. The guest boots in QEMU 2.2.0, so this
> seems to indicate a bug with the May 5th or earlier patch set.
>
>
> Please be a bit more specific, what do you run,
> with which options etc.  Current git master works
> just fine with winXP guest, be it i386 or x86_64.
>
>
> Really? Maybe it is because of my Mac OS 10.6 host.
>

[-- Attachment #2: Type: text/html, Size: 1533 bytes --]

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Michael Tokarev]

07.05.2015 04:11, G 3 wrote:
> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.

Yes, booted to desktop and did some minimal work in there,
installnig one update or two.

> Command used:
> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img" 

Aha. You run without kvm, in tcg mode.  I don't usually do that,
lemme try...

P.S. Please don't top-post.

/mjt

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Michael Tokarev]

07.05.2015 09:12, Michael Tokarev wrote:
> 07.05.2015 04:11, G 3 wrote:
>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
> 
> Yes, booted to desktop and did some minimal work in there,
> installnig one update or two.
> 
>> Command used:
>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img" 
> 
> Aha. You run without kvm, in tcg mode.  I don't usually do that,
> lemme try...

Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
Git bisect points to this:

commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Date:   Mon Mar 16 22:35:54 2015 -0700

    exec: Respect as_translate_internal length clamp

    address_space_translate_internal will clamp the *plen length argument
    based on the size of the memory region being queried. The iommu walker
    logic in addresss_space_translate was ignoring this by discarding the
    post fn call value of *plen. Fix by just always using *plen as the
    length argument throughout the fn, removing the len local variable.

    This fixes a bootloader bug when a single elf section spans multiple
    QEMU memory regions.

    Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
    Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Cc'ing relevant people.

/mjt

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Michael Tokarev]

07.05.2015 09:47, Michael Tokarev wrote:
> 07.05.2015 09:12, Michael Tokarev wrote:
>> 07.05.2015 04:11, G 3 wrote:
>>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
>>
>> Yes, booted to desktop and did some minimal work in there,
>> installnig one update or two.
>>
>>> Command used:
>>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img" 
>>
>> Aha. You run without kvm, in tcg mode.  I don't usually do that,
>> lemme try...
> 
> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
> Git bisect points to this:
> 
> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date:   Mon Mar 16 22:35:54 2015 -0700
> 
>     exec: Respect as_translate_internal length clamp
> 
>     address_space_translate_internal will clamp the *plen length argument
>     based on the size of the memory region being queried. The iommu walker
>     logic in addresss_space_translate was ignoring this by discarding the
>     post fn call value of *plen. Fix by just always using *plen as the
>     length argument throughout the fn, removing the len local variable.
> 
>     This fixes a bootloader bug when a single elf section spans multiple
>     QEMU memory regions.
> 
>     Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>     Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

This winXP BSOD happens on x86_64 target too.  Reverting the
above commit from git master fixes the BSOD.

Thanks,

/mjt

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Programmingkid]

On May 7, 2015, at 2:47 AM, Michael Tokarev wrote:

> 07.05.2015 09:12, Michael Tokarev wrote:
>> 07.05.2015 04:11, G 3 wrote:
>>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
>> 
>> Yes, booted to desktop and did some minimal work in there,
>> installnig one update or two.
>> 
>>> Command used:
>>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img" 
>> 
>> Aha. You run without kvm, in tcg mode.  I don't usually do that,
>> lemme try...
> 
> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
> Git bisect points to this:
> 
> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Date:   Mon Mar 16 22:35:54 2015 -0700
> 
>    exec: Respect as_translate_internal length clamp
> 
>    address_space_translate_internal will clamp the *plen length argument
>    based on the size of the memory region being queried. The iommu walker
>    logic in addresss_space_translate was ignoring this by discarding the
>    post fn call value of *plen. Fix by just always using *plen as the
>    length argument throughout the fn, removing the len local variable.
> 
>    This fixes a bootloader bug when a single elf section spans multiple
>    QEMU memory regions.
> 
>    Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>    Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Cc'ing relevant people.
> 
> /mjt

Thank you very much for solving this issue.

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Programmingkid]

On May 7, 2015, at 5:34 AM, Michael Tokarev wrote:

> 07.05.2015 09:47, Michael Tokarev wrote:
>> 07.05.2015 09:12, Michael Tokarev wrote:
>>> 07.05.2015 04:11, G 3 wrote:
>>>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
>>> 
>>> Yes, booted to desktop and did some minimal work in there,
>>> installnig one update or two.
>>> 
>>>> Command used:
>>>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img" 
>>> 
>>> Aha. You run without kvm, in tcg mode.  I don't usually do that,
>>> lemme try...
>> 
>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>> Git bisect points to this:
>> 
>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>> Date:   Mon Mar 16 22:35:54 2015 -0700
>> 
>>    exec: Respect as_translate_internal length clamp
>> 
>>    address_space_translate_internal will clamp the *plen length argument
>>    based on the size of the memory region being queried. The iommu walker
>>    logic in addresss_space_translate was ignoring this by discarding the
>>    post fn call value of *plen. Fix by just always using *plen as the
>>    length argument throughout the fn, removing the len local variable.
>> 
>>    This fixes a bootloader bug when a single elf section spans multiple
>>    QEMU memory regions.
>> 
>>    Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>    Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
>>    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> This winXP BSOD happens on x86_64 target too.  Reverting the
> above commit from git master fixes the BSOD.
> 
> Thanks,
> 
> /mjt
> 

After reverting this patch, I was able to boot Windows XP again. Good work finding this patch.

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Peter Crosthwaite]

On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 07.05.2015 09:47, Michael Tokarev wrote:
>> 07.05.2015 09:12, Michael Tokarev wrote:
>>> 07.05.2015 04:11, G 3 wrote:
>>>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
>>>
>>> Yes, booted to desktop and did some minimal work in there,
>>> installnig one update or two.
>>>
>>>> Command used:
>>>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img"
>>>
>>> Aha. You run without kvm, in tcg mode.  I don't usually do that,
>>> lemme try...
>>
>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>> Git bisect points to this:
>>
>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>
>>     exec: Respect as_translate_internal length clamp
>>
>>     address_space_translate_internal will clamp the *plen length argument
>>     based on the size of the memory region being queried. The iommu walker
>>     logic in addresss_space_translate was ignoring this by discarding the
>>     post fn call value of *plen. Fix by just always using *plen as the
>>     length argument throughout the fn, removing the len local variable.
>>
>>     This fixes a bootloader bug when a single elf section spans multiple
>>     QEMU memory regions.
>>
>>     Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>     Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
>>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>
> This winXP BSOD happens on x86_64 target too.  Reverting the
> above commit from git master fixes the BSOD.
>

Any useful info about IO addresses on that BSOD? The last issue with
this patch was IOPort code relying on the bug that this patch fixed.
This could be similar and if we can track the failure to a particular
address we can fix properly rather than another revert of that patch.

Regards,
Peter

> Thanks,
>
> /mjt
>
>

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Paolo Bonzini]

On 12/05/2015 03:05, Peter Crosthwaite wrote:
> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>> 07.05.2015 09:47, Michael Tokarev wrote:
>>> 07.05.2015 09:12, Michael Tokarev wrote:
>>>> 07.05.2015 04:11, G 3 wrote:
>>>>> Did you boot Windows XP to the desktop? I have tested Windows 95, Windows 2000, and Windows XP. All of them fail to boot to the desktop.
>>>>
>>>> Yes, booted to desktop and did some minimal work in there,
>>>> installnig one update or two.
>>>>
>>>>> Command used:
>>>>> ./i386-softmmu/qemu-system-i386 -boot c -hda "Windows XP Hard Drive.img"
>>>>
>>>> Aha. You run without kvm, in tcg mode.  I don't usually do that,
>>>> lemme try...
>>>
>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>> Git bisect points to this:
>>>
>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>
>>>     exec: Respect as_translate_internal length clamp
>>>
>>>     address_space_translate_internal will clamp the *plen length argument
>>>     based on the size of the memory region being queried. The iommu walker
>>>     logic in addresss_space_translate was ignoring this by discarding the
>>>     post fn call value of *plen. Fix by just always using *plen as the
>>>     length argument throughout the fn, removing the len local variable.
>>>
>>>     This fixes a bootloader bug when a single elf section spans multiple
>>>     QEMU memory regions.
>>>
>>>     Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>     Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
>>>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>
>> This winXP BSOD happens on x86_64 target too.  Reverting the
>> above commit from git master fixes the BSOD.
>>
> 
> Any useful info about IO addresses on that BSOD? The last issue with
> this patch was IOPort code relying on the bug that this patch fixed.
> This could be similar and if we can track the failure to a particular
> address we can fix properly rather than another revert of that patch.

Yes, it's on my todo list.

Paolo

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Michael Tokarev]

12.05.2015 04:05, Peter Crosthwaite wrote:
> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
...
>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>> Git bisect points to this:
>>>
>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>
>>>     exec: Respect as_translate_internal length clamp
>>
>> This winXP BSOD happens on x86_64 target too.  Reverting the
>> above commit from git master fixes the BSOD.
> 
> Any useful info about IO addresses on that BSOD? The last issue with
> this patch was IOPort code relying on the bug that this patch fixed.
> This could be similar and if we can track the failure to a particular
> address we can fix properly rather than another revert of that patch.

Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
I see.

  IRQ_NOT_LESS_OR_EQUAL
  STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)

(with some amount of leading zeros stripped).

When this happens, win does something for quite some time, the BSOD comes
after quite significant delay.

Is there anything else I can look at, maybe some crash dump or something?
I haven't done any windows debugging before.

Thanks,

/mjt

Re: [Qemu-devel] Bug report - Windows XP guest failure

[John Snow]

On 05/12/2015 03:22 AM, Michael Tokarev wrote:
> 12.05.2015 04:05, Peter Crosthwaite wrote:
>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> ...
>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>> Git bisect points to this:
>>>>
>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>
>>>>     exec: Respect as_translate_internal length clamp
>>>
>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>> above commit from git master fixes the BSOD.
>>
>> Any useful info about IO addresses on that BSOD? The last issue with
>> this patch was IOPort code relying on the bug that this patch fixed.
>> This could be similar and if we can track the failure to a particular
>> address we can fix properly rather than another revert of that patch.
> 
> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
> I see.
> 
>   IRQ_NOT_LESS_OR_EQUAL
>   STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
> 
> (with some amount of leading zeros stripped).
> 
> When this happens, win does something for quite some time, the BSOD comes
> after quite significant delay.
> 
> Is there anything else I can look at, maybe some crash dump or something?
> I haven't done any windows debugging before.
> 
> Thanks,
> 
> /mjt
> 

https://support.microsoft.com/en-us/kb/315263

You can configure the type of dump it saves, then use various MS
utilities described here (briefly) to perform some basic analysis on the
dumps, which sometimes gives extra goodies.

I haven't done too much advanced windows debugging myself, but I do
generally try to run the !analyze command on any minidumps I create, at
least.

--js

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Paolo Bonzini]

On 12/05/2015 09:22, Michael Tokarev wrote:
> 12.05.2015 04:05, Peter Crosthwaite wrote:
>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> ...
>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>> Git bisect points to this:
>>>>
>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>
>>>>     exec: Respect as_translate_internal length clamp
>>>
>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>> above commit from git master fixes the BSOD.
>>
>> Any useful info about IO addresses on that BSOD? The last issue with
>> this patch was IOPort code relying on the bug that this patch fixed.
>> This could be similar and if we can track the failure to a particular
>> address we can fix properly rather than another revert of that patch.
> 
> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
> I see.
> 
>   IRQ_NOT_LESS_OR_EQUAL
>   STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
> 
> (with some amount of leading zeros stripped).
> 
> When this happens, win does something for quite some time, the BSOD comes
> after quite significant delay.
> 
> Is there anything else I can look at, maybe some crash dump or something?
> I haven't done any windows debugging before.

I would just put a breakpoint on the new condition introduced by the
commit, and see what causes the breakage.

Paolo

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Mark Cave-Ayland]

On 13/05/15 10:01, Paolo Bonzini wrote:

> On 12/05/2015 09:22, Michael Tokarev wrote:
>> 12.05.2015 04:05, Peter Crosthwaite wrote:
>>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>> ...
>>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>>> Git bisect points to this:
>>>>>
>>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>>
>>>>>     exec: Respect as_translate_internal length clamp
>>>>
>>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>>> above commit from git master fixes the BSOD.
>>>
>>> Any useful info about IO addresses on that BSOD? The last issue with
>>> this patch was IOPort code relying on the bug that this patch fixed.
>>> This could be similar and if we can track the failure to a particular
>>> address we can fix properly rather than another revert of that patch.
>>
>> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
>> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
>> I see.
>>
>>   IRQ_NOT_LESS_OR_EQUAL
>>   STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
>>
>> (with some amount of leading zeros stripped).
>>
>> When this happens, win does something for quite some time, the BSOD comes
>> after quite significant delay.
>>
>> Is there anything else I can look at, maybe some crash dump or something?
>> I haven't done any windows debugging before.
> 
> I would just put a breakpoint on the new condition introduced by the
> commit, and see what causes the breakage.

I tried this approach and came up with the following backtrace:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff1bfc700 (LWP 30219)]
0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5cd04e8 in __GI_abort () at abort.c:89
#2  0x00007ffff5cc8226 in __assert_fail_base (fmt=0x7ffff5dfece8
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7993e2 "xplen == *plen",
    file=file@entry=0x799370 "/home/build/src/qemu/git/qemu/exec.c",
line=line@entry=362, function=function@entry=0x799be0
<__PRETTY_FUNCTION__.34759> "address_space_translate_internal") at
assert.c:92
#3  0x00007ffff5cc82d2 in __GI___assert_fail (assertion=0x7993e2 "xplen
== *plen", file=0x799370 "/home/build/src/qemu/git/qemu/exec.c", line=362,
    function=0x799be0 <__PRETTY_FUNCTION__.34759>
"address_space_translate_internal") at assert.c:101
#4  0x000000000040b54b in address_space_translate_internal
(d=0x7fffdc127150, addr=0, xlat=0x7ffff1bfb470, plen=0x7ffff1bfb530,
resolve_subpage=true) at /home/build/src/qemu/git/qemu/exec.c:362
#5  0x000000000040b643 in address_space_translate (as=0xc1b8c0
<address_space_io>, addr=0, xlat=0x7ffff1bfb540, plen=0x7ffff1bfb530,
is_write=true) at /home/build/src/qemu/git/qemu/exec.c:390
#6  0x000000000040fa54 in address_space_rw (as=0xc1b8c0
<address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
len=4, is_write=true) at /home/build/src/qemu/git/qemu/exec.c:2339
#7  0x000000000040fe19 in address_space_write (as=0xc1b8c0
<address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
len=4) at /home/build/src/qemu/git/qemu/exec.c:2431
#8  0x000000000044ef97 in cpu_outl (addr=126, val=1) at
/home/build/src/qemu/git/qemu/ioport.c:89
#9  0x0000000000517104 in helper_outl (port=126, data=1) at
/home/build/src/qemu/git/qemu/target-i386/misc_helper.c:47
#10 0x0000000040557d03 in code_gen_buffer ()
#11 0x0000000000414916 in cpu_tb_exec (cpu=0x111cc30, tb_ptr=0x40557ce0
<code_gen_buffer+5602528> "A\213n\374\205\355\017\205\067") at
/home/build/src/qemu/git/qemu/cpu-exec.c:199
#12 0x0000000000415351 in cpu_x86_exec (env=0x1124e80) at
/home/build/src/qemu/git/qemu/cpu-exec.c:519
#13 0x00000000004404e4 in tcg_cpu_exec (env=0x1124e80) at
/home/build/src/qemu/git/qemu/cpus.c:1354
#14 0x00000000004405cb in tcg_exec_all () at
/home/build/src/qemu/git/qemu/cpus.c:1387
#15 0x000000000043fb7c in qemu_tcg_cpu_thread_fn (arg=0x111cc30) at
/home/build/src/qemu/git/qemu/cpus.c:1032
#16 0x00007ffff604b0a4 in start_thread (arg=0x7ffff1bfc700) at
pthread_create.c:309
#17 0x00007ffff5d8004d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) p/x 126
$1 = 0x7e

It looks like we're trying to do a 32-bit write to the kvmvapic device
which appears as below in "info mtree":

address-space: I/O
  0000000000000000-000000000000ffff (prio 0, RW): io
    0000000000000000-0000000000000007 (prio 0, RW): dma-chan
    0000000000000008-000000000000000f (prio 0, RW): dma-cont
    0000000000000020-0000000000000021 (prio 0, RW): pic
    0000000000000040-0000000000000043 (prio 0, RW): pit
    0000000000000060-0000000000000060 (prio 0, RW): i8042-data
    0000000000000061-0000000000000061 (prio 0, RW): pcspk
    0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd
    0000000000000070-0000000000000071 (prio 0, RW): rtc
    000000000000007e-000000000000007f (prio 0, RW): kvmvapic
    0000000000000080-0000000000000080 (prio 0, RW): ioport80

According to the comments in kvmvapic.c's vapic_write(), a 32-bit write
is used to poll for pending IRQs. However with the address clamping
enabled, these writes never make it to the kvmvapic which is what causes
the breakage in WinXP.


ATB,

Mark.

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Programmingkid]

On Jun 14, 2015, at 5:55 AM, Mark Cave-Ayland wrote:

> On 13/05/15 10:01, Paolo Bonzini wrote:
> 
>> On 12/05/2015 09:22, Michael Tokarev wrote:
>>> 12.05.2015 04:05, Peter Crosthwaite wrote:
>>>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>> ...
>>>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>>>> Git bisect points to this:
>>>>>> 
>>>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>>> 
>>>>>>    exec: Respect as_translate_internal length clamp
>>>>> 
>>>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>>>> above commit from git master fixes the BSOD.
>>>> 
>>>> Any useful info about IO addresses on that BSOD? The last issue with
>>>> this patch was IOPort code relying on the bug that this patch fixed.
>>>> This could be similar and if we can track the failure to a particular
>>>> address we can fix properly rather than another revert of that patch.
>>> 
>>> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
>>> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
>>> I see.
>>> 
>>>  IRQ_NOT_LESS_OR_EQUAL
>>>  STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
>>> 
>>> (with some amount of leading zeros stripped).
>>> 
>>> When this happens, win does something for quite some time, the BSOD comes
>>> after quite significant delay.
>>> 
>>> Is there anything else I can look at, maybe some crash dump or something?
>>> I haven't done any windows debugging before.
>> 
>> I would just put a breakpoint on the new condition introduced by the
>> commit, and see what causes the breakage.
> 
> I tried this approach and came up with the following backtrace:
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7ffff1bfc700 (LWP 30219)]
> 0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff5cd04e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff5cc8226 in __assert_fail_base (fmt=0x7ffff5dfece8
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7993e2 "xplen == *plen",
>    file=file@entry=0x799370 "/home/build/src/qemu/git/qemu/exec.c",
> line=line@entry=362, function=function@entry=0x799be0
> <__PRETTY_FUNCTION__.34759> "address_space_translate_internal") at
> assert.c:92
> #3  0x00007ffff5cc82d2 in __GI___assert_fail (assertion=0x7993e2 "xplen
> == *plen", file=0x799370 "/home/build/src/qemu/git/qemu/exec.c", line=362,
>    function=0x799be0 <__PRETTY_FUNCTION__.34759>
> "address_space_translate_internal") at assert.c:101
> #4  0x000000000040b54b in address_space_translate_internal
> (d=0x7fffdc127150, addr=0, xlat=0x7ffff1bfb470, plen=0x7ffff1bfb530,
> resolve_subpage=true) at /home/build/src/qemu/git/qemu/exec.c:362
> #5  0x000000000040b643 in address_space_translate (as=0xc1b8c0
> <address_space_io>, addr=0, xlat=0x7ffff1bfb540, plen=0x7ffff1bfb530,
> is_write=true) at /home/build/src/qemu/git/qemu/exec.c:390
> #6  0x000000000040fa54 in address_space_rw (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4, is_write=true) at /home/build/src/qemu/git/qemu/exec.c:2339
> #7  0x000000000040fe19 in address_space_write (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4) at /home/build/src/qemu/git/qemu/exec.c:2431
> #8  0x000000000044ef97 in cpu_outl (addr=126, val=1) at
> /home/build/src/qemu/git/qemu/ioport.c:89
> #9  0x0000000000517104 in helper_outl (port=126, data=1) at
> /home/build/src/qemu/git/qemu/target-i386/misc_helper.c:47
> #10 0x0000000040557d03 in code_gen_buffer ()
> #11 0x0000000000414916 in cpu_tb_exec (cpu=0x111cc30, tb_ptr=0x40557ce0
> <code_gen_buffer+5602528> "A\213n\374\205\355\017\205\067") at
> /home/build/src/qemu/git/qemu/cpu-exec.c:199
> #12 0x0000000000415351 in cpu_x86_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpu-exec.c:519
> #13 0x00000000004404e4 in tcg_cpu_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpus.c:1354
> #14 0x00000000004405cb in tcg_exec_all () at
> /home/build/src/qemu/git/qemu/cpus.c:1387
> #15 0x000000000043fb7c in qemu_tcg_cpu_thread_fn (arg=0x111cc30) at
> /home/build/src/qemu/git/qemu/cpus.c:1032
> #16 0x00007ffff604b0a4 in start_thread (arg=0x7ffff1bfc700) at
> pthread_create.c:309
> #17 0x00007ffff5d8004d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p/x 126
> $1 = 0x7e
> 
> It looks like we're trying to do a 32-bit write to the kvmvapic device
> which appears as below in "info mtree":
> 
> address-space: I/O
>  0000000000000000-000000000000ffff (prio 0, RW): io
>    0000000000000000-0000000000000007 (prio 0, RW): dma-chan
>    0000000000000008-000000000000000f (prio 0, RW): dma-cont
>    0000000000000020-0000000000000021 (prio 0, RW): pic
>    0000000000000040-0000000000000043 (prio 0, RW): pit
>    0000000000000060-0000000000000060 (prio 0, RW): i8042-data
>    0000000000000061-0000000000000061 (prio 0, RW): pcspk
>    0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd
>    0000000000000070-0000000000000071 (prio 0, RW): rtc
>    000000000000007e-000000000000007f (prio 0, RW): kvmvapic
>    0000000000000080-0000000000000080 (prio 0, RW): ioport80
> 
> According to the comments in kvmvapic.c's vapic_write(), a 32-bit write
> is used to poll for pending IRQs. However with the address clamping
> enabled, these writes never make it to the kvmvapic which is what causes
> the breakage in WinXP.
> 
> 
> ATB,
> 
> Mark.

Good job figuring this out. 

Re: [Qemu-devel] Bug report - Windows XP guest failure

[Paolo Bonzini]

On 14/06/2015 11:55, Mark Cave-Ayland wrote:
> On 13/05/15 10:01, Paolo Bonzini wrote:
> 
>> On 12/05/2015 09:22, Michael Tokarev wrote:
>>> 12.05.2015 04:05, Peter Crosthwaite wrote:
>>>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>> ...
>>>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>>>> Git bisect points to this:
>>>>>>
>>>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>>>> Author: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>>>
>>>>>>     exec: Respect as_translate_internal length clamp
>>>>>
>>>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>>>> above commit from git master fixes the BSOD.
>>>>
>>>> Any useful info about IO addresses on that BSOD? The last issue with
>>>> this patch was IOPort code relying on the bug that this patch fixed.
>>>> This could be similar and if we can track the failure to a particular
>>>> address we can fix properly rather than another revert of that patch.
>>>
>>> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
>>> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
>>> I see.
>>>
>>>   IRQ_NOT_LESS_OR_EQUAL
>>>   STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
>>>
>>> (with some amount of leading zeros stripped).
>>>
>>> When this happens, win does something for quite some time, the BSOD comes
>>> after quite significant delay.
>>>
>>> Is there anything else I can look at, maybe some crash dump or something?
>>> I haven't done any windows debugging before.
>>
>> I would just put a breakpoint on the new condition introduced by the
>> commit, and see what causes the breakage.
> 
> I tried this approach and came up with the following backtrace:
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7ffff1bfc700 (LWP 30219)]
> 0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff5ccf107 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff5cd04e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff5cc8226 in __assert_fail_base (fmt=0x7ffff5dfece8
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7993e2 "xplen == *plen",
>     file=file@entry=0x799370 "/home/build/src/qemu/git/qemu/exec.c",
> line=line@entry=362, function=function@entry=0x799be0
> <__PRETTY_FUNCTION__.34759> "address_space_translate_internal") at
> assert.c:92
> #3  0x00007ffff5cc82d2 in __GI___assert_fail (assertion=0x7993e2 "xplen
> == *plen", file=0x799370 "/home/build/src/qemu/git/qemu/exec.c", line=362,
>     function=0x799be0 <__PRETTY_FUNCTION__.34759>
> "address_space_translate_internal") at assert.c:101
> #4  0x000000000040b54b in address_space_translate_internal
> (d=0x7fffdc127150, addr=0, xlat=0x7ffff1bfb470, plen=0x7ffff1bfb530,
> resolve_subpage=true) at /home/build/src/qemu/git/qemu/exec.c:362
> #5  0x000000000040b643 in address_space_translate (as=0xc1b8c0
> <address_space_io>, addr=0, xlat=0x7ffff1bfb540, plen=0x7ffff1bfb530,
> is_write=true) at /home/build/src/qemu/git/qemu/exec.c:390
> #6  0x000000000040fa54 in address_space_rw (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4, is_write=true) at /home/build/src/qemu/git/qemu/exec.c:2339
> #7  0x000000000040fe19 in address_space_write (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4) at /home/build/src/qemu/git/qemu/exec.c:2431
> #8  0x000000000044ef97 in cpu_outl (addr=126, val=1) at
> /home/build/src/qemu/git/qemu/ioport.c:89
> #9  0x0000000000517104 in helper_outl (port=126, data=1) at
> /home/build/src/qemu/git/qemu/target-i386/misc_helper.c:47
> #10 0x0000000040557d03 in code_gen_buffer ()
> #11 0x0000000000414916 in cpu_tb_exec (cpu=0x111cc30, tb_ptr=0x40557ce0
> <code_gen_buffer+5602528> "A\213n\374\205\355\017\205\067") at
> /home/build/src/qemu/git/qemu/cpu-exec.c:199
> #12 0x0000000000415351 in cpu_x86_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpu-exec.c:519
> #13 0x00000000004404e4 in tcg_cpu_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpus.c:1354
> #14 0x00000000004405cb in tcg_exec_all () at
> /home/build/src/qemu/git/qemu/cpus.c:1387
> #15 0x000000000043fb7c in qemu_tcg_cpu_thread_fn (arg=0x111cc30) at
> /home/build/src/qemu/git/qemu/cpus.c:1032
> #16 0x00007ffff604b0a4 in start_thread (arg=0x7ffff1bfc700) at
> pthread_create.c:309
> #17 0x00007ffff5d8004d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p/x 126
> $1 = 0x7e
> 
> It looks like we're trying to do a 32-bit write to the kvmvapic device
> which appears as below in "info mtree":
> 
> address-space: I/O
>   0000000000000000-000000000000ffff (prio 0, RW): io
>     0000000000000000-0000000000000007 (prio 0, RW): dma-chan
>     0000000000000008-000000000000000f (prio 0, RW): dma-cont
>     0000000000000020-0000000000000021 (prio 0, RW): pic
>     0000000000000040-0000000000000043 (prio 0, RW): pit
>     0000000000000060-0000000000000060 (prio 0, RW): i8042-data
>     0000000000000061-0000000000000061 (prio 0, RW): pcspk
>     0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd
>     0000000000000070-0000000000000071 (prio 0, RW): rtc
>     000000000000007e-000000000000007f (prio 0, RW): kvmvapic
>     0000000000000080-0000000000000080 (prio 0, RW): ioport80
> 
> According to the comments in kvmvapic.c's vapic_write(), a 32-bit write
> is used to poll for pending IRQs. However with the address clamping
> enabled, these writes never make it to the kvmvapic which is what causes
> the breakage in WinXP.

Thanks Mark.  At the very least kvmvapic.c should set .impl.unaligned to
true (like ioport.c does), but also the clamping should be disabled
based on .impl.unaligned.  I'll test this and report back.

Thanks,

Paolo