Windows 10 won't run on default x86_64 machine anymore

Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

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

Hi,

with the introduction of the following patch from 17th of February, Win10
won't boot anymore without explicitly setting the machine to be 5.2 compatible
like pc-1440fx-5.2. The default 6.0 will cause it to panic and gives as reason
only "ACPI error".

It might work to counter a bug in Linux but this is not the place to do the
patch. The BSDs don't care and will boot fine with full ACPI regardless of the
machine chosen. Windows 10 however DOES care and gets confused.

I think its better to revert this and fix Linux ;) or make it a selectable
feature as a workaround that's by default OFF :)

With regards,
Reinoud


The patch concerned is:

commit 6be8cf56bc8bda2ed9a070bdb04446191f31acc9
Author: Isaku Yamahata <isaku.yamahata@intel.com>
Date:   Wed Feb 17 21:51:12 2021 -0800

    acpi/core: always set SCI_EN when SMM isn't supported
    
    If SMM is not supported, ACPI fixed hardware doesn't support
    legacy-mode. ACPI-only platform. Where SCI_EN in PM1_CNT register is
    always set.
    The bit tells OS legacy mode(SCI_EN cleared) or ACPI mode(SCI_EN set).
    
    With the next patch (setting fadt.smi_cmd = 0 when smm isn't enabled),
    guest Linux tries to switch to ACPI mode, finds smi_cmd = 0, and then
    fails to initialize acpi subsystem. This patch proactively fixes it.
    
    This patch changes guest ABI. To keep compatibility, use
    "smm-compat" introduced by earlier patch. If the property is true,
    disable new behavior.
    
    ACPI spec 4.8.10.1 PM1 Event Grouping
    PM1 Eanble Registers
    > For ACPI-only platforms (where SCI_EN is always set)
    
    Reviewed-by: Igor Mammedov <imammedo@redhat.com>
    Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
    Message-Id:
<500f62081626997e46f96377393d3662211763a8.1613615732.git.isaku.yamahata@intel.com>
    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

 hw/acpi/core.c         | 11 ++++++++++-
 hw/acpi/ich9.c         |  2 +-
 hw/acpi/piix4.c        |  3 ++-
 hw/core/machine.c      |  5 ++++-
 hw/isa/vt82c686.c      |  2 +-
 include/hw/acpi/acpi.h |  4 +++-
 6 files changed, 21 insertions(+), 6 deletions(-)



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Windows 10 won't run on default x86_64 machine anymore

[Daniel P. Berrangé]

On Mon, Mar 15, 2021 at 05:58:04PM +0100, Reinoud Zandijk wrote:
> Hi,
> 
> with the introduction of the following patch from 17th of February, Win10
> won't boot anymore without explicitly setting the machine to be 5.2 compatible
> like pc-1440fx-5.2. The default 6.0 will cause it to panic and gives as reason
> only "ACPI error".
> 
> It might work to counter a bug in Linux but this is not the place to do the
> patch. The BSDs don't care and will boot fine with full ACPI regardless of the
> machine chosen. Windows 10 however DOES care and gets confused.
> 
> I think its better to revert this and fix Linux ;) or make it a selectable
> feature as a workaround that's by default OFF :)

I'm copying the people involved in creating/reviewing the commit you
mention below.

I've also added this regression to the 6.0 issues list, since being
able to boot current Windows guests with the default machine type
should be considered a release blocker IMHO.

   https://wiki.qemu.org/Planning/6.0#Not_fixed_yet

> 
> With regards,
> Reinoud
> 
> 
> The patch concerned is:
> 
> commit 6be8cf56bc8bda2ed9a070bdb04446191f31acc9
> Author: Isaku Yamahata <isaku.yamahata@intel.com>
> Date:   Wed Feb 17 21:51:12 2021 -0800
> 
>     acpi/core: always set SCI_EN when SMM isn't supported
>     
>     If SMM is not supported, ACPI fixed hardware doesn't support
>     legacy-mode. ACPI-only platform. Where SCI_EN in PM1_CNT register is
>     always set.
>     The bit tells OS legacy mode(SCI_EN cleared) or ACPI mode(SCI_EN set).
>     
>     With the next patch (setting fadt.smi_cmd = 0 when smm isn't enabled),
>     guest Linux tries to switch to ACPI mode, finds smi_cmd = 0, and then
>     fails to initialize acpi subsystem. This patch proactively fixes it.
>     
>     This patch changes guest ABI. To keep compatibility, use
>     "smm-compat" introduced by earlier patch. If the property is true,
>     disable new behavior.
>     
>     ACPI spec 4.8.10.1 PM1 Event Grouping
>     PM1 Eanble Registers
>     > For ACPI-only platforms (where SCI_EN is always set)
>     
>     Reviewed-by: Igor Mammedov <imammedo@redhat.com>
>     Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
>     Message-Id:
> <500f62081626997e46f96377393d3662211763a8.1613615732.git.isaku.yamahata@intel.com>
>     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
>  hw/acpi/core.c         | 11 ++++++++++-
>  hw/acpi/ich9.c         |  2 +-
>  hw/acpi/piix4.c        |  3 ++-
>  hw/core/machine.c      |  5 ++++-
>  hw/isa/vt82c686.c      |  2 +-
>  include/hw/acpi/acpi.h |  4 +++-
>  6 files changed, 21 insertions(+), 6 deletions(-)
> 
> 



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Windows 10 won't run on default x86_64 machine anymore

[Isaku Yamahata]

On Mon, Mar 15, 2021 at 05:19:17PM +0000,
"Daniel P. Berrangé" <berrange@redhat.com> wrote:

> On Mon, Mar 15, 2021 at 05:58:04PM +0100, Reinoud Zandijk wrote:
> > Hi,
> > 
> > with the introduction of the following patch from 17th of February, Win10
> > won't boot anymore without explicitly setting the machine to be 5.2 compatible
> > like pc-1440fx-5.2. The default 6.0 will cause it to panic and gives as reason
> > only "ACPI error".
> > 
> > It might work to counter a bug in Linux but this is not the place to do the
> > patch. The BSDs don't care and will boot fine with full ACPI regardless of the
> > machine chosen. Windows 10 however DOES care and gets confused.
> > 
> > I think its better to revert this and fix Linux ;) or make it a selectable
> > feature as a workaround that's by default OFF :)
> 
> I'm copying the people involved in creating/reviewing the commit you
> mention below.
> 
> I've also added this regression to the 6.0 issues list, since being
> able to boot current Windows guests with the default machine type
> should be considered a release blocker IMHO.
> 
>    https://wiki.qemu.org/Planning/6.0#Not_fixed_yet

