Re: [Qemu-devel] [RFC PATCH 01/11] hw: use ld_p/st_p instead of ld_raw/st_raw

[Peter Maydell]

On 8 May 2014 17:09, Paolo Bonzini <address@hidden> wrote:
> The ld_raw and st_raw definitions are only needed in code that
> must compile for both user-mode and softmmu emulation.  Device
> models can use the equivalent ld_p/st_p which are simple
> pointer accessors.
>
> The checkpatch situation of nseries.c and mips_malta.c is
> messy.  I'm only doing a textual substitution in this RFC,
> maintainers should let me know what they prefer.


> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  hw/9pfs/virtio-9p-device.c     |   2 +-
>  hw/arm/nseries.c               | 236 
> ++++++++++++++++++++---------------------
>  hw/block/virtio-blk.c          |  12 +--
>  hw/display/omap_lcd_template.h |  10 +-
>  hw/display/sm501_template.h    |   6 +-
>  hw/display/vga_template.h      |   4 +-
>  hw/mips/mips_fulong2e.c        |  28 ++---
>  hw/mips/mips_malta.c           | 176 +++++++++++++++---------------
>  hw/scsi/vhost-scsi.c           |   4 +-
>  hw/scsi/virtio-scsi.c          |  28 ++---

The virtio parts of this look dubious. What actual
endianness does the virtio spec say that things like the
block device geometry should have in memory? I suspect
we should be using the use-the-virtio-endianness accessors
Greg's on-list patches implement, which renders the
raw-vs-p question moot. In any case you'll probably
have patch conflicts there.

For nseries.c I think I'd prefer we do the checkpatch fixups.
There's no reason we can't do this now (ie we don't wait
on the fixes which make the rest of this series an RFC),
so if you want to make this patch smaller you could submit
a patch for the ARM bits of this and I'll take it in
target-arm.next. (Or I can do it, if you'd rather.)

I suspect the OMAP display device at least should technically
be doing lduw_le_p(), since this isn't the CPU doing the
access, but an independent peripheral doing DMA reads
from memory. It's kind of an academic question for the
moment since you'll only see an OMAP device in an
LE-target QEMU binary, though, so straight substitution
is reasonable.

thanks
-- PMM