[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
>
- Re: [Qemu-devel] RFC: memory API changes, (continued)
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Andreas Färber, 2015/03/23
- Re: [Qemu-devel] RFC: memory API changes, Igor Mammedov, 2015/03/25
Re: [Qemu-devel] RFC: memory API changes, Andreas Färber, 2015/03/23
Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes,
Paolo Bonzini <=
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Peter Maydell, 2015/03/24
- Re: [Qemu-devel] RFC: memory API changes, Paolo Bonzini, 2015/03/25