1 files changed, 88 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1030807 b/results/classifier/118/graphic/1030807
new file mode 100644
index 000000000..59105c4a9
--- /dev/null
+++ b/results/classifier/118/graphic/1030807
@@ -0,0 +1,88 @@
+graphic: 0.894
+peripherals: 0.812
+register: 0.802
+kernel: 0.800
+arm: 0.777
+user-level: 0.769
+socket: 0.766
+architecture: 0.764
+files: 0.758
+device: 0.757
+permissions: 0.754
+network: 0.753
+hypervisor: 0.736
+virtual: 0.730
+performance: 0.721
+semantic: 0.719
+boot: 0.715
+ppc: 0.712
+mistranslation: 0.709
+assembly: 0.699
+PID: 0.690
+debug: 0.685
+TCG: 0.640
+vnc: 0.627
+risc-v: 0.612
+KVM: 0.571
+x86: 0.566
+VMM: 0.538
+i386: 0.463
+
+PCI host bridge should ignore 1- and 2-byte I/O accesses
+
+In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO.
+According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes.
+
+> Anytime a host bridge sees a full DWORD I/O write from the host to
+> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS
+> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the
+> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD)
+> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on
+> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the
+> given address. I/O devices that share the same address but use BYTE or WORD registers
+> are not affected because their transactions will pass through the host bridge unchanged.
+
+In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space.
+
+have a look at:
+http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c
+
+In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored.
+On qemu line 962 will not be ignored and the test in line 963 will fail.
+The plan9 kernel will fall back to Mode2 which does not work.
+The result is that the guest will not see any PCI devices.
+
+I do not really have an image that you guys could quickly check this with, but i could prepare one if need be.
+An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void).
+
+> outl(0x80000000, 0xCF8);
++ outb0x01, 0xcfb);
+> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) {
+
+I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu.
+
+I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information.
+
+I tried the following quick fix but the BIOS does not seem to like that.
+
+
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+Cc'ing Julia (can't find her on Launchpad) because this looks
+similar to a bug she has been tracking.
+
+On 8/7/20 10:08 AM, Thomas Huth wrote:
+> Looking through old bug tickets... is this still an issue with the
+> latest version of QEMU? Or could we close this ticket nowadays?
+> 
+> 
+> ** Changed in: qemu
+>        Status: New => Incomplete
+> 
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+