It's about ACPI spec conformance. What qemu command line is used?
Smi is explicitly disabled (property smm=off), but guest requires legacy bios mode?
What about enabling smm mode? or "-global PIIX4_PM.smm-compat=on"
(or "-global ICH9-LPC.smm-compat=on" if you use q35)

Thanks,
Isaku Yamahata
-- 
Isaku Yamahata <isaku.yamahata@gmail.com>

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Mon, 15 Mar 2021 17:58:04 +0100
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> Hi,
> 
> with the introduction of the following patch from 17th of February, Win10
> won't boot anymore without explicitly setting the machine to be 5.2 compatible
> like pc-1440fx-5.2. The default 6.0 will cause it to panic and gives as reason
> only "ACPI error".
> 
> It might work to counter a bug in Linux but this is not the place to do the
> patch. The BSDs don't care and will boot fine with full ACPI regardless of the
> machine chosen. Windows 10 however DOES care and gets confused.
> 
> I think its better to revert this and fix Linux ;) or make it a selectable
> feature as a workaround that's by default OFF :)

Windows 10 1607x64 boots fine when I test it with default machine.

So
  1) can you provide full QEMU command line used
  2) What Windows build do you use
  3) is it existing guest image (i.e. installed in older QEMU version)


> With regards,
> Reinoud
> 
> 
> The patch concerned is:
> 
> commit 6be8cf56bc8bda2ed9a070bdb04446191f31acc9
> Author: Isaku Yamahata <isaku.yamahata@intel.com>
> Date:   Wed Feb 17 21:51:12 2021 -0800
> 
>     acpi/core: always set SCI_EN when SMM isn't supported
>     
>     If SMM is not supported, ACPI fixed hardware doesn't support
>     legacy-mode. ACPI-only platform. Where SCI_EN in PM1_CNT register is
>     always set.
>     The bit tells OS legacy mode(SCI_EN cleared) or ACPI mode(SCI_EN set).
>     
>     With the next patch (setting fadt.smi_cmd = 0 when smm isn't enabled),
>     guest Linux tries to switch to ACPI mode, finds smi_cmd = 0, and then
>     fails to initialize acpi subsystem. This patch proactively fixes it.
>     
>     This patch changes guest ABI. To keep compatibility, use
>     "smm-compat" introduced by earlier patch. If the property is true,
>     disable new behavior.
>     
>     ACPI spec 4.8.10.1 PM1 Event Grouping
>     PM1 Eanble Registers
>     > For ACPI-only platforms (where SCI_EN is always set)  
>     
>     Reviewed-by: Igor Mammedov <imammedo@redhat.com>
>     Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
>     Message-Id:
> <500f62081626997e46f96377393d3662211763a8.1613615732.git.isaku.yamahata@intel.com>
>     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
>  hw/acpi/core.c         | 11 ++++++++++-
>  hw/acpi/ich9.c         |  2 +-
>  hw/acpi/piix4.c        |  3 ++-
>  hw/core/machine.c      |  5 ++++-
>  hw/isa/vt82c686.c      |  2 +-
>  include/hw/acpi/acpi.h |  4 +++-
>  6 files changed, 21 insertions(+), 6 deletions(-)
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Mon, Mar 15, 2021 at 06:53:02PM +0100, Igor Mammedov wrote:
> Windows 10 1607x64 boots fine when I test it with default machine.
> 
> So
>   1) can you provide full QEMU command line used
>   2) What Windows build do you use
>   3) is it existing guest image (i.e. installed in older QEMU version)

I've used:

qemu-system-x86_64 -m 4G -smp cores=2 -accel nvmm \
	-snapshot \
	-drive file=/home/reinoud/Downloads/Win10-demo.raw,format=raw \
	-rtc base=localtime,clock=host \
	-spice port=5924,disable-ticketing=on \
	-vga qxl \
	-usb -device usb-tablet \
	-net nic -net tap,ifname=tap0,script=no &

If I add in '-M pc-i440fx-5.2' it works again with the accelerator. If I add
in '-M q35' it does work fine with or without the accelerator.

Surprisingly without accelerator ie with tcg the default machine does seem to
get to the login prompt. Is the ACPI data tailored to indicate an
accelerator/VM or is it static? Could it be that the CPU reported by my
machine is causing the issue? With the NVMM accelerator it passes on the hosts
CPU:

cpu0: "Intel(R) Celeron(R) 2957U @ 1.40GHz"
cpu0: Intel 4th gen Core, Xeon E3-12xx v3 (Haswell) (686-class), 1396.77 MHz
cpu0: family 0x6 model 0x45 stepping 0x1 (id 0x40651)

Running with NVMM gives the following warnings that might be relevant though
doesn't seem to bother the BSDs nor Linux last time I tried and Google tells
me they are power saving related MSRs:

qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored
qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored

I am not sure if that makes ACPI take a different route or not.

The Windows used is
	Windows 10 Enterprise Evaluation
	Build 17763.rs5_release.180914-1434
	version 1809

The image file was downloaded pre-installed from Microsoft for Edge browser
evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.

The NVMM accelerator was presented here before but is not yet committed. Its
API/construction is similar to WHPX.

As for the cause, I don't know; q35-6.0 works so why isn't pc-i440fx-6.0 ?

With regards,
Reinoud

Re: Windows 10 won't run on default x86_64 machine anymore

[Isaku Yamahata]

On Mon, Mar 15, 2021 at 11:27:29PM +0100,
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> On Mon, Mar 15, 2021 at 06:53:02PM +0100, Igor Mammedov wrote:
> > Windows 10 1607x64 boots fine when I test it with default machine.
> > 
> > So
> >   1) can you provide full QEMU command line used
> >   2) What Windows build do you use
> >   3) is it existing guest image (i.e. installed in older QEMU version)
> 
> I've used:
> 
> qemu-system-x86_64 -m 4G -smp cores=2 -accel nvmm \
> 	-snapshot \
> 	-drive file=/home/reinoud/Downloads/Win10-demo.raw,format=raw \
> 	-rtc base=localtime,clock=host \
> 	-spice port=5924,disable-ticketing=on \
> 	-vga qxl \
> 	-usb -device usb-tablet \
> 	-net nic -net tap,ifname=tap0,script=no &
> 
> If I add in '-M pc-i440fx-5.2' it works again with the accelerator. If I add
> in '-M q35' it does work fine with or without the accelerator.

