On 03/04/2014 08:33 AM, Don Slutz wrote: > On 03/03/14 05:47, Alexey Kardashevskiy wrote: >> On 03/03/2014 07:33 PM, Paolo Bonzini wrote: >>> Il 03/03/2014 02:58, Alexey Kardashevskiy ha scritto: >>>> On 03/02/2014 08:31 AM, Paolo Bonzini wrote: >>>>> Il 01/03/2014 13:30, Alexey Kardashevskiy ha scritto: >>>>>>>> Corrupted DMA buffer is 0x e00000 -- 0x7f15c313f000. >>>>>>>> The e1000 packet is at 0x12ffac2 -- 0x7f15c313eac2. >>>>>>>> >>>>>>>> (0x7f15c313f000 - 0x7f15c313eac2) = 0x53e which is less than 0x5aa and >>>>>>>> (0x5aa - 0x53e) = 0x6c bytes get corrupted. >>>>>>>> >>>>>>>> I see here buffer overrun from e1000 and I suspect that your patch >>>>>>>> just >>>>>>>> hides this problem. What did I miss? >>>>>> Ping, anyone? >>>>> You missed that this is a Xen-specific problem. Xen maps things a >>>>> page at >>>>> a time, so address_space_map/unmap/rw can operate only on a small part of >>>>> the requested [address, address+length) range. >>>> Sorry, I am not following you here. Does KVM map things not page-aligned? >>> Look in exec.c for xen_enabled(). Xen's implementation of >>> address_space_map/unmap is completely different. >> Honestly cannot see much difference in the current QEMU... >> >>>>> So there is no overrun in e1000. The patch is incomplete, because it >>>>> fixes >>>>> only address_space_rw, but the problem is indeed in exec.c. >>>> So you know what the problem is? We have a bunch of bugreports against >>>> e1000 breaking things... >>> This one had been reported and fixed already. >> Any hint? :) Could not spot any related to overrun except: >> a0ae17a 8 months ago Andrew Jones e1000: cleanup process_tx_desc >> but commit message says "complaints are false positives"... >> >> > > Looks like you have also ignored: > > http://marc.info/?l=qemu-devel&m=139325054822857&w=2 > http://marc.info/?l=qemu-devel&m=139325135123159&w=2
Oh, thanks! -- Alexey
