On Thu, Oct 16, 2008 at 3:28 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Think of point 1-4 as one "atomic" operation. pci_conf1_read_config32 does not call any other function, so simply unshare that and be happy.
it's worse than that. We found when doing this years ago that some nvidia vga bios'en don't call pcibios. They just set config space. But they might do INT10 for other reasons. The general case is that a vga bios might do something in config space that maps out ROM, since they "know" that there is no issue, and then do an INT 10, and if that happens, no code can be in rom -- including printk.
After the things I've seen, up to and including self-modifying code, I am not willing to trust a VGA bios not to do something really foolish.
So here's another option. We've always run out of high memory. But v3 has this nice 32-bit address space, and the ability to call rom, but most of it runs out of ram now. coreboot ROM segment is now 20K or less.
Why not just run the ROM section of coreboot in the F segment? What would that harm?
If we do this, the problem goes away.
I'm not completely getting this. Do we run the binary blob from inside coreboot or does SeaBIOS perform that task?
coreboot. vm86.
If coreboot does it, we have some trapping code for BIOS emulation anyway.
which is where the problem is.
ron