Am 05.01.2012 01:24, schrieb Peter Maydell:
On 5 January 2012 00:16, Anthony Liguori <anth...@codemonkey.ws> wrote:
On 01/04/2012 05:33 PM, Peter Maydell wrote:
A lot of the usage of target_phys_addr_t in hw/ is actually not
handling addresses at all, but merely offsets into device IO regions
(ie as parameters to device read/write functions)...
Exactly, which is why using target_phys_addr_t (and subsequently building
the device twice) doesn't make a lot of sense.
So should we have a hw_offset type for this? That would cut out a lot
of the noise and let us find out how much code in hw/ is actually
using physaddrs...
-- PMM
Hardware offsets are hardware: you can count the address lines
or get the values from the vendor's manual (you cannot count when
serial protocolsare used). A 32 bit PCI card will take 32 bit
offsets (or smaller), even when itis used in a 64 bit host.
It should be possible to model that in QEMU, too. uint8_t,
uint16_t, uint32_t and uint64_t are good enough to describe
the typical offset ranges of any hardware.
Cheers,
Stefan Weil