Anyhow, can you please try "-global PIIX4_PM.smm-compat=on"
(or "-global ICH9-LPC.smm-compat=on" if q35 is used) so that the old behavior
is presented.


> Surprisingly without accelerator ie with tcg the default machine does seem to
> get to the login prompt. Is the ACPI data tailored to indicate an
> accelerator/VM or is it static? Could it be that the CPU reported by my
> machine is causing the issue? With the NVMM accelerator it passes on the hosts

I think tcg case can be explained by x86_machine_is_smm_enabled()

  bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
  ...
      if (tcg_enabled() || qtest_enabled()) {
          smm_available = true;
      } else if (kvm_enabled()) {
          smm_available = kvm_has_smm();
      }
  ...

Although I don't know about nvmm case, this function also needs to be updated
if smi isn't supported.

Thanks,


> CPU:
> 
> cpu0: "Intel(R) Celeron(R) 2957U @ 1.40GHz"
> cpu0: Intel 4th gen Core, Xeon E3-12xx v3 (Haswell) (686-class), 1396.77 MHz
> cpu0: family 0x6 model 0x45 stepping 0x1 (id 0x40651)
> 
> Running with NVMM gives the following warnings that might be relevant though
> doesn't seem to bother the BSDs nor Linux last time I tried and Google tells
> me they are power saving related MSRs:
> 
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
> qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored
> 
> I am not sure if that makes ACPI take a different route or not.
> 
> The Windows used is
> 	Windows 10 Enterprise Evaluation
> 	Build 17763.rs5_release.180914-1434
> 	version 1809
> 
> The image file was downloaded pre-installed from Microsoft for Edge browser
> evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.
> 
> The NVMM accelerator was presented here before but is not yet committed. Its
> API/construction is similar to WHPX.
> 
> As for the cause, I don't know; q35-6.0 works so why isn't pc-i440fx-6.0 ?
> 
> With regards,
> Reinoud
> 
> 

-- 
Isaku Yamahata <isaku.yamahata@gmail.com>

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Mon, 15 Mar 2021 18:55:03 -0700
Isaku Yamahata <isaku.yamahata@gmail.com> wrote:

> On Mon, Mar 15, 2021 at 11:27:29PM +0100,
> Reinoud Zandijk <reinoud@NetBSD.org> wrote:
> 
> > On Mon, Mar 15, 2021 at 06:53:02PM +0100, Igor Mammedov wrote:  
> > > Windows 10 1607x64 boots fine when I test it with default machine.
> > > 
> > > So
> > >   1) can you provide full QEMU command line used
> > >   2) What Windows build do you use
> > >   3) is it existing guest image (i.e. installed in older QEMU version)  
> > 
> > I've used:
> > 
> > qemu-system-x86_64 -m 4G -smp cores=2 -accel nvmm \
> > 	-snapshot \
> > 	-drive file=/home/reinoud/Downloads/Win10-demo.raw,format=raw \
> > 	-rtc base=localtime,clock=host \
> > 	-spice port=5924,disable-ticketing=on \
> > 	-vga qxl \
> > 	-usb -device usb-tablet \
> > 	-net nic -net tap,ifname=tap0,script=no &
> > 
> > If I add in '-M pc-i440fx-5.2' it works again with the accelerator. If I add
> > in '-M q35' it does work fine with or without the accelerator.  
> 
> Anyhow, can you please try "-global PIIX4_PM.smm-compat=on"
> (or "-global ICH9-LPC.smm-compat=on" if q35 is used) so that the old behavior
> is presented.
> 
> 
> > Surprisingly without accelerator ie with tcg the default machine does seem to
> > get to the login prompt. Is the ACPI data tailored to indicate an
> > accelerator/VM or is it static? Could it be that the CPU reported by my
> > machine is causing the issue? With the NVMM accelerator it passes on the hosts  
> 
> I think tcg case can be explained by x86_machine_is_smm_enabled()
> 
>   bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
>   ...
>       if (tcg_enabled() || qtest_enabled()) {
>           smm_available = true;
>       } else if (kvm_enabled()) {
>           smm_available = kvm_has_smm();
>       }
>   ...
> 
> Although I don't know about nvmm case, this function also needs to be updated
> if smi isn't supported.
can you submit a patch for this please?

> 
> Thanks,
> 
> 
> > CPU:
> > 
> > cpu0: "Intel(R) Celeron(R) 2957U @ 1.40GHz"
> > cpu0: Intel 4th gen Core, Xeon E3-12xx v3 (Haswell) (686-class), 1396.77 MHz
> > cpu0: family 0x6 model 0x45 stepping 0x1 (id 0x40651)
> > 
> > Running with NVMM gives the following warnings that might be relevant though
> > doesn't seem to bother the BSDs nor Linux last time I tried and Google tells
> > me they are power saving related MSRs:
> > 
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x606, ignored
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x641, ignored
> > qemu-system-x86_64: NVMM: Unexpected RDMSR 0x611, ignored
> > 
> > I am not sure if that makes ACPI take a different route or not.
> > 
> > The Windows used is
> > 	Windows 10 Enterprise Evaluation
> > 	Build 17763.rs5_release.180914-1434
> > 	version 1809
> > 
> > The image file was downloaded pre-installed from Microsoft for Edge browser
> > evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.
> > 
> > The NVMM accelerator was presented here before but is not yet committed. Its
> > API/construction is similar to WHPX.
> > 
> > As for the cause, I don't know; q35-6.0 works so why isn't pc-i440fx-6.0 ?
> > 
> > With regards,
> > Reinoud
> > 
> >   
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Paolo Bonzini]

On 16/03/21 13:13, Igor Mammedov wrote:
>>> Surprisingly without accelerator ie with tcg the default machine does seem to
>>> get to the login prompt. Is the ACPI data tailored to indicate an
>>> accelerator/VM or is it static? Could it be that the CPU reported by my
>>> machine is causing the issue? With the NVMM accelerator it passes on the hosts
>>
>> I think tcg case can be explained by x86_machine_is_smm_enabled()
>>
>>    bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
>>    ...
>>        if (tcg_enabled() || qtest_enabled()) {
>>            smm_available = true;
>>        } else if (kvm_enabled()) {
>>            smm_available = kvm_has_smm();
>>        }
>>    ...
>>
>> Although I don't know about nvmm case, this function also needs to be updated
>> if smi isn't supported.
> can you submit a patch for this please?

