qemu-devel
[Top][All Lists]
Advanced

[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 15:45:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 24/03/2015 14:47, Peter Maydell wrote:
> On 23 March 2015 at 12:24, Peter Maydell <address@hidden> wrote:
>> (This is part of the work I'm doing for transaction attributes.)
> 
> OK, here's try 2, based on feedback on the first proposal:
> 
>  * address_space_rw &c remain with their current names, but
>    take an extra MemTxAttrs argument and return MemTxResult
>    rather than bool. (The latter conveniently doesn't require changes to
>    callsites because conversion to bool gives the same true-on-error
>    semantics as before.)
>    [maybe readbuf/writebuf would be clearer than read/write,
>    but it didn't seem sufficiently obvious a win to make the change]
>  * the ld/st_*phys functions are renamed as:
>      ldl_be_phys -> address_space_ldl_be &c
>    and all take MemTxAttrs, *MemTxResult
>  * rather than MEMTXATTRS_UNSPECIFIED, use TXATTRS_NONE, so the
>    extra arguments (TXATTRS_NONE, NULL) aren't too unwieldy
>  * prototypes in memory.h
>  * 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).

In any case, the removal or segregation of ld/st*_phys should be a
separate series for ease of review.

Apart from this, I'm on board.

Paolo

>  * mechanically convert all uses of cpu_physical_memory_* to
>    address_space_*(&address_space_memory, ...)
> 
> [This leaves the "where do we call the unassigned-access
> hooks" problem for a different patchset.]
> 
> Is there anything in there people strongly dislike, or
> should I start writing coccinelle patches for this?
> 
> -- PMM
> 



reply via email to

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