qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching


From: Anthony Liguori
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Date: Fri, 12 Jul 2013 12:49:59 -0500
User-agent: Notmuch/0.15.2+202~g0c4b8aa (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Benjamin Herrenschmidt <address@hidden> writes:

> On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
>> We model a single system wide io space today and access to that one
>> happens through you pci host controller. I just messed up the
>> terminology here.
>
> Single system wide IO space is broken. We have separate IO space per
> PHB. That was working afaik.

Hrm, probably not.  We don't propagate I/O spaces very well today.

> In any case, I completely object to all that business with conversion in
> bridges.
>
> That's fundamentally WRONG.
>
> The whole business of endianness in qemu is a mess. In the end what
> matters and the only thing that does is:

It's not as bad as you think I suspect.

>  * The endianness of a given memory access by the guest (which may or
> may not be the endianness of the guest -> MSR:LE, byteswap load/store
> instsructions, etc..)

Correct.

> vs.
>
>  * The endianness of the target device register (and I say register ...
> a framebuffer does NOT have endianness per-se and thus accesses to BAR
> mapping a "memory" range (framebuffer, ROM, ...) should go such that the
> *byte order* of individual bytes is preserved, which typically means
> untranslated).

Yes.  To put it another way, an MMIO write is a store and depending on
the VCPU, that will result in a write with a certain byte order.  That
byte order should be preserved.

However, what we don't model today, and why we have the silly
endianness in MemoryRegionOps, is the fact that I/O may pass through
multiple layers and those layers may change byte ordering.

We jump through great hoops to have a flat dispatch table.  I've never
liked it but that's what we do.  That means that in cases where a host
bridge may do byte swapping, we cannot easily support that.

That's really what endianness is for but it's abused.

> Unless they are completely broken (and those exist, don't get me wrong,
> though mostly they are a thing of a past long gone), bridges and busses
> have no effect on endianness.

That's simply not true.  There are programmable PCI host bridges that
support byte swapping.  Some allow this to be done on a per-device basis
too.

> So I'm not sure what you guys are up to, but from what I read, it's
> wrong, and the fact at this stage is that your broke IO space (and thus
> virtio and VGA) on powerpc (including pseries).

I'm not sure what this patch was trying to do but it was certainly
wrong.

Regards,

Anthony Liguori

>
> Cheers,
> Ben.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]