nvmm is not part of upstream yet, so I guess it's up to Reinoud to fix 
it.  Still, reproducing his testing conditions with KVM and -M smm=off 
is probably interesting because it also affects HAX, HVF and WHPX which 
are supported upstream.

Paolo

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 13:49:57 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 16/03/21 13:13, Igor Mammedov wrote:
> >>> Surprisingly without accelerator ie with tcg the default machine does seem to
> >>> get to the login prompt. Is the ACPI data tailored to indicate an
> >>> accelerator/VM or is it static? Could it be that the CPU reported by my
> >>> machine is causing the issue? With the NVMM accelerator it passes on the hosts  
> >>
> >> I think tcg case can be explained by x86_machine_is_smm_enabled()
> >>
> >>    bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
> >>    ...
> >>        if (tcg_enabled() || qtest_enabled()) {
> >>            smm_available = true;
> >>        } else if (kvm_enabled()) {
> >>            smm_available = kvm_has_smm();
> >>        }
> >>    ...
> >>
> >> Although I don't know about nvmm case, this function also needs to be updated
> >> if smi isn't supported.  
> > can you submit a patch for this please?  
> 
> nvmm is not part of upstream yet, so I guess it's up to Reinoud to fix 
> it.  Still, reproducing his testing conditions with KVM and -M smm=off 
> is probably interesting because it also affects HAX, HVF and WHPX which 
> are supported upstream.

I'm in process of preparing test env for it with reported Windows version,
so I'll try this case as well.

> 
> Paolo
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 14:10:44 +0100
Igor Mammedov <imammedo@redhat.com> wrote:

> On Tue, 16 Mar 2021 13:49:57 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 16/03/21 13:13, Igor Mammedov wrote:  
> > >>> Surprisingly without accelerator ie with tcg the default machine does seem to
> > >>> get to the login prompt. Is the ACPI data tailored to indicate an
> > >>> accelerator/VM or is it static? Could it be that the CPU reported by my
> > >>> machine is causing the issue? With the NVMM accelerator it passes on the hosts    
> > >>
> > >> I think tcg case can be explained by x86_machine_is_smm_enabled()
> > >>
> > >>    bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
> > >>    ...
> > >>        if (tcg_enabled() || qtest_enabled()) {
> > >>            smm_available = true;
> > >>        } else if (kvm_enabled()) {
> > >>            smm_available = kvm_has_smm();
> > >>        }
> > >>    ...
> > >>
> > >> Although I don't know about nvmm case, this function also needs to be updated
> > >> if smi isn't supported.    
> > > can you submit a patch for this please?    
> > 
> > nvmm is not part of upstream yet, so I guess it's up to Reinoud to fix 
> > it.  Still, reproducing his testing conditions with KVM and -M smm=off 
> > is probably interesting because it also affects HAX, HVF and WHPX which 
> > are supported upstream.  
> 
> I'm in process of preparing test env for it with reported Windows version,
> so I'll try this case as well.
> 

Here is test matrix booting Windows install ISO:
qemu-system-x86_64  -m 4G -smp cores=2 -cpu host -accel kvm -vnc localhost:0 -snapshot -M pc-i440fx-6.0,smm=off \
 -cdrom en_windows_10_business_editions_version_1809_updated_jan_2019_x64_dvd_72a665f1.iso

                       | smm=on     | smm=off    |
--------------------------------------------------
QEMU6.0 pc-i440fx-5.2  |    pass    | pass       |
defaut smm-compat=on   |            |            |
--------------------------------------------------
QEMU6.0 pc-i440fx-6.0  |    pass    | fail       |
defaut smm-compat=off  |            |            |
-------------------------------------------------|

so it will break booting Windows on accelerators that do not support smm
by default starting from pc-i440fx-6.0 machine type.

It asserts in: 0xa5_FAILED_ACPI_TRANSITION_ACPI!ACPIEnableEnterACPIMode

I haven't looked into what it doesn't like there.


> > Paolo
> >   
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Paolo Bonzini]

On 16/03/21 17:49, Igor Mammedov wrote:
>                         | smm=on     | smm=off    |
> --------------------------------------------------
> QEMU6.0 pc-i440fx-5.2  |    pass    | pass       |
> defaut smm-compat=on   |            |            |
> --------------------------------------------------
> QEMU6.0 pc-i440fx-6.0  |    pass    | fail       |
> defaut smm-compat=off  |            |            |
> -------------------------------------------------|
> 
> so it will break booting Windows on accelerators that do not support smm
> by default starting from pc-i440fx-6.0 machine type.
> 
> It asserts in: 0xa5_FAILED_ACPI_TRANSITION_ACPI!ACPIEnableEnterACPIMode

Since smm is part of the guest ABI, can we just set use "!smm || 
smm-compat" whenever we use smm-compat right now?

Paolo

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 18:33:47 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 16/03/21 17:49, Igor Mammedov wrote:
> >                         | smm=on     | smm=off    |
> > --------------------------------------------------
> > QEMU6.0 pc-i440fx-5.2  |    pass    | pass       |
> > defaut smm-compat=on   |            |            |
> > --------------------------------------------------
> > QEMU6.0 pc-i440fx-6.0  |    pass    | fail       |
> > defaut smm-compat=off  |            |            |
> > -------------------------------------------------|
> > 
> > so it will break booting Windows on accelerators that do not support smm
> > by default starting from pc-i440fx-6.0 machine type.
> > 
> > It asserts in: 0xa5_FAILED_ACPI_TRANSITION_ACPI!ACPIEnableEnterACPIMode  
> 
> Since smm is part of the guest ABI, can we just set use "!smm || 
> smm-compat" whenever we use smm-compat right now?

if we can't fix issue before release, then we will have to do something like this.


> Paolo
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Tue, Mar 16, 2021 at 01:49:57PM +0100, Paolo Bonzini wrote:
> On 16/03/21 13:13, Igor Mammedov wrote:
> > > Although I don't know about nvmm case, this function also needs to be updated
> > > if smi isn't supported.
> > can you submit a patch for this please?

