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

[Paolo Bonzini <pbonzini@redhat.com>]

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