|
From: | Sebastian Herbszt |
Subject: | Re: [Qemu-devel] Re: qdev property bug? |
Date: | Mon, 14 Dec 2009 23:14:41 +0100 |
Anthony Liguori wrote:
Sebastian Herbszt wrote:Anthony Liguori wrote:Michael S. Tsirkin wrote:On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote:Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command.Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed.I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works.The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size.It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xDFFFF) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect romPMM doesn't have (anything?) to do with this and the rom doesn't have to be loadedoutside of 1MB.Well PMM is used to do the resizing.
You can shrink in-place with rom layout like [header, run-time code, init code]. The init code can then just be "truncated". You only need PMM if you can't manage with the allocated memory.
But it sounds like the problem is that we should not be loading the roms into the rom space. Instead, seabios should be mapping them into that space, running the rom init, then moving to the next one.I suspect we need to either need to implement the proper pci interface for seabios to do this or we need to provide a pv channel.
I suggested a proper pci interface before [1]; please no pv channel. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01823.html - Sebastian
[Prev in Thread] | Current Thread | [Next in Thread] |