> nvmm is not part of upstream yet, so I guess it's up to Reinoud to fix it.
> Still, reproducing his testing conditions with KVM and -M smm=off is
> probably interesting because it also affects HAX, HVF and WHPX which are
> supported upstream.

As stated in my other mail, I think NVMM supports the SMI. We would have liked
to add NVMM in the comming 6.0 release but I see we missed the timeframe as
the soft feature freeze date is today.

It was posted here some months before but somehow it got stalled and when the
main NVMM developer left the project to persuit other things it kind of
stalled. I've now forward ported NVMM support to todays Qemu sources.

With regards,
Reinoud

Re: Windows 10 won't run on default x86_64 machine anymore

[Paolo Bonzini]

On 16/03/21 17:27, Reinoud Zandijk wrote:
> On Tue, Mar 16, 2021 at 01:49:57PM +0100, Paolo Bonzini wrote:
>> On 16/03/21 13:13, Igor Mammedov wrote:
>>>> Although I don't know about nvmm case, this function also needs to be updated
>>>> if smi isn't supported.
>>> can you submit a patch for this please?
> 
>> nvmm is not part of upstream yet, so I guess it's up to Reinoud to fix it.
>> Still, reproducing his testing conditions with KVM and -M smm=off is
>> probably interesting because it also affects HAX, HVF and WHPX which are
>> supported upstream.
> 
> As stated in my other mail, I think NVMM supports the SMI.

I doubt, even KVM only supports it as a kind of "fringe" feature for 
secure boot.  But anyway, feel free to post the patches now and we'll 
have time to do more passes if needed, during the freeze.

Paolo

> We would have liked
> to add NVMM in the comming 6.0 release but I see we missed the timeframe as
> the soft feature freeze date is today.
> 
> It was posted here some months before but somehow it got stalled and when the
> main NVMM developer left the project to persuit other things it kind of
> stalled. I've now forward ported NVMM support to todays Qemu sources.
> 
> With regards,
> Reinoud
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Mon, Mar 15, 2021 at 06:55:03PM -0700, Isaku Yamahata wrote:
> > If I add in '-M pc-i440fx-5.2' it works again with the accelerator. If I add
> > in '-M q35' it does work fine with or without the accelerator.
> 
> Anyhow, can you please try "-global PIIX4_PM.smm-compat=on"
> (or "-global ICH9-LPC.smm-compat=on" if q35 is used) so that the old behavior
> is presented.

It works indeed with the default model when I specify the -global. With Q35
its not needed; it boots fine after reconfiguring itself.

> I think tcg case can be explained by x86_machine_is_smm_enabled()
> 
>   bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
>   ...
>       if (tcg_enabled() || qtest_enabled()) {
>           smm_available = true;
>       } else if (kvm_enabled()) {
>           smm_available = kvm_has_smm();
>       }
>   ...
> 
> Although I don't know about nvmm case, this function also needs to be updated
> if smi isn't supported.

The NVMM backend can only be used on x86_64 (for now) and then only for CPUs
with VMX or SVM support. It can run 32 and 64 bit OSes. On all other systems
the kernel module either does not exist or refuses to load.

NVMM has support code for it for the SVM and VMX backends and it allows them.
NVMM also handles the SMI just as WHPX does in the Qemu backend.

So maybe it an be set to default on in this test?

With regards,
Reinoud

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Mon, Mar 15, 2021 at 06:55:03PM -0700, Isaku Yamahata wrote:
> I think tcg case can be explained by x86_machine_is_smm_enabled()
> 
>   bool x86_machine_is_smm_enabled(const X86MachineState *x86ms)
>   ...
>       if (tcg_enabled() || qtest_enabled()) {
>           smm_available = true;
>       } else if (kvm_enabled()) {
>           smm_available = kvm_has_smm();
>       }
>   ...
> 
> Although I don't know about nvmm case, this function also needs to be updated
> if smi isn't supported.

I can create a local patch to enable SMM here when NVMM is enabled if KVM, HAX
and HWPX work fine.

Shouldn't this check be rewritten? What about HWPX and the others? They will
always report smm_available=false here.

Reinoud

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Mon, 15 Mar 2021 23:27:29 +0100
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> On Mon, Mar 15, 2021 at 06:53:02PM +0100, Igor Mammedov wrote:
> > Windows 10 1607x64 boots fine when I test it with default machine.
> > 
> > So
> >   1) can you provide full QEMU command line used
> >   2) What Windows build do you use
> >   3) is it existing guest image (i.e. installed in older QEMU version)  
[...]
> 
> The image file was downloaded pre-installed from Microsoft for Edge browser
> evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.

issue looks similar to:
0a343a5add7 i386/acpi: restore device paths for pre-5.1 vms

I think that's the problem, the old Windows image (installed on old QEMU),
may fail to boot if started on newest machine type of a newer QEMU.
User should use versioned machine type (the same version it was installed on)
to keep it working the same way otherwise there is no promise that machine ABI
won't change.

> 
> The NVMM accelerator was presented here before but is not yet committed. Its
> API/construction is similar to WHPX.
does it work with kvm for the same image/configuration?

 
> As for the cause, I don't know; q35-6.0 works so why isn't pc-i440fx-6.0 ?
> 
> With regards,
> Reinoud
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Tue, Mar 16, 2021 at 01:53:01PM +0100, Igor Mammedov wrote:
> > The image file was downloaded pre-installed from Microsoft for Edge browser
> > evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.
> 
> issue looks similar to:
> 0a343a5add7 i386/acpi: restore device paths for pre-5.1 vms
> 
> I think that's the problem, the old Windows image (installed on old QEMU),
> may fail to boot if started on newest machine type of a newer QEMU.
> User should use versioned machine type (the same version it was installed on)
> to keep it working the same way otherwise there is no promise that machine ABI
> won't change.

The machine setup doesn't mind changing the machine to the Q35 type; its only
the older machine thats failing to work.

Reinoud

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 17:28:52 +0100
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> On Tue, Mar 16, 2021 at 01:53:01PM +0100, Igor Mammedov wrote:
> > > The image file was downloaded pre-installed from Microsoft for Edge browser
> > > evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.  
> > 
> > issue looks similar to:
> > 0a343a5add7 i386/acpi: restore device paths for pre-5.1 vms
> > 
> > I think that's the problem, the old Windows image (installed on old QEMU),
> > may fail to boot if started on newest machine type of a newer QEMU.
> > User should use versioned machine type (the same version it was installed on)
> > to keep it working the same way otherwise there is no promise that machine ABI
> > won't change.  
> 
> The machine setup doesn't mind changing the machine to the Q35 type; its only
> the older machine thats failing to work.

