[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] 64 bit I/O support v7

From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7
Date: Fri, 1 May 2009 13:03:50 +0100
User-agent: KMail/1.9.9

> The old array function call is supported so no existing drivers need
> to be modified.  They can continue to do 2 32 bit accesses because 2
> helper functions have been added to break up the accesses automatically.
> However, the helper functions should only be used until all drivers are
> converted to use the structure and then can be removed along
> with the old array functions api.  The replacement of the arrays with
> structures in the drivers is very straightforward for drivers that don't
> do 64 bit I/O and the few that do can be cleaned up to remove the
> work arounds for the lack of true 64 bit I/O by their maintainers.

This is going to be a bit of a pain, and a lot of duplication.  My expectation 
is that most devices don't know/care about 64-bit accesses and want them to 
be automatically split into a pair of 32-bit accesses. I suggest pushing this 
down into the lower level dispatch routines. By my reading your mem_writeq 
helpers are broken if we happen to have multiple regions with the same opaque 
value (this effects at least lsi53c895a.c).

In the interests of avoiding duplication, I'd also implement 
cpu_register_io_memory in terms of cpu_register_io_memory64.

> +    return ((CPUReadMemoryFunc64*)(*mmio->mem_read[idx][3]))
> (mmio->opaque[idx][0][3],  addr + mmio->region_offset[idx][0][3]);

Eww. It would be a good idea to fix this at the same time.


reply via email to

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