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

[Robert Reif <reif@earthlink.net>]

Paul Brook wrote:
>> Here is a patch for most of the sparc32 hardware drivers.  It's
>> a very trivial and mechanical process for these drivers.  The one
>> driver that does 64 bit accesses just adds 64 bit access functions
>> because it's broken now and has no workaround to remove.  I don't
>> think converting most other drivers will be much harder.
>>     
>
> sparc hardware is rather abnormal (for qemu at least) because it cares what 
> happens when you use the wrong width. Most devices don't care, and having any 
> NULL functions is liable to introduce significant overhead.
>
> Paul
>
>   
Ok, so that explains the curious code in m48t59.c:

static void nvram_writeb (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, value & 0xff);
}

static void nvram_writew (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, (value >> 8) & 0xff);
    m48t59_write(NVRAM, addr + 1, value & 0xff);
}

static void nvram_writel (void *opaque, target_phys_addr_t addr, 
uint32_t value)
{
    m48t59_t *NVRAM = opaque;

    m48t59_write(NVRAM, addr, (value >> 24) & 0xff);
    m48t59_write(NVRAM, addr + 1, (value >> 16) & 0xff);
    m48t59_write(NVRAM, addr + 2, (value >> 8) & 0xff);
    m48t59_write(NVRAM, addr + 3, value & 0xff);
}

So nvram_writeq should be present on non sparc architectures
and actually should be doing 8 byte accesses?  How do we handle
architecture differences like this?  On sparc, it looks like the
sbus controller does this because the actual hardware really
only has an 8 bit bus.