On 06/07/2015 14:12, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2015 at 12:50:43PM +0100, Peter Maydell wrote:
>> On 6 July 2015 at 11:31, Michael S. Tsirkin wrote:
>>> On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
>
On Mon, Jul 06, 2015 at 02:04:12PM +0200, Paolo Bonzini wrote:
>
>
> On 06/07/2015 13:50, Peter Maydell wrote:
> > On 6 July 2015 at 11:31, Michael S. Tsirkin wrote:
> >> On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
> >>> On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
> >>
On Mon, Jul 06, 2015 at 12:50:43PM +0100, Peter Maydell wrote:
> On 6 July 2015 at 11:31, Michael S. Tsirkin wrote:
> > On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
> >> On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
> >> > On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter May
On 06/07/2015 13:50, Peter Maydell wrote:
> On 6 July 2015 at 11:31, Michael S. Tsirkin wrote:
>> On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
>>> On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
> But a
On 6 July 2015 at 11:31, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
>> On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
>> > On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
>> >> But address_space_rw() is just the "memcpy bytes to t
On Mon, Jul 06, 2015 at 11:04:24AM +0100, Peter Maydell wrote:
> On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
> > On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
> >> But address_space_rw() is just the "memcpy bytes to the
> >> target's memory" operation -- if you have a pile
On 6 July 2015 at 11:03, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
>> But address_space_rw() is just the "memcpy bytes to the
>> target's memory" operation -- if you have a pile of bytes
>> then there are no endianness concerns. If you don't have
>>
On Mon, Jul 06, 2015 at 10:11:18AM +0100, Peter Maydell wrote:
> On 6 July 2015 at 10:06, Michael S. Tsirkin wrote:
> > On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
> >> Why host endian and not device (in this case little) endian?
>
> > It's the endian of the originator of the t
On 6 July 2015 at 10:06, Michael S. Tsirkin wrote:
> On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
>> Why host endian and not device (in this case little) endian?
> It's the endian of the originator of the transaction.
> And emulated device code is all compiled in host endian-nes
On Mon, Jul 06, 2015 at 10:46:31AM +0200, Paolo Bonzini wrote:
>
>
> On 06/07/2015 10:33, Michael S. Tsirkin wrote:
> > 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.
> >
On 06/07/2015 10:33, Michael S. Tsirkin wrote:
> 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
> memor
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
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_endi
On Thu, Jul 02, 2015 at 09:02:58PM +0200, Paolo Bonzini wrote:
>
>
> On 02/07/2015 21:00, Michael S. Tsirkin wrote:
> > On Thu, Jul 02, 2015 at 08:48:14PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 02/07/2015 15:00, Michael S. Tsirkin wrote:
> >>> +cfg = (void *)(proxy->pci_dev.config
On Do, 2015-07-02 at 15:00 +0200, Michael S. Tsirkin wrote:
> spec says we must, so let's do it!
>
> Signed-off-by: Michael S. Tsirkin
> ---
>
> untested at this point.
Tested-by: Gerd Hoffmann
[ seabios patches follow in a moment ]
cheers,
Gerd
On 02/07/2015 21:00, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2015 at 08:48:14PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 02/07/2015 15:00, Michael S. Tsirkin wrote:
>>> +cfg = (void *)(proxy->pci_dev.config + proxy->config_cap);
>>> +off = le32_to_cpu(cfg->cap.offset);
>>> +
On Thu, Jul 02, 2015 at 08:48:14PM +0200, Paolo Bonzini wrote:
>
>
> On 02/07/2015 15:00, Michael S. Tsirkin wrote:
> > +cfg = (void *)(proxy->pci_dev.config + proxy->config_cap);
> > +off = le32_to_cpu(cfg->cap.offset);
> > +len = le32_to_cpu(cfg->cap.length);
> > +
> > +
On 02/07/2015 15:00, Michael S. Tsirkin wrote:
> +cfg = (void *)(proxy->pci_dev.config + proxy->config_cap);
> +off = le32_to_cpu(cfg->cap.offset);
> +len = le32_to_cpu(cfg->cap.length);
> +
> +if ((len == 1 || len == 2 || len == 4)) {
> +address_space_
spec says we must, so let's do it!
Signed-off-by: Michael S. Tsirkin
---
untested at this point.
Paolo, could you pls take a look and confirm this
memory API usage is ok?
hw/virtio/virtio-pci.h | 3 ++
hw/virtio/virtio-pci.c | 76 +-
2 files cha
19 matches
Mail list logo