never-mind, either we have a bug on piix4 side of QEMU or Windows doesn't support
smm less mode, probably the former since q35 works.
I'm trying to dig out what's going wrong,
maybe Isaku Yamahata can also look into it.

> 
> Reinoud
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 18:17:50 +0100
Igor Mammedov <imammedo@redhat.com> wrote:

> On Tue, 16 Mar 2021 17:28:52 +0100
> Reinoud Zandijk <reinoud@NetBSD.org> wrote:
> 
> > On Tue, Mar 16, 2021 at 01:53:01PM +0100, Igor Mammedov wrote:  
> > > > The image file was downloaded pre-installed from Microsoft for Edge browser
> > > > evaluation. I used it first on Qemu 5.1 IIRC and it kept working in Qemu 5.2.    
> > > 
> > > issue looks similar to:
> > > 0a343a5add7 i386/acpi: restore device paths for pre-5.1 vms
> > > 
> > > I think that's the problem, the old Windows image (installed on old QEMU),
> > > may fail to boot if started on newest machine type of a newer QEMU.
> > > User should use versioned machine type (the same version it was installed on)
> > > to keep it working the same way otherwise there is no promise that machine ABI
> > > won't change.    
> > 
> > The machine setup doesn't mind changing the machine to the Q35 type; its only
> > the older machine thats failing to work.  
> 
> never-mind, either we have a bug on piix4 side of QEMU or Windows doesn't support
> smm less mode, probably the former since q35 works.
> I'm trying to dig out what's going wrong,
> maybe Isaku Yamahata can also look into it.

Thanks for reporting it before it was released
please test/review fix that I've just posted:

 "[PATCH for-6.0] x86:acpi:piix4: reinitialize PM1.CNT on reset"

> > 
> > Reinoud
> > 
> >   
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

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

On Tue, Mar 16, 2021 at 09:34:08PM +0100, Igor Mammedov wrote:
> Thanks for reporting it before it was released
> please test/review fix that I've just posted:
> 
>  "[PATCH for-6.0] x86:acpi:piix4: reinitialize PM1.CNT on reset"

I've tested qemu with the patch, booted the install without specifying the
machine with -M and it boots!

Thanks! I think it could be considered fixed now?

Reinoud


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Wed, 17 Mar 2021 09:58:25 +0100
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> On Tue, Mar 16, 2021 at 09:34:08PM +0100, Igor Mammedov wrote:
> > Thanks for reporting it before it was released
> > please test/review fix that I've just posted:
> > 
> >  "[PATCH for-6.0] x86:acpi:piix4: reinitialize PM1.CNT on reset"  
> 
> I've tested qemu with the patch, booted the install without specifying the
> machine with -M and it boots!
Thanks for testing.

> Thanks! I think it could be considered fixed now?
I think so.

If you wish, you can reply here with 'Tested-By:'
so your contribution would be mentioned in commit message,
and may add "Reported-by:" as well (sorry I forgot about including it)

> 
> Reinoud
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

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

On Wed, Mar 17, 2021 at 09:58:25AM +0100, Reinoud Zandijk wrote:
> On Tue, Mar 16, 2021 at 09:34:08PM +0100, Igor Mammedov wrote:
> > Thanks for reporting it before it was released
> > please test/review fix that I've just posted:
> > 
> >  "[PATCH for-6.0] x86:acpi:piix4: reinitialize PM1.CNT on reset"
> 
> I've tested qemu with the patch, booted the install without specifying the
> machine with -M and it boots!

For completion, I tested the following configurations with the Win10 image:

              | NVMM/q35 | NVMM/pc | TCG/q35 | TCG/pc
--------------|----------|---------|---------|-----------
Without patch | OK       | XXX     | OK      | OK
--------------|----------|---------|---------|-----------
With patch    | OK       | OK      | OK      | OK


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Windows 10 won't run on default x86_64 machine anymore

[Reinoud Zandijk]

On Tue, Mar 16, 2021 at 09:34:08PM +0100, Igor Mammedov wrote:
> Thanks for reporting it before it was released
> please test/review fix that I've just posted:
> 
>  "[PATCH for-6.0] x86:acpi:piix4: reinitialize PM1.CNT on reset"

Reported-by: Reinoud Zandijk <reinoud@NetBSD.org>
Tested-by: Reinoud Zandijk <reinoud@NetBSD.org>

Re: Windows 10 won't run on default x86_64 machine anymore

[Michael S. Tsirkin]

On Mon, Mar 15, 2021 at 05:58:04PM +0100, Reinoud Zandijk wrote:
> Hi,
> 
> with the introduction of the following patch from 17th of February, Win10
> won't boot anymore without explicitly setting the machine to be 5.2 compatible
> like pc-1440fx-5.2. The default 6.0 will cause it to panic and gives as reason
> only "ACPI error".


Thanks for the report!
Could you provide a bit more detail please?
Which windows version is used, which qemu command line, etc etc.

Also does this only affect pre-installed guests? what if you
install a fresh copy of windows?

