On 01/28/14 19:28, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
> walk into mine at 04:07:29 on Tuesday 28 January 2014 and say:
I think I've never tried gin. I like beer and various liqueurs. Based on
the wikipedia entry for gin, I'm adding gin to my TODO list. Thanks.
>> On 01/27/14 23:01, Bill Paul wrote:
>> Placing this string of areas at 0x800000 is quite arbitrary for us, as
>> far as I know. I believe (without doing any investigation) that we could
>> move it a bit around, but it must stay low. The decompression happens at
>> an early stage.
>
> Can't you move it after decompression?
IMO it wouldn't be too practical. By the time we could conveniently move
it around, we'd be *running* from it already. So if we end up putting it
elsewhere, we should do that off the bat.
Of course Jordan might have a different opinion.
>> Why does it bother you where it is right now? What conflict do you see?
>
> What I'm doing is running VxWorks in QEMU for testing purposes. Using QEMU
> and
> OVMF has proven to be an excellent way to experiment with booting VxWorks
> with
> UEFI before moving to real hardware.
Awesome! It's one of the (semi-)stated goals with OVMF in my
understanding (ie. support development of runtime OS's UEFI-related
parts), and it's nice to see OVMF being put to use.
> The problem I'm having has to do with VxWorks' memory management. Due to
> hysterical raisins, when the VxWorks kernel starts up, it expects to be given
> a contiguous chunk of memory to use as its initial heap memory pool. Once the
> kernel is running you can add additional chunks -- these are called memory
> partitions by the memory manager.
>
> The thing is, on the Intel arch, it's always been assumed that that the first
> chunk of usable memory starts at 0x100000 and is fairly large. With the
> memory
> hole created by the PEIFV block, you end up with only about 7MB in this
> block,
> which is too small. (The real havoc occurs with 64-bit VxWorks, which has
> additional restrictions.)
I hope you too perceive how hilarious this is :) The reasons you listed
for VxWorks mostly hold for OVMF too (= "we're just starting so let's
stick with something very low until we know more about the system").
How large a contiguous range would you need from 1MB upwards? (Because
the address that we'd shift this up to would likely directly impact the
minimum qemu guest memory requirements.)
> It is possible to tweak things in VxWorks to avoid this problem, but it's a
> pain. It's also not something we typically encounter on real hardware.
I don't think we'd like to hard-wire a *very* different base address
statically. Maybe we could add a build option, but that only moves the
pain around.
Re it being different from real hardware, the explanation is that most
of OVMF's modules are stored compressed in the flash, and are
decompressed to (and then run from) RAM at startup. I assume on real
hardware the firmware simply runs from flash. (Hm, I guess it could be
shadowed into RAM too, but I have no data about what addresses.)
>> Additionally, after the full S3 support series committed, further code
>> will be added to honor the case when the user disables S3 on the qemu
>> command line ("-global PIIX4_PM.disable_s3=1"). Then the memory
>> allocation in question will be qualified as Boot Services Data (rather
>> than ACPI NVS), and the OS will be able to drop it after transitioning
>> to runtime.
>
> It appears I need a newer version of QEMU for that option:
>
> root@core:/home/wpaul/ovmf # qemu-system-x86_64 -global PIIX4_PM.disable_s3=1
> qemu-system-x86_64: Property '.disable_s3' not found
Correct. This property was added in
commit 459ae5ea5ad682c2b3220beb244d4102c1a4e332
Author: Gleb Natapov <g...@redhat.com>
Date: Mon Jun 4 14:31:55 2012 +0300
Add PIIX4 properties to control PM system states.
first released in v1.2.0.
I searched the FreeBSD ports repo for qemu, and it seems that the
"qemu-devel" package is at 1.7.0. (Not sure if you can easily get it in
9.1-RELEASE.)
> That aside, this would be an acceptable compromise, at least until VxWorks
> supports S3 resume on the Intel architecture. :)
>
> I still think the placement of the PEIFV block is much less than ideal, but
> for the time being I can deal with it.
Alternatively, please propose the lowest address that would work out of
the box for your use case, and then Jordan could decide if it was
reasonable to re-wire the FDFs with that address.
Thanks!
Laszlo
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
