On Friday 19 June 2009 21:44:40 Alex Williamson wrote: > On Fri, 2009-06-19 at 15:27 +0800, Yang, Sheng wrote: > > On Friday 19 June 2009 00:28:41 Alex Williamson wrote: > > > 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, > > > > That should be fine. I've taken a look at code, seems Linux kernel set > > enable_bit when someone begin to read rom, and copy rom to buffer, then > > unmap the rom. So the rom can be read when enable bit clear. > > For this testing, I used an mmap of the ROM address though, so the > kernel caching shouldn't have been involved. It looks to me like the > problem is that the map function provided via pci_register_io_region() > only knows how to create mappings, not tear them down. I think maybe > pci_update_mappings() should still call the map_func when new_addr is -1 > to let the io space drive shutdown the mapping. As it is, once we setup > the mapping, it lives until something else happens to overlap it, > regardless of the state of the PCI BAR. Thanks, I think it may not necessary to tear them down, for the bar mapping won't change IIUR. And you are accessing the sysfs file, right? In the Linux kernel, IIRC, pci_create_sysfs_dev_files() create sysfs file, and hook the read to pci_read_rom(), which called pci_map_rom(), which would call pci_enable_rom(), and write the enable_rom bit to the rom_base_reg. So that the rom can be read regardless of enable_rom bit state - and . But I also found something interested. The write hook of file, pci_write_rom() seems won't cause NMI(and seems you need write a char rather than 0 to enable the accessing?). So why NMI happen in host?... -- regards Yang, Sheng -- 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
