From: Gerd Hoffmann <kraxel@redhat.com>
To: Gordan Bobic <gordan@bobich.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU etc/e820 and fw_cfg
Date: Thu, 05 Mar 2015 09:08:28 +0100 [thread overview]
Message-ID: <1425542908.12745.22.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <9779520a9ba5544750f4eb570ce3bf8c@mail.shatteredsilicon.net>
On Mi, 2015-03-04 at 19:12 +0000, Gordan Bobic wrote:
> On 2015-03-04 13:20, Gerd Hoffmann wrote:
> > On Di, 2015-03-03 at 10:32 +0000, Gordan Bobic wrote:
> >> I need to pass a custom e820 map to a virtual machine for
> >> troubleshooting purposes and working around IOMMU hardware
> >> bugs.
> >>
> >> I have found references to a custom map being providable
> >> via an external file, mentioned as "etc/e820" and "fw_cfg".
> >
> > That is the (filesystem-like) interface between qemu and firmware
> > (seabios usually), it doesn't refer to a on-disk file.
> >
> >> Unfortunately, I have not found any documentation that
> >> explains how to use this from userspace when invoking
> >> qemu.
> >
> > You can't.
> >
> > Passing a different e820 map requires patching qemu (or seabios, which
> > mangles the e820 table to add reservations for acpi etc).
> >
> > What exactly do you need?
>
> Thank you for responding. The situation I have is that my PCIe
> bridges are buggy and they seem to bypass the upstream PCIe hub
> IOMMU. The problem with this is that when the guest accesses
> RAM within it's emulated address space that overlaps with
> PCI I/O memory ranges in the host's address space, what should
> have ended up in RAM in the guest ends up trampling over the
> IOMEM on the host.
The iommu isn't involved here at all. When the pci devices are
accessing host ram via busmaster dma, *this* goes through the iommu.
And unless you are trying to use pci device assignment the iommu should
not matter at all.
What you describe sounds more like a bug in ept/ntp/softmmu (either
kernel driver or hardware). What machine is this? Intel? Has it ept?
What happens if you turn off ept?
I'd also suggest to go to the kvm list with this issue.
cheers,
Gerd
next prev parent reply other threads:[~2015-03-05 8:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 10:32 [Qemu-devel] QEMU etc/e820 and fw_cfg Gordan Bobic
2015-03-04 13:20 ` Gerd Hoffmann
2015-03-04 19:12 ` Gordan Bobic
2015-03-05 8:08 ` Gerd Hoffmann [this message]
2015-03-05 10:18 ` Gordan Bobic
2015-03-05 10:42 ` Gerd Hoffmann
2015-03-05 11:01 ` Gordan Bobic
2015-03-05 11:17 ` Gerd Hoffmann
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=1425542908.12745.22.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=gordan@bobich.net \
--cc=qemu-devel@nongnu.org \
/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).