On Tue, 2012-01-03 at 16:29 -0800, Gordon Messmer wrote: > 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 ? It looks like the AMD path initializes the GART as a fallback in case AMD IOMMU initialization fails and allocates the swiotlb if there are devices that are not handled by the IOMMU, so probably best just to forget about that memory. > > 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? All AMD IOMMU (AMD-Vi) hardware supports interrupt remapping, but there's no Linux software support for it, so that config option really only enables the Intel code. > >> 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 Yep, that's what I would have guessed, there's a 256MB resource. I'm not sure if the seabios you're using is mapping the MMIO hole efficiently enough to handle that. Can you test on new upstream qemu-kvm? Thanks, Alex -- 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
