[Top][All Lists]

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

Re: [Qemu-arm] [Qemu-devel] [RFC PATCH v1 4/4] target-arm: Compute page

From: Vijay Kilari
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC PATCH v1 4/4] target-arm: Compute page size based on ARM target cpu type
Date: Fri, 17 Jun 2016 16:09:42 +0530

On Fri, Jun 17, 2016 at 4:00 PM, Peter Maydell <address@hidden> wrote:
> On 17 June 2016 at 11:20, Vijay Kilari <address@hidden> wrote:
>> On Fri, Jun 17, 2016 at 1:12 AM, Richard Henderson <address@hidden> wrote:
>>> On 06/14/2016 04:36 AM, Peter Maydell wrote:
>>>> It would be better to delay the point at which we allocate
>>>> the data structures which care about page size, rather than
>>>> moving init of the CPU earlier.
>>> It would be *best* if we could re-initialize and re-allocate these data
>>> structures so that we can follow the current page size as it changes.
>>> Yes, this might require flushing just about everything, but it's the kind of
>>> thing that's likely to happen only at system startup.  After that, 
>>> everything
>>> benefits from having the correct (larger) page size.
>> I tried shuffling the memory initialization code after cpu initialization.
>> but it was full mess. So could not proceed further.
>> However, I tried early creation cpu objects instead of doing it from
>> machvirt_init.
>> With this, initfn of the cpu model is called earlier and feature set is 
>> updated.
>> With that I could fetch arm architecture info. Based on this we can
>> choose page size.
> This won't work, because machvirt_init needs to be able to specify
> properties of the CPU. I think we need to solve the issues with
> dynamically reinitializing and reallocating the data structures,
> as rth suggests.

In early init, only cpu object is created and does not specify
properties of the CPU.
machvirt_init will reuse already created cpu object and specify
properties of the CPU.


reply via email to

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