qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks


From: Phil Dennis-Jordan
Subject: Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Fri, 21 Jul 2017 13:46:44 +0200

On Fri, Jul 21, 2017 at 12:50 PM, BALATON Zoltan <address@hidden> wrote:
> On Fri, 21 Jul 2017, Igor Mammedov wrote:
>>
>> On Fri, 21 Jul 2017 10:20:26 +0100
>> "Daniel P. Berrange" <address@hidden> wrote:
>>>
>>> On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
>>>>
>>>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>>>> <address@hidden> wrote:
>>>>>
>>>>> I noticed that Windows 2000 does not boot up in QEMU recently. After
>>>>> bisecting the issue I found the offending commit:
>>>>
>>>>
>>>> Ouch. I reckon we have 2 options for fixing this:
>>>>
>>>> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>>>> to be pointed to by an XSDT, which Qemu currently doesn't implement at
>>>> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>>>> this? Any likely other OS regressions?
>>>>
>>>> 2. Select FADT version with an option. This one is definitely safe,
>>>> but adds yet another option.
>>>>
>>>> Thoughts?
>>>
>>>
>>> The original comit below claims the change does not impact guest ABI
>>> compatibility, so do we understand why Windows broke ?
>>
>> Author made a reasonable effort to test with variety of guest OSes upto
>> vanilla WinXP, we can't blame ourselves for not testing OS that's is not
>> available.
>>
>> Well we don't know why w2k breaks, only that it bisects to this commit.
>
>
> I don't know if this helps but I've found that this same commit also broke
> booting OS X on q35 with OVMF and Clover (some old versions I had and worked
> before this commit). See here:
> http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04306.html
>
> Maybe it's simpler to debug as these are open source but it's still not very
> clear why they fail because it starts to boot OS X but hangs during kernel
> init (and maybe Win2K fails to boot because of something else). I think I've
> seen this with OVMF 58f025afd and Clover 3354 (or around that, not
> completely sure about these versions).

OVMF had 2 bugs that totally mucked up the ACPI tables if Qemu didn't
supply its loader commands "just so", and modified ACPI 2.0-5.0 FADTs
in such a way that they were no longer valid. These are fixed in
198a46d and 072060a, which are about a year newer than 58f025afd, so
it's no surprise this combination doesn't work. I have no idea if
Clover on top makes any difference.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]