Re: [Qemu-devel] [PATCH] virtio-pci: implement cfg capability

[Michael S. Tsirkin]

On Mon, Jul 06, 2015 at 09:46:14AM +0200, Paolo Bonzini wrote:
> 
> 
> On 04/07/2015 23:19, Michael S. Tsirkin wrote:
> > The fact that address_space_write/_read actually does a byteswap if
> > host!=target endian should probably be documented.
> 
> FWIW, it's not if host != target endian.  It's if memory region
> endianness != target endianness.  See memory_region_wrong_endianness.

Right. What I meant is that if device != host then we want a byteswap
anyway.  E.g. if device says it's BE and system is LE, then it does want
to get byte 0 as MSB in the uint32 it gets.

IOW we want byteswap if host != MR.
Instead we get a byteswap if target != MR.

This is the same unless host != target.


> > Or maybe it should be changed: it seems likely that non-target-specific 
> > devices
> > that use it do this incorrectly ATM. In particular, dma_memory_rw_relaxed 
> > calls
> > address_space_rw and since DMA originates with devices I think there's very
> > little chance that these actually want a different behaviour depending on 
> > the
> > target endian-ness.
> > 
> > Most likely, these only work correctly because DMA outside RAM
> > is highly unusual.
> 
> They work correctly because of that, and because most devices *and*
> targets are little endian so you have no swap.  On ppc64, which has
> TARGET_WORDS_BIGENDIAN, it probably wouldn't work correctly.
> 
> Paolo

Also, by luck, some values work the same whatever the endian-ness.
E.g. dma_memory_set fills the buffer with a given pattern, so
nothing changes if you byte-swap it.

Here's an example that's wrong: dp8393x. Typically it's accessing
memory for DMA, so there's no byteswap. Works fine.

But should device attempt to access another device memory,
it would break because MIPS target is BE.

Cc Hervé for confirmation.

I conclude that virtio is not so special in needing a variant
of address_space_rw that assumes host endian format for the data.

-- 
MST