qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise ma


From: Laszlo Ersek
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Fri, 3 Aug 2018 16:50:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 08/03/18 16:39, Andrew Jones wrote:
> On Fri, Aug 03, 2018 at 03:44:21PM +0200, Laszlo Ersek wrote:

>> In my earlier email
>>
>>   dynamic DRAM base for ArmVirtQemu
>>   http://mid.mail-archive.com/address@hidden
>>
>> I investigated what it would take to adapt this SEC driver,
>> "ArmPlatformPkg/PrePeiCore" (and other drivers that depend on it, and
>> run from pflash) to a dynamic RAM base.
>>
>> First of all, the driver would have to be cloned from ArmPlatformPkg to
>> ArmVirtPkg (becasue we shouldn't / can't modify ArmPlatformPkg for this
>> paravirt feature). Then all the changes should occur under ArmVirtPkg.
>>
>> Those would begin with replacing the fixed PcdCPUCoresStackBase (i.e.,
>> the location of the stack, which is the only writeable thing we start
>> out with) with calculating (and passing around) a stack base derived
>> from the initial x0 value. (This is bullet (1) in my above email.)
> 
> I'm actually attacking it without a stack. x0 will have the address of
> the DTB, which may or may not also be the base address of main memory.
> There's no need to code to the assumption it is in order to have a
> stack. The code to parse the DT can all be done in assembler without
> a stack.

That sounds very cunning :)

But, a stack will certainly be needed by the rest of the code, so even
if the DTB parsing itself needs no stack, later (but still early)
dependencies on PcdCPUCoresStackBase (and friends) will have to be replaced.

>> IOW, the cornerstone of this feature is to replace all constants
>> (FixedPCDs and otherwise) related to the RAM Base with values
>> dynamically calculated from the initial x0 value. My earlier email
>> details this as well -- at the earliest, the results can only be passed
>> around on the (dynamically configured) stack itself; a bit later, PPIs
>> (= structures identified by particular GUIDs, located originally in
>> temporary SEC/PEI RAM) can be used too. But, there's nothing ArmVirtQemu
>> can "patch" the way ArmVirtQemuKernel and ArmVirtXen do.
> 
> I need to digest this more, too, and to modify it to use the actual base
> of memory found in the DT, rather then value of x0, which may or may
> not be the same value.

Good point!

Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]