From: Paolo Bonzini <pbonzini@redhat.com>
To: "Hoyer, David" <David.Hoyer@netapp.com>,
"Qemu-devel@nongnu.org" <Qemu-devel@nongnu.org>
Cc: "Moyer, Keith" <Keith.Moyer@netapp.com>,
"Best, Tish" <Tish.Best@netapp.com>
Subject: Re: [Qemu-devel] e1000 memory corruption in guest OS
Date: Mon, 24 Feb 2014 15:02:08 +0100 [thread overview]
Message-ID: <530B50E0.2020304@redhat.com> (raw)
In-Reply-To: <6777CD901FD53644B082307CD745FB8326AC9348@SACEXCMBX02-PRD.hq.netapp.com>
Il 16/02/2014 05:29, Hoyer, David ha scritto:
> We are using Qemu-1.7.0 with Xen-4.3.0 and Debian jessie. We are
> noticing that when we transfer large files from our network to the
> guestOS via the e1000 virtual network device that we experience memory
> corruption on the guestOS. We have debugged this problem and have
> determined where it appears that the corruption is happening and have
> created a patch file with a fix (at least the corruption is no longer
> happening on our guestOS anymore). Note that our test file is a
> large file consisting of the value 0x61 repeated over the entire file.
I think you are missing this patch:
commit 360e607b88a23d378f6efaa769c76d26f538234d
Author: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu Jan 30 12:46:05 2014 +0000
address_space_translate: do not cross page boundaries
The following commit:
commit 149f54b53b7666a3facd45e86eece60ce7d3b114
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri May 24 12:59:37 2013 +0200
memory: add address_space_translate
breaks Xen support in QEMU, in particular the Xen mapcache. The effect
is that one Windows XP installation out of ten would end up with BSOD.
The reason is that after this commit l in address_space_rw can span a
page boundary, however qemu_get_ram_ptr still calls xen_map_cache asking
to map a single page (if block->offset == 0).
Fix the issue by reverting to the previous behaviour: do not return a
length from address_space_translate_internal that can span a page
boundary.
Also in address_space_translate do not ignore the length returned by
address_space_translate_internal.
This patch should be backported to QEMU 1.6.x.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Anthony Perard <anthony.perard@citrix.com>
Tested-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-stable@nongnu.org
and the subsequent fix:
commit a87f39543a9259f671c5413723311180ee2ad2a8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri Feb 7 15:47:46 2014 +0100
memory: fix limiting of translation at a page boundary
Commit 360e607 (address_space_translate: do not cross page boundaries,
2014-01-30) broke MMIO accesses in cases where the section is shorter
than the full register width. This can happen for example with the
Bochs DISPI registers, which are 16 bits wide but have only a 1-byte
long MemoryRegion (if you write to the "second byte" of the register
your access is discarded; it doesn't write only to half of the register).
Restrict the action of commit 360e607 to direct RAM accesses. This
is enough for Xen, since MMIO will not go through the mapcache.
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Both of them will be included next week in 1.7.1.
Paolo
next prev parent reply other threads:[~2014-02-24 14:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-16 4:29 [Qemu-devel] e1000 memory corruption in guest OS Hoyer, David
2014-02-24 4:20 ` Alexey Kardashevskiy
2014-03-01 12:30 ` Alexey Kardashevskiy
2014-03-01 21:31 ` Paolo Bonzini
2014-03-03 1:58 ` Alexey Kardashevskiy
2014-03-03 8:33 ` Paolo Bonzini
2014-03-03 10:47 ` Alexey Kardashevskiy
2014-03-03 11:21 ` Paolo Bonzini
2014-03-03 21:33 ` Don Slutz
2014-03-03 22:53 ` Alexey Kardashevskiy
2014-02-24 14:02 ` Paolo Bonzini [this message]
2014-02-24 14:15 ` Hoyer, David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530B50E0.2020304@redhat.com \
--to=pbonzini@redhat.com \
--cc=David.Hoyer@netapp.com \
--cc=Keith.Moyer@netapp.com \
--cc=Qemu-devel@nongnu.org \
--cc=Tish.Best@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).