[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: Tue, 24 Mar 2015 18:51:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 24/03/2015 17:35, Peter Maydell wrote:
> On 24 March 2015 at 16:23, Paolo Bonzini <address@hidden> wrote:
>>> On 24 March 2015 at 15:08, Paolo Bonzini <address@hidden> wrote:
>>>> On 24/03/2015 15:53, Peter Maydell wrote:
>>>>>>> In any case, the removal or segregation of ld/st*_phys should be a
>>>>>>> separate series for ease of review.
>>>>> Who wants to remove ld/st*_phys? Not me...
>>>> Well, you want to rename them _and_ add new arguments.  Basically at the
>>>> end they don't exist anymore as we know them now. :)
>>> I guess :-)  So what exactly would you like to see as a
>>> separate series?
>> Adding the arguments / renaming the functions
> OK. (This will need the patch that actually at least defines
> the MemTxAttr and MemTxResult types, obviously.)
>> , for those callers
>> of ld/st*_phys that use cs->as as the first argument.
> ...but I don't understand this caveat. I want to add arguments
> and rename the functions for *all* callers of ld/st*_phys.
> I don't want to specialcase the ones which happen to be
> operating on cs->as.

The ones that operate on cs->as could become (for some CPUs at least)
special-cased accessors like the bus ones; for example building the
MemTxAttrs according to internal CPU state.

ld/st*_phys actually started as CPU-specific accessors, and most uses
are still of that kind, so it makes sense to me that we special-case
them.  Maybe it limits churn, maybe it doesn't.  But if it doesn't, it's
not like anything is lost.


reply via email to

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