qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Cc: Denis Lunev <den@virtuozzo.com>,
	rkagan@virtuozzo.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] acpi: change CPU container node _HID to compatible PNP0A05
Date: Tue, 23 May 2017 10:53:35 +0300	[thread overview]
Message-ID: <d063eb22-cd22-80e7-d9f9-46b0fed61f28@virtuozzo.com> (raw)
In-Reply-To: <20170522204309-mutt-send-email-mst@kernel.org>



On 22.05.2017 20:44, Michael S. Tsirkin wrote:
> On Mon, May 22, 2017 at 02:58:56PM +0200, Igor Mammedov wrote:
>> On Mon, 22 May 2017 14:01:15 +0300
>> Evgeny Yakovlev <eyakovlev@virtuozzo.com> wrote:
>>
>>> On 22.05.2017 13:35, Igor Mammedov wrote:
>>>> On Mon, 22 May 2017 12:50:30 +0300
>>>> Evgeny Yakovlev <eyakovlev@virtuozzo.com> wrote:
>>>>   
>>>>> When running windows 2016 server guests we have encountered a problem
>>>>> with ACPI representation of CPU devices. This windows version contains a
>>>>> hidinterrupt.sys driver which looks for ACPI device node with _HID set
>>>>> to "ACPI0010" and "ACPI0011". ACPI0010 is also a valid id for CPU
>>>>> container device which qemu uses.
>>>>>
>>>>> hidinterrupt driver takes over (even though it fails) ACPI0010 node and
>>>>> thus hides its children -- the CPUs -- from the regular ACPI
>>>>> enumeration.  So there are no processors in the Windows device tree
>>>>> Device Manager or "!devnode 0 1" in the debugger.
>>>>>
>>>>> hidinterrupt.inf as shipped with Windows 2016 has both ACPI0011 and
>>>>> ACPI0010; the record for the latter is preceded with a comment "This Id
>>>>> is not to be used. It will be removed once everyone has stopped using
>>>>> it."  So I guess the typo was not in the driver but in the ACPI tables
>>>>> of some device(s) which the driver wanted to support despite the bug.
>>>>>
>>>>> For reference this is a known issue:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1377155#c31
>>>>>
>>>>> This change works around this problem by setting qemu CPU container ACPI
>>>>> _HID to compatible PNP0A05.
>>>> I'd say NACK to it.
>>>> It's Windows server 2016 bug that violates spec and
>>>> it's been reported to them before RTM has been released.
>>>> So complain to Microsoft support and make them fix it.
>>>>
>>>> Meanwhile there is MS suggested workaround to fix issue,
>>>> one can use https://bugzilla.redhat.com/show_bug.cgi?id=1377155#c17
>>>>
>>>> Perhaps I should add workaround link as comment above line:
>>>>
>>>> aml_append(cpus_dev, aml_name_decl("_HID", aml_string("ACPI0010")));
>>> Thanks for replying!
>>>
>>> Strictly speaking, this is not a Windows bug. Comment in INF file says
>>> that they had to support a hardware device which erroneously picked this
>>> ACPI HID.
>> in linux kernel we use device specific quirks to workaround broken hardware,
>> there is no point to break generic code for all hardware configurations
>> for the sake of one broken firmware.
>> So it's Windows problem that they prefer to violate spec and cannibalize
>> ACPI0010 for the sake of broken firmware. Open support case with Windows,
>> the more complains they get, the more chances that they'll fix it.
>>
>>> I understand that this is not a qemu problem either. Then again other
>>> emulators we've tested this on (VirtualBox, Parallels, HyperV) provide a
>>> compatible ACPI configuration and don't trigger this conflict. If this
>> we provide it, that's what '_CID' field is for, so OS that doesn't know
>> about ACPI0010 would be happy (any Windows prior Win10/2016)
>>
>>> fix is not a big deal and does not affect anything negatively then maybe
>>> we pay a relatively small price to improve compatibility with some guest
>>> systems?
>> we plan to reuse this code for ARM in future and it might use
>> ACPI0010 container as per spec to describe modeled topology.
>> Hence no workaround in QEMU, just use MS suggested workaround
>> to remove wrong device binding in WS2016 until they actually
>> fix it.
> I wonder whether adding an INF with a stub driver
> on the install disk can also help as a work-around.
> Thoughts?

As far as i know this is one of the proposed solutions we consider. Will 
have to test and see.

>>>>> Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
>>>>> ---
>>>>>    hw/acpi/cpu.c | 2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
>>>>> index a233fe1..b93db40 100644
>>>>> --- a/hw/acpi/cpu.c
>>>>> +++ b/hw/acpi/cpu.c
>>>>> @@ -397,7 +397,7 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
>>>>>            Aml *rm_evt = aml_name("%s.%s", cphp_res_path, CPU_REMOVE_EVENT);
>>>>>            Aml *ej_evt = aml_name("%s.%s", cphp_res_path, CPU_EJECT_EVENT);
>>>>>    
>>>>> -        aml_append(cpus_dev, aml_name_decl("_HID", aml_string("ACPI0010")));
>>>>> +        aml_append(cpus_dev, aml_name_decl("_HID", aml_string("PNP0A05")));
>>>>>            aml_append(cpus_dev, aml_name_decl("_CID", aml_eisaid("PNP0A05")));
>>>>>    
>>>>>            method = aml_method(CPU_NOTIFY_METHOD, 2, AML_NOTSERIALIZED);
>>>

      reply	other threads:[~2017-05-23  7:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22  9:50 [Qemu-devel] [PATCH] change CPU container node _HID to compatible PNP0A05 Evgeny Yakovlev
2017-05-22  9:50 ` [Qemu-devel] [PATCH] acpi: " Evgeny Yakovlev
2017-05-22 10:35   ` Igor Mammedov
2017-05-22 11:01     ` Evgeny Yakovlev
2017-05-22 12:58       ` Igor Mammedov
2017-05-22 17:44         ` Michael S. Tsirkin
2017-05-23  7:53           ` Evgeny Yakovlev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d063eb22-cd22-80e7-d9f9-46b0fed61f28@virtuozzo.com \
    --to=eyakovlev@virtuozzo.com \
    --cc=den@virtuozzo.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkagan@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).