Re: [PATCH 04/17] hvmloader: add ACPI enabling for Q35

[Alexey G <x1917x@gmail.com>]

On Tue, 28 Apr 2026 12:48:23 +0200
Roger Pau Monné <roger.pau@citrix.com> wrote:
>On Fri, Mar 13, 2026 at 04:35:05PM +0000, Thierry Escande wrote:
>> In order to turn on ACPI for OS, we need to write a chipset-specific
>> value to SMI_CMD register (sort of imitation of the APM->ACPI switch
>> on real systems). Modify acpi_enable_sci() function to support both
>> i440 and Q35 emulation.
>> 
>> Signed-off-by: Alexey Gerasimenko <x1917x@gmail.com>
>> Signed-off-by: Thierry Escande <thierry.escande@vates.tech>
>
>Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>
>It's not great to add more stuff into hvmloader when we want to move
>out of it, but it's also not helpful to tie the Q35 addition to the
>removal of hvmloader.

I'm afraid the only option to get rid of hvmloader is to move its
responsibilities back into the firmware (SeaBIOS/OVMF). But if I
understand it right, the whole idea of introducing hvmloader originally
was to delegate Xen-specific parts of HVM guest initialization from
firmware to a component managed by Xen itself.

So, to some extent hvmloader can be considered as a part of the firmware
itself as it does things like PCI BAR allocation etc which are normally
done by the guest firmware, but with more knowledge of Xen specifics.

I guess this hvmloader/firmware split model was introduced to have more
freedom/maintainability/control - I suppose it's much faster and easier
to integrate Xen-specific changes to hvmloader directly then to
upstream them to SeaBIOS/OVMF codebases.

But other than moving hvmloader's responsibilities to the firmware we
can't do much I think - HVM guests expect to have full freedom over the
emulated platform. Among problems are non-standard (chipset-specific)
devices which also need to have assigned resources like MMIO ranges -
and Xen doesn't know anything about these devices and their resource
requirements (left alone how to configure them), yet they still need to
have correct BARs assigned with no conflicts with other PCI devices and
to contribute to MMIO hole sizing. This is something which cannot be
solved on the toolstack level unless Xen emulates the whole chipset and
knows about all emulated chipset devices - we limit ourselves to
MMCONFIG now but there are more configurable ranges like this.