All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.