Avi Kivity writes:
> On 10/04/2012 04:13 PM, Anthony Liguori wrote:
>>>
>>> +void address_space_init_dispatch(AddressSpace *as)
>>> +{
>>> +AddressSpaceDispatch *d = g_new(AddressSpaceDispatch, 1);
>>> +
>>> +d->phys_map = (PhysPageEntry) { .ptr = PHYS_MAP_NODE_NIL, .is_leaf =
>>> 0 }
On 10/04/2012 09:16 PM, Peter Maydell wrote:
> On 4 October 2012 20:05, Anthony Liguori wrote:
>> Blue Swirl writes:
>>> They can all be 64 bits, I'm just considering types. Getting rid of
>>> target_phys_addr_t, pcibus_t, pio_addr_t and dma_addr_t (are there
>>> more?) may be also worthwhile.
>>
On Thu, Oct 4, 2012 at 7:05 PM, Anthony Liguori wrote:
> Blue Swirl writes:
>
>> On Thu, Oct 4, 2012 at 5:19 PM, Avi Kivity wrote:
>>> On 10/04/2012 07:13 PM, Blue Swirl wrote:
On Thu, Oct 4, 2012 at 6:38 AM, Avi Kivity wrote:
> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>> >
>>
On 4 October 2012 20:05, Anthony Liguori wrote:
> Blue Swirl writes:
>> They can all be 64 bits, I'm just considering types. Getting rid of
>> target_phys_addr_t, pcibus_t, pio_addr_t and dma_addr_t (are there
>> more?) may be also worthwhile.
>
> Where this breaks down is devices that are DMA ca
Blue Swirl writes:
> On Thu, Oct 4, 2012 at 5:19 PM, Avi Kivity wrote:
>> On 10/04/2012 07:13 PM, Blue Swirl wrote:
>>> On Thu, Oct 4, 2012 at 6:38 AM, Avi Kivity wrote:
On 10/03/2012 10:24 PM, Blue Swirl wrote:
> >
> > #else
> > -void cpu_physical_memory_rw(target_phys_addr_t
On 10/04/2012 04:13 PM, Anthony Liguori wrote:
>>
>> +void address_space_init_dispatch(AddressSpace *as)
>> +{
>> +AddressSpaceDispatch *d = g_new(AddressSpaceDispatch, 1);
>> +
>> +d->phys_map = (PhysPageEntry) { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0
>> };
>> +d->listener = (Memor
Avi Kivity writes:
> Currently we use a global radix tree to dispatch memory access. This only
> works with a single address space; to support multiple address spaces we
> make the radix tree a member of AddressSpace (via an intermediate structure
> AddressSpaceDispatch to avoid exposing too man
On Thu, Oct 4, 2012 at 5:19 PM, Avi Kivity wrote:
> On 10/04/2012 07:13 PM, Blue Swirl wrote:
>> On Thu, Oct 4, 2012 at 6:38 AM, Avi Kivity wrote:
>>> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>
> #else
> -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> -
On 10/04/2012 07:13 PM, Blue Swirl wrote:
> On Thu, Oct 4, 2012 at 6:38 AM, Avi Kivity wrote:
>> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>>> >
>>> > #else
>>> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>>> > -int len, int is_write)
>>> > +
On Thu, Oct 4, 2012 at 6:38 AM, Avi Kivity wrote:
> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>> >
>> > #else
>> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>> > -int len, int is_write)
>> > +
>> > +void address_space_rw(AddressSpace *as, targ
On 10/04/2012 12:29 PM, Peter Maydell wrote:
> On 4 October 2012 11:15, Avi Kivity wrote:
>> On 10/04/2012 10:47 AM, Peter Maydell wrote:
>>> I'd favour just moving everything to 64 bits (the remaining
>>> 32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32,
>>> xtensa). However
On 4 October 2012 11:15, Avi Kivity wrote:
> On 10/04/2012 10:47 AM, Peter Maydell wrote:
>> I'd favour just moving everything to 64 bits (the remaining
>> 32 bit targets are: cris, lm32, m68k, microblaze, or32, sh4, unicore32,
>> xtensa). However it does require some review of devices to check th
On 10/04/2012 10:47 AM, Peter Maydell wrote:
>>> I'd make address_space_* use uint64_t instead of target_phys_addr_t
>>> for the address. It may actually be buggy for 32 bit
>>> target_phys_addr_t and 64 bit DMA addresses, if such architectures
>>> exist. Maybe memory.c could be made target indepe
On 4 October 2012 07:38, Avi Kivity wrote:
> On 10/03/2012 10:24 PM, Blue Swirl wrote:
>> >
>> > #else
>> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
>> > -int len, int is_write)
>> > +
>> > +void address_space_rw(AddressSpace *as, target_phys
On 10/03/2012 10:24 PM, Blue Swirl wrote:
> >
> > #else
> > -void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> > -int len, int is_write)
> > +
> > +void address_space_rw(AddressSpace *as, target_phys_addr_t addr, uint8_t
> > *buf,
> > +
On Wed, Oct 3, 2012 at 4:04 PM, Avi Kivity wrote:
> Currently we use a global radix tree to dispatch memory access. This only
> works with a single address space; to support multiple address spaces we
> make the radix tree a member of AddressSpace (via an intermediate structure
> AddressSpaceDisp
Currently we use a global radix tree to dispatch memory access. This only
works with a single address space; to support multiple address spaces we
make the radix tree a member of AddressSpace (via an intermediate structure
AddressSpaceDispatch to avoid exposing too many internals).
A side effect
17 matches
Mail list logo
