[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: Peter Maydell
Subject: Re: [Qemu-devel] [RFC PATCH 00/34] Multi Architecture System Emulation
Date: Mon, 11 May 2015 09:52:10 +0100

On 11 May 2015 at 09:21, Peter Crosthwaite <address@hidden> wrote:
> On Mon, May 11, 2015 at 12:13 AM, Peter Maydell
> <address@hidden> wrote:
>> Do you give each CPU its own codegen buffer? (I'm thinking that some
>> of this might also be more easily done once multithreadded-TCG is
>> complete, since that will properly split the datastructures.)
> No, the approach taken here is everything is exactly the same as
> existing SMP. My logic is we already have the core support in that
> AArch64 SMP lets us runtime mix-and-match arches. E.g. there's nothing
> stopping the bootloader putting one core in AA32 and the other in 64
> leading to basically multi-arch. I just extend that to cross
> target-foo boundaries with some code re-arrangement.

This works for AArch32+AArch64 because the target-arm frontend
puts "is this CPU in AArch64?" in the TB flags, so the hash
lookup can never return an AArch64 translated TB for a CPU
that's in AArch32 state. For two separate front-ends there's
no guarantee that the (physaddr+vaddr+TB flags) lookup won't
produce false matches between the two CPUs.

For this to work with multiple different frontends you'd either
need to add the CPU architecture to the set of checks made in
TB lookup, or just provide separate codegen buffers. Waiting
for multithreaded-TCG to provide the latter may be the simplest

-- PMM

reply via email to

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