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

[Peter Crosthwaite <peter.crosthwaite@xilinx.com>]

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