Xenix is currently working (when copied from real hardware).
As well Interactive UNIX and some other non-DOS from 8086 and 286 era.
I'm not really sure that operating systems (specially the 8086 ones
that do mmu functions in software) will be happy with the PCI bus
present.
Same for first 386 operating systems (OS/2 2, UNIX, Xenix, so on).
I don't think it is so bad forking the BIOS, letting the ISA one only
for bug fixes, and the PCI one for new features.
Even the ISA BIOS can be code cleaned, there is no SMBIOS or ACPI in
ISA hardware.
Or, use bochs bios, that we know is working (at least for now) for
isapc, and seabios for pcipc.
There are a lot of ways to do that, but I think that simply forgetting
about isapc and deleting it is not a bugfix, but a big big bug.
El 09/02/2010, a las 21:05, Anthony Liguori escribió:
On 02/09/2010 02:36 PM, Natalia Portillo wrote:
There are operating systems that simple conflict with some
assumptions made by PCI architecture.
Rembember that the PC memory map changed to include the PCI
configuration space and so on, space that can be expected to
contain other data, or not at all, and could be used in ISA/EISA/
VLB/MCA systems by PCI-unaware operating systems or applications.
But practically speaking, given the devices that we emulate, is
there any workload that works with -M isapc but not -M pc?
Having to support an ISA and PCI system in the BIOS is a bit of a
burden. If we can eliminate that without regressing any guest
workloads, I think it would be a net win.
Regards,
Anthony Liguori
