|
From: | Sebastian Herbszt |
Subject: | Re: [Qemu-devel] Re: qdev property bug? |
Date: | Mon, 14 Dec 2009 22:36:31 +0100 |
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 rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB.
I don't know whether gpxe will actually reduce it's size as part of this process so it may not matter. After running the option roms init vector, the rom must be relocated into the option rom space though so even this technique is not a solution unless gpxe is able to discard a lot of bits it doesn't need.
gPXE supports DDIM.
Also, the comment about "wasting memory" not quite accurate. The memory region in question is only used for roms. If we didn't put roms there, it would go to waste.Some BIOSes I saw have an option not to use the first 1M for rom shadowing :). Seriously as you see we are already running out of that 1M.I think that's just the first phase of rom loading.
- Sebastian
[Prev in Thread] | Current Thread | [Next in Thread] |