qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [edk2] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU
Date: Wed, 20 Nov 2013 09:36:50 +0100

  Hi,

> > If you simply relax (drop) the stage-wise hole-setting, that will at
> > best create a situation where OVMF and qemu duplicate the logic. This
> > info needs to be passed down to OVMF (maybe it already is, somewhere in
> > fw_cfg!), in some form that's more approachable than an ACPI table. (We
> > absolutely don't want to parse ACPI (AML) in OVMF.)

No need to parse aml.  The acpi tables are not fixed, qemu tweaks them
according to the hardware programming done by the guest.

> Two possible fixes, both of them in QEMU:
> 1. declare all available regions (that resolve to PCI) in _CRS
> 2. detect where did guest put PCI devices and declare the result in _CRS
> 
> 2 is exactly what we did for 64 bit BARs.

Well, it's actually a mix, isn't it?  64bit window base address is
derived from guest pci bar mapping, 64bit window size is configurable to
leave room for hotplug (or maybe that is the future plan still ...).

I think we should simply declare end-of-lowram -> ioapic base as 32bit
window.  Looking at the pci bar locations programmed by the guest will
only make this smaller, leaving less space for hotplug, for no good
reason.

> The only issue I worry about is MTRRs.
> Maybe we are lucky and they do not matter for KVM.

I think they are largely cosmetic in virtual machines.  And if ovmf
wants use 0xa000000+ as pci io window it still has the option to create
two mtrr entries to cover the region (one 512m @ 0xa0000000 and one 1G @
0xc0000000).

cheers,
  Gerd





reply via email to

[Prev in Thread] Current Thread [Next in Thread]