On 27/3/24 14:09, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000
Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100
Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since
such machine was around with real ISA only PC hardware practically
defunct.
Also it's slowly bit-rots (for example: I was able to boot RHEL6 on
RHEL9 host
in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old /
defunct hardware. I'm pretty sure Bernhard and myself are OK to
keep maintaining it, besides we are working in separating it from
the i440fx+piix machine. Also, this machine is particularly
interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every
case where ISAPC related code gets in a way, nor it's fair to
ask other contributors to ensure that their patches don't break
semi-working ISAPC or refactor code that relates to it.
[
for example I'd like to refactor smbios parts in the image
ACPI table builder, but the I'd have to do it for legacy
part as well without means to verify that. Sure it can be
done but at cost of extra time spent to rewrite something
that would never be used and to find test env to verify
touched code.
]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec
is from 1999, while PCI has been around since 1992.
Theoretically SMBIOS can still be used with isapc,
(that's how I've tested factoring out legacy part by running
RHEL6 in TCG mode)
Whether it's used in practice somewhere else is unknown.
IOW, we shouldn't even be exposing SMBIOS with the isapc
machine type. If we address that, then isapc has no impact
on your ability to refactor SMBIOS code.
It's question of whether we are willing to do unthinkable,
i.e. to break QEMU <-> guest ABI for isapc case by removing
corresponding fwcfg entries.
With migration ignored it shouldn't be a problem.
Question is: does anyone care about migration with isapc?
If not, I'd gladly axe smbios legacy parts in 9.1
But given how easy one can spawn old qemu environment to
run something on isapc, we are loosing a chance to cleanup
QEMU code base touching following
m->option_rom_has_mr = true;
m->rom_file_has_mr = false;
pcmc->pci_enabled = false;
pcmc->has_acpi_build = false;
pcmc->smbios_defaults = false;
pcmc->gigabyte_align = false;
pcmc->smbios_legacy_mode = true;
My plan is to split the legacy part of fw_cfg_build_smbios() out
of it as fw_cfg_build_smbios_legacy().
pcmc->has_reserved_memory = false;
they are all marginal but in shared code, and removing them
makes code a bit more easier to follow (especially when it
comes to memory layout).
With regards,
Daniel
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
