From: Gordan Bobic <gordan@bobich.net>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU etc/e820 and fw_cfg
Date: Wed, 04 Mar 2015 19:12:10 +0000 [thread overview]
Message-ID: <9779520a9ba5544750f4eb570ce3bf8c@mail.shatteredsilicon.net> (raw)
In-Reply-To: <1425475231.8389.63.camel@nilsson.home.kraxel.org>
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. This typically results in crashing the
host (or worse, if it happens to trample any IOMEM regions
mapped to disk controllers).
The solution seems to be to prevent the guest from accessing
the areas of memory that are mapped as something other than
RAM on the host.
So what I need to be able to do is set a bseline e820 map
that marks all areas as reserved if they are not marked
as usable on the host.
I wrote a prototype patch (an ugly bodge not for public
consumption) for Xen to test the theory of whether this
would fix the problem, and it did. But I would like to
use KVM now instead. I tried using the max-ram-below-4g
option to --machine, and that fixes a part of the problem,
but because it doesn't mark the memory between the set
value and 4GB as reserved, it ends up mapping the PCI
devices passed through to the guest into that area, which
similarly ends up trampling over the host's IOMEM area
and crashing the machine. So I need a way to explicitly
reserve certain memory ranges in the map.
What is the most sensible way to do this with QEMU?
Gordan
next prev parent reply other threads:[~2015-03-04 19:12 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 [this message]
2015-03-05 8:08 ` Gerd Hoffmann
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=9779520a9ba5544750f4eb570ce3bf8c@mail.shatteredsilicon.net \
--to=gordan@bobich.net \
--cc=kraxel@redhat.com \
--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).