Hi Heinrich,
On Sat, 10 Oct 2026 at 06:26, Heinrich Schuchardt
<[email protected]> wrote:
>
> On 10/9/26 09:26, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On 2026-10-07T19:09:05, Heinrich Schuchardt
> > <[email protected]> wrote:
> >
> >> Currently we only support reset but not poweroff on x86 QEMU.
> >
> > I agree with where you and Bin ended up: keep the existing x86_reset
> > driver so efi_reset_system() keeps working. But I think we can go
> > further and avoid a new driver entirely. The existing driver already
> > handles SYSRESET_POWER_OFF: pch_sysreset_power_off() asks the PCH for
> > its PM-block layout with PCH_REQ_PMBASE_INFO and writes SLP_TYP_S5 /
> > SLP_EN itself. The QEMU devicetrees already have PCH nodes
> > ('intel,pch7' on i440fx, 'intel,pch9' on q35), but neither pch7.c nor
> > pch9.c implements that ioctl, so the request fails today. If those
> > drivers (or QEMU-specific variants) returned the PM base and offsets,
> > poweroff would work through the existing path. That needs no new
> > driver, compatible strings, undocumented 'intel,*' properties, DT
> > nodes or 'imply SYSRESET_X86 if !QEMU' change, and the EFI reset path
> > stays as it is.
> >
> > What do you think?
> >
> > Since this is a user-visible feature, please can you also update
> > doc/board/emulation/qemu-x86.rst to say that poweroff is supported?
> > Please also add a test if possible, e.g. a pytest that runs poweroff
> > on qemu-x86 in CI.
> >
> > Regards,
> > Simon
>
> Using the pch7 or pch9 drivers would make sense.
>
> Where would the following have to be done?
>
> /* Map the target ACPI base window using DM PCI config write */
> dm_pci_write_config32(pci_bridge_dev, plat->pmbase_reg,
> plat->pmbase_val);
>
> /* Enable the hardware bridge routing decoder switch via DM */
> dm_pci_write_config8(pci_bridge_dev, plat->pcicnt_reg,
> plat->pcicnt_val);
>
> In misc_init_r()?
> This function is implemented in arch/x86/cpu/x86_64/misc.c and does nothing.
> But shouldn't it be board specific?
That part already exists. qemu_chipset_init() in
arch/x86/cpu/qemu/qemu.c programs PMBASE to CONFIG_ACPI_PM1_BASE
(0xe400) for both i440fx and q35
But looking at it a bit more, pch7 and pch9 are shared with real x86
boards whose PM blocks are elsewhere. On i440fx the pch7 node is also
the PIIX3 ISA bridge at 00:01.0, while the PM registers are on
00:01.3. QEMU uses none of the pch7/pch9 ops, so I think a small
UCLASS_PCH driver in arch/x86/cpu/qemu/ would be better - match a
“qemu,pch” compatible and implement only PCH_REQ_PMBASE_INFO,
returning CONFIG_ACPI_PM1_BASE with PM1_STS at 0 and PM1_CNT at 4.
With the x86 code we tried to make it general so the same operations
could work on different hardware (particularly SPI flash).
BTW Claude took at look at the code and found two bugs in
pch_sysreset_power_off(): It uses inl()/outl() on PM1_CNT. QEMU only
accepts 8/16-bit access to PM1_STS and PM1_CNT, which are 2-byte
registers in the ACPI spec, so the write is silently dropped.
inw()/outw() works on both QEMU and Intel hardware.
‘reg32 |= SLP_TYP_S5’ sets bits 0-2 rather than SLP_TYP (bits 10-12),
so SLP_TYP stays 0. QEMU powers off only for SLP_TYP 0 (its _S5 is {0,
0, 0, 0}) and ignores 7, so fixing the shift alone would break QEMU. I
suggest adding a slp_typ_s5 field to struct pch_pmbase_info:
SLP_TYP_S5 for broadwell/ivybridge and 0 for QEMU.
With those changes, plus CONFIG_CMD_POWEROFF and
CONFIG_SYSRESET_CMD_POWEROFF, ‘poweroff’ exits QEMU on both -M pc and
-M q35 -- I have a rough prototype if it helps. Also note that
efi_reset_system() in sysreset_x86.c still has a TODO for
EFI_RESET_SHUTDOWN
Also whatever you do, please update doc/board/emulation/qemu-x86.rst
and ideally add a pytest which checks that QEMU exits.
Regards,
Simon
