Il 22/03/2013 17:09, Laszlo Ersek ha scritto: > I'm confused. What are the requirements? > > (1) should unpatched qemu work with patched seabios?
Yes. > (2) should patched qemu work with unpatched seabios? No. > Considering patched qemu + patched seabios, > (3) should qemu dynamically control table origin/contents per table? Not sure I understand this? > (4) should qemu be able to suppress/disable a seabios table via fw_cfg > without providing a replacement? QEMU should be able to suppress all SeaBIOS tables except for the four tables you identified. Once the transition is done, a special fw_cfg file (or alternatively a SeaBIOS/OVMF patch) would direct SeaBIOS to not create _any_ ACPI table except those four. > I had thought: > (1) yes (firmware upgrade on same hardware), > (2) no (hardware upgrade), > (3) yes (eases development and ultimately covers everything), > (4) no (*) Three out of four, you're probably right on (3) too. :) Paolo > but apparently I'm wrong. I'm ready to be enlightened and try to > implement whatever the consensus is, but what is the consensus? > > (*) For each table we can investigate why SeaBIOS provides it now: > > - RSDP, RSDT, XSDT: These look like links-only tables. In general, links > (pointers) have to be updated by the firmware (eg. in the FADT), thus > qemu would provide zeros in those fields in general. Since these three > tables consist of nothing more than pointers, qemu would never provide > any of these tables. Choice between RSDT and XSDT is the jurisdiction of > the boot firmware, and it should choose exactly one. (SeaBIOS currently > uses RSDT, OVMF uses XSDT.) > > - FADT (FACP): required by the spec. Qemu would either put up with > SeaBIOS's or provide a replacement. > > - FACS: always prepared by the boot firmware. > > - DSDT: Same as FADT. > > - SSDT: a continuation of the DSDT; there can be several instances. If > the DSDT comes from qemu, SeaBIOS shouldn't install any SSDTs of its > own. Qemu won't provide SSDTs without its own DSDT. > > - APIC (MADT): required in the "APIC interrupt model", which is probably > "always" for us. Hence same as with FADT/DSDT. > > - HPET: Hardware dependent. If qemu doesn't provide the hardware, it > also wouldn't provide the table, and SeaBIOS already doesn't install one > itself because there's no hardware. If the hardware is there, qemu > provides the table, or puts up with SeaBIOS's. > > - SRAT: Dependent on NUMA setup. Same case as with HPET. > > - MCFG: Seems to depend on hardware (q35). Same as with HPET. > > (I'll be out of the office next week -- if I don't follow up, that's the > reason.) > > Thanks > Laszlo > >
