On Thu, 2009-06-18 at 13:30 +0800, Yang, Sheng wrote: > On Tuesday 16 June 2009 00:29:17 Alex Williamson wrote: > > The PCI code already knows about option ROMs, so we just need to > > mmap some space for it, load it with a copy of the contents, and > > complete the plubming to the generic code. > > > > With this a Linux guest can get access to the ROM contents via > > /sys/bus/pci/devices/<dev>/rom. This might also enable the BIOS > > to execute ROMs by loading them dynamically from the device > > rather than hoping they all fit into RAM. > > > The patch looks fine. One question: if guest write to the ROM, I think the > guest would be killed for QEmu would receive a SIGSEGV? I am not sure if it's > too severe... Hi Sheng, Good thought. I tested this with a simple program that mmaps the ROM address from /dev/mem and tries to write to it (using setpci to enable the ROM). The results are a little surprising. On the host, writing to the ROM causes an NMI and the system dies. On the KVM guest, the write is happily discarded, neither segfaulting from the mprotect nor affecting the contents of the ROM. So it seems that something above my mprotect is discarding the write, and if we did hit it, a qemu segfault isn't that far from what happens on bare metal. The one oddity I noticed is that even when the enable bit is clear, the guest can read the ROM. I don't know that this is actually illegal, vs returning zeros or ones though. It seems like maybe the generic PCI code isn't tracking the enable bit. I think that's an independent problem from this patch though. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