> It might work to counter a bug in Linux but this is not the place to do the
> patch. The BSDs don't care and will boot fine with full ACPI regardless of the
> machine chosen. Windows 10 however DOES care and gets confused.
> 
> I think its better to revert this and fix Linux ;) or make it a selectable
> feature as a workaround that's by default OFF :)
> 
> With regards,
> Reinoud
> 
> 
> The patch concerned is:
> 
> commit 6be8cf56bc8bda2ed9a070bdb04446191f31acc9
> Author: Isaku Yamahata <isaku.yamahata@intel.com>
> Date:   Wed Feb 17 21:51:12 2021 -0800
> 
>     acpi/core: always set SCI_EN when SMM isn't supported
>     
>     If SMM is not supported, ACPI fixed hardware doesn't support
>     legacy-mode. ACPI-only platform. Where SCI_EN in PM1_CNT register is
>     always set.
>     The bit tells OS legacy mode(SCI_EN cleared) or ACPI mode(SCI_EN set).
>     
>     With the next patch (setting fadt.smi_cmd = 0 when smm isn't enabled),
>     guest Linux tries to switch to ACPI mode, finds smi_cmd = 0, and then
>     fails to initialize acpi subsystem. This patch proactively fixes it.
>     
>     This patch changes guest ABI. To keep compatibility, use
>     "smm-compat" introduced by earlier patch. If the property is true,
>     disable new behavior.
>     
>     ACPI spec 4.8.10.1 PM1 Event Grouping
>     PM1 Eanble Registers
>     > For ACPI-only platforms (where SCI_EN is always set)
>     
>     Reviewed-by: Igor Mammedov <imammedo@redhat.com>
>     Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
>     Message-Id:
> <500f62081626997e46f96377393d3662211763a8.1613615732.git.isaku.yamahata@intel.com>
>     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
>  hw/acpi/core.c         | 11 ++++++++++-
>  hw/acpi/ich9.c         |  2 +-
>  hw/acpi/piix4.c        |  3 ++-
>  hw/core/machine.c      |  5 ++++-
>  hw/isa/vt82c686.c      |  2 +-
>  include/hw/acpi/acpi.h |  4 +++-
>  6 files changed, 21 insertions(+), 6 deletions(-)
> 
> 

Re: Windows 10 won't run on default x86_64 machine anymore

[Isaku Yamahata]

On Mon, Mar 15, 2021 at 05:58:04PM +0100,
Reinoud Zandijk <reinoud@NetBSD.org> wrote:

> I think its better to revert this and fix Linux ;) or make it a selectable
> feature as a workaround that's by default OFF :)

Anyway here is a patch to flip the default.
At the moment, this is compile-only tested to provide the change quickly
and make discussion progress.

From 50deeed38832ceccfb68f78dd66de5a1741b2897 Mon Sep 17 00:00:00 2001
Message-Id: <50deeed38832ceccfb68f78dd66de5a1741b2897.1615845421.git.isaku.yamahata@intel.com>
From: Isaku Yamahata <isaku.yamahata@intel.com>
Date: Mon, 15 Mar 2021 14:42:33 -0700
Subject: [PATCH] ich9, piix4: flip default value for smm-compat

Make default value for smm-compat of ich9, piix4 true to keep old
behavior.
To get new (and more conformance to ACPI spec) behavior, explicitly
set "-global ICH9-LPC.smm-compat=off" or
"-global PIIX4_PM.smm-compat=off".

Reported-by: Reinoud Zandijk <reinoud@NetBSD.org>
Fixes: 24cd04fce0 ("ich9, piix4: add property, smm-compat, to keep compatibility of SMM")
Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
---
 hw/acpi/piix4.c   | 2 +-
 hw/core/machine.c | 2 --
 hw/isa/lpc_ich9.c | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 1efc0ded9f..34ade2c9bb 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -644,7 +644,7 @@ static Property piix4_pm_properties[] = {
                      use_acpi_root_pci_hotplug, true),
     DEFINE_PROP_BOOL("memory-hotplug-support", PIIX4PMState,
                      acpi_memory_hotplug.is_enabled, true),
