similar to: iommu options?

I hope someone can enlighten me. I have a quad-port Intel 82580 nic (igb driver) on my system and I''d like to dedicate each nic to a HVM via VT-d PCI passthrough. The IOMMU on my system seems to work, I can assign the PCI devices to my HVMs. The HVMs see the pci device and load their respective igb drivers, and ethtool -i eth0 works on each HVM, shows the drivers are loaded and the

Fixed : Double amount of memory from 128 to 256 and iommu works it out fine. RTFEM (read the fucking error message) : [ 0.872160] Kernel panic - not syncing: Out of memory and no killable processes... ________________________________________________________________________________________________________________ Frédéric Abel| RTS France BeNeLux | Quantum Corporation

Hi, I am playing around with PCI passthrough and came across some posts that said you could not do PCI passthrough unless you had IOMMU hardware. which it would appear I don't Is this the case? Am I flogging a dead horse? Thanks, Marco -- Marco van Beek ========================================== Supporting Role Ltd. Grove Park Studios, 188-192 Sutton Court Rd, London, W4 3HR

On Wed, Mar 04, 2020 at 02:37:08PM +0100, Joerg Roedel wrote: > Hi Michael, > > On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > > No. It's coded into the hardware. Which might even be practical > > for bare-metal (e.g. on-board flash), but is very practical > > when the device is part of a hypervisor. > > If its that way on PPC, than

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called as introduced with the patch "x86-64: detect processors subject to AMD erratum #121 and

Sorry to duplicate my issues onto the list - I thought I had looked through this thread before and seen a different error, but apparently Adam and I are running into much the same thing. I'm seeing exactly the same "Failed to assign device to IOMMU" along with the "Device not owned by PCI Back End or pci-stub" in these scenarios. I have not gone back to previous versions,

Matching the comment in iommu_set_dom0_mapping(), map only actual RAM from the address range starting at 4G. It''s not clear though whether that comment is actually correct (which is why I''m sending this as RFC), but it is certain that on systems with sparse physical memory map we''re currently wasting a potentially significant amount of memory for setting up IOMMU page

Hi, I''m running a machine with: - Hypervisor: xen-unstable - Dom0: xen/next-2.6.32.17 commit c3f5aba942c7516a5c76c47345ff0a473daf2542 Hardware: -MSI 890FXA-GD70 with AMD IOMMU -Phenom X6 I''m trying to do PCI passthrough to a HVM, this fails with: Error: Failed to assign device to IOMMU (0000:04:00.0@100,msitranslate=1,power_mgmt=0) Error: pci: to avoid potential security

Hi all, I''ve fetched the xen 4.0.1 source from the usual spot and have git''d the stable dom0 source (recently) from the jeremy repository, have successfully built and installed each of these on my VT-x and VT-d capable x86_64 system, over a fedora 14 installation. Most of the features seem to be running just fine, but I''m having a real problem getting the virtual

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote: > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices,

Hi folks, currently I try to setup a new xen host v3.4.1 on top of a Asus P5E-VM DO (latest BIOS, Vt-d capable and enabled in BIOS) to migrate my extisting HVMs (Win2k3 server) running on Xen v3.3.0 to a new home. I want to switch over to 3.4.1 to (hopefully!) passthrough my ISDN board to a HVM domU. Unfortunate there seem some issue with the VT-d DMAR tables which is beyond my knowledge and

diff -r e6266fc76d08 -r 6feac926cf80 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Fri Jul 27 12:22:13 2012 +0200 +++ b/xen/drivers/passthrough/vtd/iommu.c Mon Jul 30 15:35:16 2012 -0700 @@ -2137,6 +2137,15 @@ int __init intel_vtd_setup(void) { iommu = drhd->iommu; + printk("Intel VT-d supported page sizes: 4kB"); + if

Hello I am trying to boot ubuntu 9.04 with iommu=1 iommu=passthrough noreboot and i keep getting a panic i have vt and vt-d enabled in my bios here is the serial console capture __ __ _____ _ _ _ \ \/ /___ _ __ |___ /| || | / | \ // _ \ ''_ \ |_ \| || |_ | | / \ __/ | | | ___) |__ _|| | /_/\_\___|_| |_| |____(_) |_|(_)_|

Dear Users, Debian Etch 2.6.18.8-xen from xensource.com with Xen 3.3.0 on AMD64: After i want to start the HVM i get: VmError: fail to assign device(1:0.0): maybe it has already been assigned to other domain, or maybe it doesn''t exist. [2008-10-25 19:59:30 2460] DEBUG (__init__:1072) XendDomainInfo.destroy: domid=5 [2008-10-25 19:59:30 2460] DEBUG (__init__:1072)

> From: Tian, Kevin > Sent: Thursday, March 22, 2018 6:06 PM > > > From: Robin Murphy [mailto:robin.murphy at arm.com] > > Sent: Wednesday, March 21, 2018 10:24 PM > > > > On 21/03/18 13:14, Jean-Philippe Brucker wrote: > > > On 21/03/18 06:43, Tian, Kevin wrote: > > > [...] > > >>> + > > >>> +#include

Hi everyone, First post, already a call for help :) I''m trying to use a gtx 580 with Xen 4 VGA Passthrough to test CUDA performances, the MB is an Asus P7P55 LX with a i7 870, VT-D is enabled in bios and reported as active by Xen. I''m using Debian Squeeze as Dom0 and DomU OS. Dom0 is configured with iommu=1 and iommu=verbose parameters and xen-pciback.hide=(01:00.0)(01:00.1)

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

 Hi!    I want to make windows work  with native graphics card on xen with no iommu (no vt-d) support. With many googling, I find that xen with Neocleuse 1:1 No-IOMMU passthough patches maybe can meet my requestment.    I download and compile a copy of direct-io.hg source, and pass my graphics card to hvm