[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH 00/34] Multi Architecture System Emulation

From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC PATCH 00/34] Multi Architecture System Emulation
Date: Mon, 11 May 2015 12:44:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Am 11.05.2015 um 10:21 schrieb Peter Crosthwaite:
> On Mon, May 11, 2015 at 12:13 AM, Peter Maydell
> <address@hidden> wrote:
>> On 11 May 2015 at 07:29, Peter Crosthwaite <address@hidden> wrote:
>>> The env as handle by common code now needs to architecture-agnostic. The
>>> MB and ARM envs are refactored to have CPU_COMMON as the first field(s)
>>> allowing QOM-style pointer casts to/from a generic env which contains only
>>> CPU_COMMON. Might need to lock down some struct packing for that but it
>>> works for me so far.
>> Have you managed to retain the "generated code passes around a pointer
>> to an env which starts with the CPU specific fields"? We have the env
>> structs the layout we do because it's a performance hit if the registers
>> aren't a short distance away from the pointer...
> OK, I knew there had to be a reason. So I guess the simplest
> alternative is pad the env out so the arch-specific env sections are
> the same length followed by a CPU_COMMON. A bit of union { struct {} }
> stuffs might just do the trick although there will be some earthworks
> on cpu.h.

Please keep in mind that the reason of the current CPUState layout is
(hopefully documented?) that we were allowing negative offsets for
common CPUState fields fields while retaining positive offsets for
CPUArchState fields. So you are free to move stuff from CPU_COMMON to
somewhere before env in CPUState.


SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)

reply via email to

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