On 25/03/2015 12:43, Peter Maydell wrote:
> I was trying to avoid leaving us with yet another half-finished
> set of API transitions: because many of our CPUs are in this
> odd-fixes state, it's unlikely anybody will get round to
> updating them in the near future, so we'll be carrying a
> duplic
On 25 March 2015 at 11:34, Paolo Bonzini wrote:
>
>
> On 25/03/2015 00:41, Peter Maydell wrote:
>> On 24 March 2015 at 20:00, Paolo Bonzini 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
On 25/03/2015 00:41, Peter Maydell wrote:
> On 24 March 2015 at 20:00, Paolo Bonzini 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
On Mon, 23 Mar 2015 17:32:21 +0100
Andreas Färber wrote:
> Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> > On 23 March 2015 at 14:39, Paolo Bonzini wrote:
> >> On 23/03/2015 13:24, Peter Maydell wrote:
> >>> * cpu_physical_memory_rw are obsolete and should be replaced
> >>>with uses of th
On 24 March 2015 at 20:00, Paolo Bonzini wrote:
> On 24/03/2015 19:06, Peter Maydell wrote:
>> I think this is where we disagree. I see ld/st*_phys as being
>> really generic -- they take an AddressSpace, after all, and
>> part of the same family with address_space_read &c. If you
>> don't leave t
On 24/03/2015 19:06, Peter Maydell wrote:
> On 24 March 2015 at 17:51, Paolo Bonzini wrote:
>> On 24/03/2015 17:35, Peter Maydell wrote:
>>> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
> On 24 March 2015 at 15:08, Paolo Bonzini wrote:
, for those callers
of ld/st*_phys that u
On 24 March 2015 at 17:51, Paolo Bonzini wrote:
> On 24/03/2015 17:35, Peter Maydell wrote:
>> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
On 24 March 2015 at 15:08, Paolo Bonzini wrote:
>>> , for those callers
>>> of ld/st*_phys that use cs->as as the first argument.
>>
>> ...but I don
On 24/03/2015 17:35, Peter Maydell wrote:
> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
>>> On 24 March 2015 at 15:08, Paolo Bonzini 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 e
On 24 March 2015 at 16:23, Paolo Bonzini wrote:
>> On 24 March 2015 at 15:08, Paolo Bonzini 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/s
> On 24 March 2015 at 15:08, Paolo Bonzini 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 th
On 24 March 2015 at 15:08, Paolo Bonzini 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 n
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 an
On 24 March 2015 at 14:45, Paolo Bonzini wrote:
> On 24/03/2015 14:47, Peter Maydell wrote:
>> On 23 March 2015 at 12:24, Peter Maydell 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 ac
On 24/03/2015 14:47, Peter Maydell wrote:
> On 23 March 2015 at 12:24, Peter Maydell 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
>ta
On 23 March 2015 at 12:24, Peter Maydell 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
On 23 March 2015 at 17:51, Andreas Färber wrote:
> Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> The point of indicating failure via MemTxResult is that at
>>> some point we need to correct the current broken handling of
>>> the CPUClass do_unassign
Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
> On 23/03/2015 13:24, Peter Maydell wrote:
>> The point of indicating failure via MemTxResult is that at
>> some point we need to correct the current broken handling of
>> the CPUClass do_unassigned_access hook, because that should
>> only be invoked i
On 23 March 2015 at 16:30, Paolo Bonzini wrote:
> None of them does, uses of ld*_phys(cs->as, ...) are almost all in
> target-* already.
Oh good :-)
Regardless, I don't see why this means that ld*_phys should be
in cpu-common.h or cpu-all.h rather than memory.h ?
> There's just hw/ppc/spapr_hca
Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> * cpu_physical_memory_rw are obsolete and should be replaced
>>>with uses of the as_* functions -- we should at least note
>>>this in the header
On 23/03/2015 17:00, Peter Maydell wrote:
> On 23 March 2015 at 15:47, Paolo Bonzini wrote:
>> Ok, so most ld*_phys users are already using cs->as.
>
> But this is only because when the AddressSpace* argument
> to ld*_phys was introduced we made it be cs->as for
> existing callers, to retain th
On 23 March 2015 at 15:47, Paolo Bonzini wrote:
> Ok, so most ld*_phys users are already using cs->as.
But this is only because when the AddressSpace* argument
to ld*_phys was introduced we made it be cs->as for
existing callers, to retain the existing behaviour.
That doesn't mean that callers us
On 23/03/2015 16:39, Peter Maydell wrote:
> > Not necessarily, for example PCI devices can certainly
> > use the short name.
>
> PCI devices should all be using ld*_pci_dma and st*_pci_dma
> so they go through the correct address space for the PCIDevice.
> Any PCI device making direct calls to ld
On 23 March 2015 at 15:27, Paolo Bonzini wrote:
>
>
> On 23/03/2015 16:26, Peter Maydell wrote:
>> > True. But since it's not a new API we can keep the old name for the
>> > simple one.
>>
>> ...except that means that the function you should in
>> general not be using as default is the one with t
On 23 March 2015 at 15:18, Paolo Bonzini wrote:
> On 23/03/2015 16:11, Peter Maydell wrote:
>> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>>> On 23/03/2015 13:24, Peter Maydell wrote:
* ld/st*_phys to be renamed to as_ld*, eg
ldub_phys -> as_ldub
ldl_be_phys -> as_ldl
On 23/03/2015 16:26, Peter Maydell wrote:
> > True. But since it's not a new API we can keep the old name for the
> > simple one.
>
> ...except that means that the function you should in
> general not be using as default is the one with the short
> name, which is the wrong way round. We should b
On 23/03/2015 16:11, Peter Maydell wrote:
> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>>
>>
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> (This is part of the work I'm doing for transaction attributes.)
>>>
>>> Currently we have several APIs used for making physical
>>> memory accesses:
On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>
>
> On 23/03/2015 13:24, Peter Maydell wrote:
>> (This is part of the work I'm doing for transaction attributes.)
>>
>> Currently we have several APIs used for making physical
>> memory accesses:
>>
>> 1. cpu_physical_memory_rw &c
>>
>> 2. address_
On 23/03/2015 13:24, Peter Maydell wrote:
> (This is part of the work I'm doing for transaction attributes.)
>
> Currently we have several APIs used for making physical
> memory accesses:
>
> 1. cpu_physical_memory_rw &c
>
> 2. address_space_rw/read/write/map
>
> 3. ld/st*_phys
>
> These do
On 23 March 2015 at 12:30, Andreas Färber wrote:
> Am 23.03.2015 um 13:24 schrieb Peter Maydell:
>> * address_space_rw &c to be renamed:
>> address_space_rw -> as_rw_buf
>> address_space_read -> as_read_buf
>> address_space_write -> as_write_buf
>> address_space_map -> as_map_buf
Am 23.03.2015 um 13:24 schrieb Peter Maydell:
> * address_space_rw &c to be renamed:
> address_space_rw -> as_rw_buf
> address_space_read -> as_read_buf
> address_space_write -> as_write_buf
> address_space_map -> as_map_buf &c
>This is just so the names line up nicely and we h
(This is part of the work I'm doing for transaction attributes.)
Currently we have several APIs used for making physical
memory accesses:
1. cpu_physical_memory_rw &c
2. address_space_rw/read/write/map
3. ld/st*_phys
These do more-or-less overlapping jobs and it's not
obvious which should be u
31 matches
Mail list logo
