On 04.02.2014, at 01:44, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 3 February 2014 23:28, Alexander Graf <ag...@suse.de> wrote:
>> That means that something relies on the incorrect behavior we did
>> before to set *plen (end) = *plen (start) after the loop when
>> !mr->iommu_ops. I wonder what that could be...
>
> I bounced around in a debugger for a bit looking for cases where
> the *plen got updated. One of them is
> cpu_physical_memory_write_rom_internal(): we now rather less
> efficiently do memcpy of 4K at a time into the guest RAM rather
> than blasting the entire ROM image, but the code still works.
I suppose the same happens on DMA access, rendering it less efficient, no?
>
> This backtrace, on the other hand, looks rather more suspect:
>
> #0 portio_write (opaque=0x101686160, addr=0, data=4, size=1) at
> /Users/pm215/src/qemu/ioport.c:203
> #1 0x000000010032f143 in memory_region_write_accessor
> (mr=0x101686160, addr=0, value=0x105fab508, size=1, shift=0, mask=255)
> at /Users/pm215/src/qemu/memory.c:441
> #2 0x000000010032f062 in access_with_adjusted_size (addr=0,
> value=0x105fab508, size=1, access_size_min=1, access_size_max=4,
> access=0x10032f0a0 <memory_region_write_accessor>, mr=0x101686160) at
> /Users/pm215/src/qemu/memory.c:478
> #3 0x000000010032e16f in memory_region_dispatch_write
> (mr=0x101686160, addr=0, data=4, size=1) at
> /Users/pm215/src/qemu/memory.c:985
> #4 0x000000010032e079 in io_mem_write (mr=0x101686160, addr=0, val=4,
> size=1) at /Users/pm215/src/qemu/memory.c:1744
> #5 0x00000001002c47c1 in address_space_rw (as=0x10067fd80,
> addr=4261413326, buf=0x105fab66c "\004", len=2, is_write=true) at
> /Users/pm215/src/qemu/exec.c:2011
> #6 0x00000001002c511f in address_space_write (as=0x10067fd80,
> addr=4261413326, buf=0x105fab66c "\004", len=2) at
> /Users/pm215/src/qemu/exec.c:2068
> #7 0x00000001002c3b13 in subpage_write (opaque=0x103058200, addr=462,
> value=1024, len=2) at /Users/pm215/src/qemu/exec.c:1662
> #8 0x000000010032f143 in memory_region_write_accessor
> (mr=0x103058200, addr=462, value=0x105fab798, size=2, shift=0,
> mask=65535) at /Users/pm215/src/qemu/memory.c:441
> #9 0x000000010032f00a in access_with_adjusted_size (addr=462,
> value=0x105fab798, size=2, access_size_min=1, access_size_max=4,
> access=0x10032f0a0 <memory_region_write_accessor>, mr=0x103058200) at
> /Users/pm215/src/qemu/memory.c:473
> #10 0x000000010032e16f in memory_region_dispatch_write
> (mr=0x103058200, addr=462, data=1024, size=2) at
> /Users/pm215/src/qemu/memory.c:985
> #11 0x000000010032e079 in io_mem_write (mr=0x103058200, addr=462,
> val=1024, size=2) at /Users/pm215/src/qemu/memory.c:1744
> #12 0x000000010037da52 in io_writew (env=0x1019ae338, physaddr=462,
> val=1024, addr=4261413326, retaddr=4430414751) at
> softmmu_template.h:336
> #13 0x000000010037dc37 in helper_be_stw_mmu (env=0x1019ae338,
> addr=4261413326, val=1024, mmu_idx=1, retaddr=4430414751) at
> softmmu_template.h:448
>
> The address_space access/write functions from
> subpage_write have decided that len==2 isn't valid
> (ie we called address_space_translate with plen pointing
> at a value of 2, address_space_translate_internal updated
> that to 1 (prior to this commit it would have left it alone) and
> we are now going to do what started off as a 16 bit access
> as two single byte writes. I have a feeling this is also
> bypassing the endianness swapping that would otherwise
> happen for this 16 bit write, as well.
>
> This happens because the IO port we're trying to access:
> { 2, 1, 2, .read = vbe_ioport_read_data, .write = vbe_ioport_write_data },
>
> is declared as having a length of 1 and a size of 2. That
> would be nonsensical for MMIO but is apparently entirely
> fine for IO ports (go x86 madness). With this change, the
> memory system is now refusing to allow an access of size
> 2 through, because it's greater than the region length. So
Ouch. Yes, for ioport reads/writes we definitely have to only cap the port
range, not the length.
Alex
