[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] OVMF on PVH
On Thu, Aug 02, 2018 at 06:23:54AM -0600, Jan Beulich wrote: > >>> On 02.08.18 at 13:24, <anthony.perard@xxxxxxxxxx> wrote: > > ## Loading binary at 0x10000 (1MB, like hvmloader on HVM) > > > > Right now, the OVMF blob is loaded (by hvmloader) just below 4GB, with > > hvmloader moving some RAM around to allow that. But with the use of an > > ELF header, and let libxc load the blob, it was not possible to load the > > blob just below 4GB. (Or at least without modification of the toolstack I > > guess.) So I've attempted to have OVMF been started from a different place > > in memory. Then I had to hack a bit more in order to be able to start OVMF > > from two different location (the current one for HVM guest, and a new one > > that can be used for PVH). That works fine, I'll just have to find out > > what upstream think about that. > > I'm of two minds here - as a firmware binary, it doesn't seem to make > sense to load at 0x100000, yet as a hvmloader replacement it might. > However, parts of it will need to stay (runtime services code/data), > and such permanent data better lives at higher addresses imo. > > Jan On Thu, Aug 02, 2018 at 06:21:31PM +0200, Roger Pau Monné wrote: > That works well for hvmloader because after it has finished running > the memory can be overwritten without issues. The same is not true for > ovmf which needs to keep data around so that boot services and runtime > services can continue working. > > Thanks, Roger. So there is something to know about the way the OVMF blob (it's actually called flash device image, or FD), it that there is almost no text (code to execute). Most of the FD is compressed, with a small section (called SEC Phase modules) which takes care of bringing up the CPU from 16bits to 64bits, then some code to find where the next phase is and decompress the main module. I don't think any of the initial blob is kept around once the decompression is done. I did build my OVMF, and use the same exacte blob for both HVM and PVH, in HVM the blob would be loaded below 4G (no change), and for PVH it would be loaded at 1M. They both worked fine, so it doesn't really matter where the initial blob is. As for where the permanent data actually lives, I am not changing that. OVMF setup a lot of stuff between 0x800000-0x1400000 as this is where its page tables are initialy setup (I don't know if they move later), and all its code is. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |