All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey G <x1917x@gmail.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Thierry Escande <thierry.escande@vates.tech>,
	xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anthony PERARD <anthony.perard@vates.tech>
Subject: Re: [PATCH 07/17] hvmloader: add basic Q35 support
Date: Mon, 11 May 2026 01:32:52 +0200	[thread overview]
Message-ID: <20260511013252.326cd768@LinuxLaptop> (raw)
In-Reply-To: <afCy-IU85MdDBlUq@macbook.local>

On Tue, 28 Apr 2026 15:15:36 +0200
Roger Pau Monné <roger.pau@citrix.com> wrote:
>
>> +        pci_writel(devfn, 0x40, ACPI_PM1A_EVT_BLK_ADDRESS_V1 | 1);
>> +        pci_writeb(devfn, 0x44, 0x80); /* enable PM io space */
>> +        outl(SCI_EN_IOPORT, inl(SCI_EN_IOPORT) | GBL_SMI_EN | APMC_EN);
>
>Most of the above looks like black magic.  It's not like the context
>of this function is great, most of the existing stuff is poorly
>documented.  Can we get a bit more comments about what's this supposed
>to do, and maybe a reference to the Intel specification that lists
>where those PCI config space registers are coming from?

This is a precondition for the (later) switch to ACPI.

First, we set the ACPI I/O registers base - it can be absolutely
arbitrary but we choose the same value that was used before for PIIX4 -
ACPI_PM1A_EVT_BLK_ADDRESS_V1. The "| 1" part is likely NOT necessary
and should be removed unless QEMU has a bug with its handling -
according to Intel datasheet, bit0 is "Hardwired to 1 to indicate I/O
space", no need to set it explicitly.

At this point we can use ACPI I/O register block at
ACPI_PM1A_EVT_BLK_ADDRESS_V1. We are only interested in one register
from this range - at offset +30h. SCI_EN_IOPORT is a wrong name
actually, it should be renamed to SMI_EN_IOPORT.

Finally, the line
"outl(SCI_EN_IOPORT, inl(SCI_EN_IOPORT) | GBL_SMI_EN | APMC_EN)"
enables SMI generation - we will use it later to perform a classic
APM -> ACPI switch via a write to the APM_CNT (0B2h) register to
trigger an SW SMI, followed by validating SCI_EN=1 to confirm the
successful switch.

Basically, all this setup is just a preparation for the step done in
the next patch - "hvmloader: add ACPI enabling for Q35".

What I don't remember is who was actually responsible for actual ACPI
enabling - either QEMU or firmware.
On real systems it is a bit more complicated - the APM -> ACPI switch
is done by an ACPI-aware OS itself (OSPM, how they call it). The OS
extracts information from ACPI tables and use it to find out what and
where to write in order to switch to ACPI. Under the hood it's still a
special value written to the SW SMI register, triggering a SMI handler
in the firmware. The actual hand-off to ACPI was done by the SMI
handler, including switching the PM interrupt from SMI to ACPI's SCI.

I'm not sure why hvmloader does this switch early instead. But at least
this APM -> ACPI switch flow matches the older (PIIX4) one. Perhaps
this is how it was handled by QEMU.


  reply	other threads:[~2026-05-10 23:33 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 16:35 [PATCH 00/17] Q35 initial support for HVM guests Thierry Escande
2026-03-13 16:35 ` [PATCH 01/17] libacpi: Split dsdt.asl file and extract i440 specific parts Thierry Escande
2026-04-28  9:05   ` Roger Pau Monné
2026-05-04 14:34   ` Jan Beulich
2026-05-04 14:35     ` Jan Beulich
2026-03-13 16:35 ` [PATCH 06/17] hvmloader: Move pci devices setup to a separate function Thierry Escande
2026-04-28 12:48   ` Roger Pau Monné
2026-05-04 14:52   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 03/17] hvmloader: add function to set the emulated machine type (i440/Q35) Thierry Escande
2026-04-28 10:39   ` Roger Pau Monné
2026-05-04 10:58     ` Jan Beulich
2026-05-04 14:43   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 02/17] libacpi: new DSDT ACPI table for Q35 Thierry Escande
2026-04-28 10:17   ` Roger Pau Monné
2026-05-04 14:39   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 05/17] hvmloader: add Q35 DSDT table loading Thierry Escande
2026-04-28 11:08   ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 08/17] hvmloader: Extend PCI BAR struct Thierry Escande
2026-04-28 13:31   ` Roger Pau Monné
2026-05-04 15:01   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 10/17] hvmloader: Add support for HVMOP_set|get_ecam_space hypercalls Thierry Escande
2026-04-28 14:14   ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 07/17] hvmloader: add basic Q35 support Thierry Escande
2026-04-28 13:15   ` Roger Pau Monné
2026-05-10 23:32     ` Alexey G [this message]
2026-05-04 14:55   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 14/17] libacpi: build ACPI MCFG table if requested Thierry Escande
2026-04-29 10:13   ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 09/17] xev/hvm: Add HVMOP_get|set_ecam_space hypercalls Thierry Escande
2026-04-28 13:59   ` Roger Pau Monné
2026-05-04 11:09     ` Jan Beulich
2026-05-04 15:12   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 11/17] hvmloader: allocate MMCONFIG area in the MMIO hole Thierry Escande
2026-04-29  9:29   ` Roger Pau Monné
2026-05-04 11:11     ` Jan Beulich
2026-05-04 12:23       ` Roger Pau Monné
2026-05-04 12:36         ` Jan Beulich
2026-03-13 16:35 ` [PATCH 12/17] libxl: Q35 support (new option device_model_machine) Thierry Escande
2026-04-29 10:01   ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 13/17] libxl: Add xen-platform device for Q35 machine Thierry Escande
2026-03-13 16:35 ` [PATCH 15/17] hvmloader: Set MCFG in ACPI table Thierry Escande
2026-04-29 12:33   ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 04/17] hvmloader: add ACPI enabling for Q35 Thierry Escande
2026-04-28 10:48   ` Roger Pau Monné
2026-05-05 13:58     ` Alexey G
2026-05-05 14:25       ` Roger Pau Monné
2026-03-13 16:35 ` [PATCH 16/17] Handle PCIe ECAM space access from guests Thierry Escande
2026-04-29 12:42   ` Roger Pau Monné
2026-05-04 15:22   ` Jan Beulich
2026-03-13 16:35 ` [PATCH 17/17] docs: provide description for device_model_machine option Thierry Escande
2026-04-29 12:43   ` Roger Pau Monné
2026-03-15 22:43 ` [PATCH 00/17] Q35 initial support for HVM guests Alexey G
2026-04-28  7:48 ` Roger Pau Monné
2026-05-04 10:45   ` Jan Beulich
2026-05-05  5:48     ` Jan Beulich
2026-05-05  5:49       ` Jan Beulich
2026-05-05 13:29     ` Alexey G
2026-05-05 13:07   ` Alexey G
2026-05-05 14:15     ` Roger Pau Monné

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=20260511013252.326cd768@LinuxLaptop \
    --to=x1917x@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=thierry.escande@vates.tech \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.