-    DEFINE_PROP_BOOL("smm-compat", PIIX4PMState, smm_compat, false),
+    DEFINE_PROP_BOOL("smm-compat", PIIX4PMState, smm_compat, true),
     DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 4386f57b5c..e644c4e07d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -37,8 +37,6 @@
 #include "hw/virtio/virtio-pci.h"
 
 GlobalProperty hw_compat_5_2[] = {
-    { "ICH9-LPC", "smm-compat", "on"},
-    { "PIIX4_PM", "smm-compat", "on"},
 };
 const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
 
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 3963b73520..b7ff3a9747 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -775,7 +775,7 @@ static const VMStateDescription vmstate_ich9_lpc = {
 
 static Property ich9_lpc_properties[] = {
     DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
-    DEFINE_PROP_BOOL("smm-compat", ICH9LPCState, pm.smm_compat, false),
+    DEFINE_PROP_BOOL("smm-compat", ICH9LPCState, pm.smm_compat, true),
     DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
                       ICH9_LPC_SMI_F_BROADCAST_BIT, true),
     DEFINE_PROP_BIT64("x-smi-cpu-hotplug", ICH9LPCState, smi_host_features,
-- 
2.25.1



-- 
Isaku Yamahata <isaku.yamahata@gmail.com>

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Mon, 15 Mar 2021 15:05:26 -0700
Isaku Yamahata <isaku.yamahata@gmail.com> wrote:

> On Mon, Mar 15, 2021 at 05:58:04PM +0100,
> Reinoud Zandijk <reinoud@NetBSD.org> wrote:
> 
> > I think its better to revert this and fix Linux ;) or make it a selectable
> > feature as a workaround that's by default OFF :)  
> 
> Anyway here is a patch to flip the default.
> At the moment, this is compile-only tested to provide the change quickly
> and make discussion progress.
> 
> From 50deeed38832ceccfb68f78dd66de5a1741b2897 Mon Sep 17 00:00:00 2001
> Message-Id: <50deeed38832ceccfb68f78dd66de5a1741b2897.1615845421.git.isaku.yamahata@intel.com>
> From: Isaku Yamahata <isaku.yamahata@intel.com>
> Date: Mon, 15 Mar 2021 14:42:33 -0700
> Subject: [PATCH] ich9, piix4: flip default value for smm-compat
> 
> Make default value for smm-compat of ich9, piix4 true to keep old
> behavior.
> To get new (and more conformance to ACPI spec) behavior, explicitly
> set "-global ICH9-LPC.smm-compat=off" or
> "-global PIIX4_PM.smm-compat=off".

I'm not sure we should do that,
it's fine for non-versioned/new machine type to change in incompatible way with old images,
it's the job of old versioned machines types to maintain compatibility.
It's of cause pain for users if they use are unable to boot old image
on newest machine type, but we never promised that and if we made such
promise we would never be able to fix bugs.

> Reported-by: Reinoud Zandijk <reinoud@NetBSD.org>
> Fixes: 24cd04fce0 ("ich9, piix4: add property, smm-compat, to keep compatibility of SMM")
> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
> ---
>  hw/acpi/piix4.c   | 2 +-
>  hw/core/machine.c | 2 --
>  hw/isa/lpc_ich9.c | 2 +-
>  3 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> index 1efc0ded9f..34ade2c9bb 100644
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4.c
> @@ -644,7 +644,7 @@ static Property piix4_pm_properties[] = {
>                       use_acpi_root_pci_hotplug, true),
>      DEFINE_PROP_BOOL("memory-hotplug-support", PIIX4PMState,
>                       acpi_memory_hotplug.is_enabled, true),
> -    DEFINE_PROP_BOOL("smm-compat", PIIX4PMState, smm_compat, false),
> +    DEFINE_PROP_BOOL("smm-compat", PIIX4PMState, smm_compat, true),
>      DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 4386f57b5c..e644c4e07d 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -37,8 +37,6 @@
>  #include "hw/virtio/virtio-pci.h"
>  
>  GlobalProperty hw_compat_5_2[] = {
> -    { "ICH9-LPC", "smm-compat", "on"},
> -    { "PIIX4_PM", "smm-compat", "on"},
>  };
>  const size_t hw_compat_5_2_len = G_N_ELEMENTS(hw_compat_5_2);
>  
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 3963b73520..b7ff3a9747 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -775,7 +775,7 @@ static const VMStateDescription vmstate_ich9_lpc = {
>  
>  static Property ich9_lpc_properties[] = {
>      DEFINE_PROP_BOOL("noreboot", ICH9LPCState, pin_strap.spkr_hi, true),
> -    DEFINE_PROP_BOOL("smm-compat", ICH9LPCState, pm.smm_compat, false),
> +    DEFINE_PROP_BOOL("smm-compat", ICH9LPCState, pm.smm_compat, true),
>      DEFINE_PROP_BIT64("x-smi-broadcast", ICH9LPCState, smi_host_features,
>                        ICH9_LPC_SMI_F_BROADCAST_BIT, true),
>      DEFINE_PROP_BIT64("x-smi-cpu-hotplug", ICH9LPCState, smi_host_features,

Re: Windows 10 won't run on default x86_64 machine anymore

[Daniel P. Berrangé]

On Tue, Mar 16, 2021 at 01:33:54PM +0100, Igor Mammedov wrote:
> On Mon, 15 Mar 2021 15:05:26 -0700
> Isaku Yamahata <isaku.yamahata@gmail.com> wrote:
> 
> > On Mon, Mar 15, 2021 at 05:58:04PM +0100,
> > Reinoud Zandijk <reinoud@NetBSD.org> wrote:
> > 
> > > I think its better to revert this and fix Linux ;) or make it a selectable
> > > feature as a workaround that's by default OFF :)  
> > 
> > Anyway here is a patch to flip the default.
> > At the moment, this is compile-only tested to provide the change quickly
> > and make discussion progress.
> > 
> > From 50deeed38832ceccfb68f78dd66de5a1741b2897 Mon Sep 17 00:00:00 2001
> > Message-Id: <50deeed38832ceccfb68f78dd66de5a1741b2897.1615845421.git.isaku.yamahata@intel.com>
> > From: Isaku Yamahata <isaku.yamahata@intel.com>
> > Date: Mon, 15 Mar 2021 14:42:33 -0700
> > Subject: [PATCH] ich9, piix4: flip default value for smm-compat
> > 
> > Make default value for smm-compat of ich9, piix4 true to keep old
> > behavior.
> > To get new (and more conformance to ACPI spec) behavior, explicitly
> > set "-global ICH9-LPC.smm-compat=off" or
> > "-global PIIX4_PM.smm-compat=off".
> 
> I'm not sure we should do that,
> it's fine for non-versioned/new machine type to change in incompatible way with old images,
> it's the job of old versioned machines types to maintain compatibility.
> It's of cause pain for users if they use are unable to boot old image
> on newest machine type, but we never promised that and if we made such
> promise we would never be able to fix bugs.

If this incompatibility with Windows 10 is confirmed though, I don't
think it is viable for QEMU to ship the default machine type with
settings that break Windows 10.




Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Windows 10 won't run on default x86_64 machine anymore

[Igor Mammedov]

On Tue, 16 Mar 2021 12:40:28 +0000
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Tue, Mar 16, 2021 at 01:33:54PM +0100, Igor Mammedov wrote:
> > On Mon, 15 Mar 2021 15:05:26 -0700
> > Isaku Yamahata <isaku.yamahata@gmail.com> wrote:
> >   
> > > On Mon, Mar 15, 2021 at 05:58:04PM +0100,
> > > Reinoud Zandijk <reinoud@NetBSD.org> wrote:
> > >   
> > > > I think its better to revert this and fix Linux ;) or make it a selectable
> > > > feature as a workaround that's by default OFF :)    
> > > 
> > > Anyway here is a patch to flip the default.
> > > At the moment, this is compile-only tested to provide the change quickly
> > > and make discussion progress.
> > > 
> > > From 50deeed38832ceccfb68f78dd66de5a1741b2897 Mon Sep 17 00:00:00 2001
> > > Message-Id: <50deeed38832ceccfb68f78dd66de5a1741b2897.1615845421.git.isaku.yamahata@intel.com>
> > > From: Isaku Yamahata <isaku.yamahata@intel.com>
> > > Date: Mon, 15 Mar 2021 14:42:33 -0700
> > > Subject: [PATCH] ich9, piix4: flip default value for smm-compat
> > > 
> > > Make default value for smm-compat of ich9, piix4 true to keep old
> > > behavior.
> > > To get new (and more conformance to ACPI spec) behavior, explicitly
> > > set "-global ICH9-LPC.smm-compat=off" or
> > > "-global PIIX4_PM.smm-compat=off".  
> > 
> > I'm not sure we should do that,
> > it's fine for non-versioned/new machine type to change in incompatible way with old images,
> > it's the job of old versioned machines types to maintain compatibility.
> > It's of cause pain for users if they use are unable to boot old image
> > on newest machine type, but we never promised that and if we made such
> > promise we would never be able to fix bugs.  
> 
> If this incompatibility with Windows 10 is confirmed though, I don't
> think it is viable for QEMU to ship the default machine type with
> settings that break Windows 10.

Choice is Windows vs Linux kernel
the later behaves correctly (as spec dictates) and 'offending' commit
fixes QEMU deviation from spec. It might be hard to convince kernel
side to merge a hack for Windows sake that goes against spec.
As for Windows, if new install works fine then that's all fine,
users really should use version-ed machine types or instead of
pushing old broken 'features' to [new] default machine types.

> 
> 
> 
> Regards,
> Daniel