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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
