qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] ppc vga output breakage since commit c3c1bb99


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] ppc vga output breakage since commit c3c1bb99
Date: Mon, 30 Mar 2015 21:45:53 +1000

On Mon, Mar 30, 2015 at 8:28 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 30/03/2015 12:20, Mark Cave-Ayland wrote:
>>> >
>>> > Of course, there's a QEMU regression too and I'm thinking of how to fix 
>>> > it.

Can the address_space_translate_address() length clamp be made
conditional on non-MMIO access as the RC fix? I submitted
c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 as I think its the right
thing to do regardless of memory type, but in reality it only fixes a
bug I encountered with RAM memory regions. The original code ignores
address_space_translate_internal() return-by-pointer length value
absolutely and the new code uses it absolutely. Should we just if the
whole thing, old vs new behaviour on MMIO vs non-MMIO?

Happy to submit that fixup if that's the accepted plan.

Regards,
Peter

>> Hmmm that's interesting because the documentation refers to both
>> registers being 16-bit: http://wiki.osdev.org/Bochs_VBE_Extensions. And
>> indeed the pseudo-code uses outpw/inpw for accesses, even though the
>> index and data registers are only 1 byte apart (0x1ce and 0x1cf) in I/O
>> space.
>
> Ugh, you're right.
>
>> Maybe OpenBIOS is getting the endian conversion incorrect for the word
>> access? (i.e. it's not converting to little endian).
>
> No, that's not it.  It's basically treating the whole access as
> "unassigned" because 0x1cf is not allocated (on non-x86 machines, the
> DISPI data port is at 0x1d0).
>
> Paolo
>



reply via email to

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