qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 2/2] hw/integratorcp: Simplify flash remap co


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v4 2/2] hw/integratorcp: Simplify flash remap code
Date: Sun, 08 Jan 2012 13:16:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/07/2012 06:09 PM, Peter Maydell wrote:
> On 7 January 2012 04:40, Andreas Färber <address@hidden> wrote:
> > I noticed you're dropping a comment about tlb_flush(). Is that because
> > it was dead code, or does the Memory API take care of it for us?
> > (I assume the former because memory_region_set_enabled() does not take a
> > CPUState* to operate on.)
>
> Arranging for a tlb_flush if needed has to be the Memory API's
> problem, because everything that uses the memory API to rearrange
> the view of the address space has exactly the same requirement that
> anything else in QEMU has to be told it may need to redo any caching
> data structure it has set up. In particular, this doesn't apply just
> for a single CPUState* -- in a multicore system every CPU has to be
> made aware that the world has changed, not just the one which
> happened to do the store to the "remap the flash" register.
> Also the memory API is the only thing that knows whether the region
> was already enabled (ie this is a no-op), whether some other region
> is overlapping so in fact it makes no difference whether we enable
> or disable this one, etc etc).
>
> So basically I dropped that line because it was a bit of commented
> out code with a ??? marker appended, and the device layer is the
> wrong place to be trying to solve the issue it was gesturing at.
>

Correct, and the memory core will flush the tlb, so all is well.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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