qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory c


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Date: Sun, 14 Jul 2013 08:15:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

Il 13/07/2013 17:22, Anthony Liguori ha scritto:
> 1) MMIO request goes to sPAPR PIO area, the vCPU was in BE mode but by
> the time the handler is called, the value is in host byte order.
> 
> 2) sPAPR (incorrectly) byte swaps by marking the region as little
> endian (data is now garbage)
> 
> 3) The portio layer (incorrectly) byte swaps because it is marked as
> little endian (data is now good)
> 
> 4) Dispatch happens to VGA device which (incorrectly) byte swaps
> because it is marked as little endian (data is now bad)
> 
> (2), (3), and (4) are all wrong.  By removing either (2) or (3) we can
> "fix" the regression but that's just because two wrongs make a right
> in this situation.
> 
> We should remove *all* of the LE markings from ISA devices, remove the
> portio mark, and the sPAPR mark.  That's the right fix.

So the bug here is that we have multiple levels of dispatch.  Byte
swapping in the dispatch level only works as long as every dispatch is
merged, which is not the case.

However, I do suspect that you have broken PREP again, because PREP has
1/3/4 but not 2.  Removing (2) IIUC amounts to re-applying commit
a178274efabcbbc5d44805b51def874e47051325, and I think that's a better fix.

Also, what devices exactly would have a non-native byte order?!?  I'm
confused...

Paolo



reply via email to

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