On Mon, Mar 30, 2015 at 8:28 PM, Paolo Bonzini <pbonz...@redhat.com> 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 >