From: Gordon Messmer <yinyang@eburg.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: Device pass-through
Date: Tue, 03 Jan 2012 16:29:26 -0800 [thread overview]
Message-ID: <4F039D66.103@eburg.com> (raw)
In-Reply-To: <1325626484.4305.15.camel@bling.home>
Thanks, Alex. I really appreciate the reply.
On 01/03/2012 01:34 PM, Alex Williamson wrote:
> This is actually the GART aperture, which Linux will try to use as an
> IOMMU. You can pretty much ignore this, but it may be wasting memory
> for no good reason if it's really hiding usable memory and allocating a
> bounce buffer area.
It does look that way, but I doubt I'll miss it. Would you suggest that
I boot with swiotlb=0 ?
> The host is potentially exposed to a malicious guest trying to trigger
> MSI interrupts for denial of service or exploit probing. If you trust
> your guest, it's safe to allow this.
I do. It's a Fedora guest that I'm personally using. Suppose I didn't.
My kernel was built with CONFIG_INTR_REMAP=y but the kernel said
"kvm_iommu_map_guest: No interrupt remapping support, disallowing device
assignment." Does that mean that the motherboard doesn't support
interrupt remapping?
>> 4: What do these errors mean, and is there any way I can correct the
>> problem?
>>> create_userspace_phys_mem: File exists
>>> assigned_dev_iomem_map: Error: create new mapping failed
>
> Might mean the resources for the graphics card are getting mapped to
> overlap with guest memory. What does lspci -v for the graphics card
> show? More recent changes upstream might make better use of the space
> we have for devices, might be worth a test.
05:00.0 VGA compatible controller: ATI Technologies Inc RV620 PRO
[Radeon HD 3470] (prog-if 00 [VGA controller])
Subsystem: Dell Device 3243
Flags: fast devsel, IRQ 17
Memory at c0000000 (64-bit, prefetchable) [disabled] [size=256M]
Memory at fd9f0000 (64-bit, non-prefetchable)
[disabled] [size=64K]
I/O ports at ae00 [disabled] [size=256]
Expansion ROM at fd900000 [disabled by cmd] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information <?>
Kernel modules: radeon
next prev parent reply other threads:[~2012-01-04 0:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 19:41 Device pass-through Gordon Messmer
2012-01-03 21:34 ` Alex Williamson
2012-01-04 0:29 ` Gordon Messmer [this message]
2012-01-04 3:44 ` Alex Williamson
2012-01-05 19:07 ` Gordon Messmer
2012-01-06 7:25 ` Gordon Messmer
2012-01-06 9:31 ` André Weidemann
2012-01-07 2:07 ` Gordon Messmer
2012-01-07 22:21 ` Gordon Messmer
2012-01-09 6:22 ` Gordon Messmer
2012-01-16 6:52 ` Gordon Messmer
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=4F039D66.103@eburg.com \
--to=yinyang@eburg.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.