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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, May 05, 2026 at 03:58:16PM +0200, Alexey G wrote:
> On Tue, 28 Apr 2026 12:48:23 +0200
> Roger Pau Monné <roger.pau@xxxxxxxxxx> 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@xxxxxxxxx>
> >> Signed-off-by: Thierry Escande <thierry.escande@xxxxxxxxxx>
> >
> >Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> >
> >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.

Maybe originally?  We then ended up having to add all sorts of Xen
specific logic into both SeaBIOS and OVMF, so much to OVMF that
there's a Xen-specific target/platform in OVMF.

> 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.

Faster to integrate possibly, but then we end up with IMO a lot of
duplication between what hvmloader does vs what we could offload to
OVMF.

> 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.

I think we do want to move a lot of hvmloader responsibilities into
OVMF (maybe SeaBIOS if possible also, albeit that's a legacy firmware
by today standards anyway).  Whether we would need to partially
offload some of what hvmloader does into the toolstack remains to be
seen.

Chipset initialization would possibly need to be done by OVMF, at
which point we might require PVH guests that want to use PCI
passthrough to also rely on OVMF instead of direct kernel boot.
Anyway, this is quite distant future.

Thanks, Roger.