[Top][All Lists]

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

Re: [Qemu-devel] RFC: memory API changes

From: Paolo Bonzini
Subject: Re: [Qemu-devel] RFC: memory API changes
Date: Wed, 25 Mar 2015 12:34:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 25/03/2015 00:41, Peter Maydell wrote:
> On 24 March 2015 at 20:00, Paolo Bonzini <address@hidden> wrote:
>> I agree with that.  I just want to keep ld/st*_phys _in addition_ as the
>> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
>> address_space_ld/st* for those uses that have cs->as as the first argument.
> ...but for ARM I want to be able to specify the memory
> attribute argument (and possibly also get the behaviour
> right on failure). So I definitely don't want the short
> forms for my cs->as uses.

You're free to move ARM to the longer versions, and/or to push the short
versions to all cpu.h files except ARM's.

> And it seems to me at best
> uncertain that anybody does, in the long run.

I disagree: most CPUs are in odd fixes/unmaintained state (so attributes
probably won't matter), and most don't even define an unassigned_access
callback (so result won't matter either).

>> The rationale is to evolve ld/st*_phys into CPU-specific accessors
>> paralleling the bus-specific accessors.
> I don't think this is any harder starting from
> address_space_ld/st* than if we leave ld/st*_phys
> around.

It does cause unnecessary churn though.


reply via email to

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