On real hardware especially server platforms, there might be multiple
root buses, thus pci bus number could run up to 255. This patch fixed
pci_probe_devices() by allowing to scan all 256 pci bus numbers(0-255).
Signed-off-by: Bin Gao <gaobin(a)amazon.com>
---
src/hw/pcidevice.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c
index 8853cf7..8d9c401 100644
--- a/src/hw/pcidevice.c
+++ b/src/hw/pcidevice.c
@@ -26,6 +26,14 @@ pci_probe_devices(void)
struct hlist_node **pprev = &PCIDevices.first;
int extraroots = romfile_loadint("etc/extra-pci-roots", 0);
int bus = -1, lastbus = 0, rootbuses = 0, count=0;
+
+ // There might be multiple PCI root buses on physical hardware especially
+ // server platforms, thus bus number could run up to the top value,
+ // i.e. 0xff. Setting extraroots to 0xff to ensure we can enumerate all
+ // PCI bus numbers.
+ if (CONFIG_CSM)
+ extraroots = 0xff;
+
while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) {
bus++;
int bdf;
--
2.17.1
Hello,
Host : centos 7
Guest : Concurrent DOS 386 v3.00 (problem also happen on DOS 3.0)
QEMU : v5.1.0
Virtualbox : v6.1.14
Seabios : seabios-rel-1.13.0
I first started to run some tests to debug the alt-gr behavior, and I ended up noticing something strange.
This issue is the same as this one: https://bugs.launchpad.net/qemu/+bug/1574246
So I have an old computer with CDOS installed directly on it (i486-DX2 processeur), and I have to virtualize it with QEMU. Lets call this computer “antique”.
When I run the command ‘n’ in cdos, I select French and I install AZERTY 102 keys 8 bit keyboard.
Then when i press alt-gr + 3, on antique and vbox it display ‘#’, but on QEMU ,it doesn’t, it print the gibberish ^@ sequence.
So VBox handle keyboard input properly, but not qemu.
I investigated to see if the problem was how QEMU interpret the alt-gr, and I thought it was, because the flags set in registers AH and AL when I press alt-gr are the same as when I press Alt (AH=0x2, AL=0x8) according to this site:
http://helppc.netcore2k.net/table/bda : AH – 40:18 AL – 40:17
So I launched qemu and vbox in debug mode, with gdb for qemu and the included debbuger for vbox. By breaking on 0xF000:0xFFF0 and inspecting the IVT, I could see that CDOS replaces the IRQ handler because the address stored at 0x24 (irq 9) change after I resume execution, and when I inspect the machine code at 0xAF:0x618 (address of the IRQ 9 stored in 0x24 after cdos has started), it’s the same on qemu and vbox.
The behavior and scancodes received are the same on QEMU and VBox in the CDOS irq 1 handler. I break on the respective BIOS irq 1 handler, called from the CDOS irq 1 handler, and at this point the byte read on 0x60 differs. Exemple for alt-gr, so 0xE038:
* …
* %000000000000113f e4 60 in AL, 060h // CDOS read 0xE0 from port 0x60
* …
* CDOS call bios handler
* …
* %00000000000fe987 e4 60 in AL, 060h // VBOX bios read 0xE0, QEMU bios read 0x38
* …
I didn’t see any command from CDOS irq 1 handler that would tell the PS2 controller to refeed the last byte read on the port 0x60, and all the BIOS does before the read is to deactivate the keyboard by writing 0xAD to port 0x64, so I think the issue could be from how the ps2 controller is emulated on QEMU. Somehow, VBOX knows that it has to keep the value in it’s output buffer after the first read, or maybe some kind of timer, idk.
I join to this mail the asm of the CDOS irq 1 handler that I extracted from the debugger.
If someone could help me to create a fix, even not official, that we could use on our project.
Thanks a lot.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
