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

[Peter Maydell]

On 24 March 2015 at 14:45, Paolo Bonzini <address@hidden> wrote:
> On 24/03/2015 14:47, Peter Maydell wrote:
>> On 23 March 2015 at 12:24, Peter Maydell <address@hidden> wrote:
>>  * no default-to-no-attrs/etc versions of ld/st*_ phys
>>    (if in specific devices/buses it's the best thing we should
>>    have bus-specific dma accessors, as we do for pci)
>
> I would keep them since they're really heavily used with cs->as as the
> first argument.  But definitely move them to a different header than
> cpu-common.h, and perhaps make them takes a CPUState instead of an
> AddressSpace (which might help solving "where do we call the
> unassigned-access hooks" in the future).

No, I think we want to be able to do simple "load a word
from an arbitrary AddressSpace" functions. And these should
definitely include the parameters for attributes and result
information, because otherwise it's way too easy to just
forget completely about those when you're writing a device.
What I don't think there's much call for is "load/store a
word, but completely ignore the possibility that might fail".

At some point we might want to have functions that take a
CPUState, yes. (We probably *don't* want those to do the
"call the unassigned access hook", because longjumping out of
functions is really hard to deal with, and we should I think
restrict that to code paths that come directly or near directly
from translated code. For instance if we take an exception trying
to read code during translation at the moment we do some completely
lunatic things that happen to work, and it would be much better
to just return a failure...) But that's separate cleanup IMHO.

In other words I'd rather try to restrict this to sorting out
the APIs that work generically on AddressSpaces. The amount
of change involved is already starting to feel very unwieldy.

> 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...

-- PMM