similar to: multiple devices in the same iommu group in L1 guest

Rather than requiring the scopes to be the first members of their respective structures (so that casts can be used to switch between the different views), properly use types and container_of(). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -304,13 +304,15 @@ static int __init scope_device_count(con

On Fri, Oct 30, 2020 at 07:44:43PM +0800, Jason Wang wrote: > >On 2020/10/30 ??6:54, Stefano Garzarella wrote: >>On Fri, Oct 30, 2020 at 06:02:18PM +0800, Jason Wang wrote: >>> >>>On 2020/10/30 ??1:43, Stefano Garzarella wrote: >>>>This patch enables the IOTLB API support for vhost-vsock devices, >>>>allowing the userspace to emulate an IOMMU

Purchased DQ35JO on Vt-d/PCI passthrough wiki''s recommendations. Built latest xen-unstable and am getting the following via ''xm dmesg'': (XEN) [VT-D]dmar.c:374: RMRR error: base_addr d0000000 end_address cfffffff (XEN) Failed to parse ACPI DMAR. Disabling VT-d. My grub.conf looks like this: kernel /xen.gz vga=mode-0x0317 vtd=1 iommu=1

I am getting the following on my 'new box' for my DNS server: Date: Wed, 20 Feb 2013 13:58:04 -0500 From: To: Subject: [abrt] full crash report User-Agent: Heirloom mailx 12.4 7/29/08 abrt_version: 2.0.8 cmdline: ro root=/dev/mapper/vg_onlo3-root_01 rd_NO_LUKS rd_LVM_LV=vg_onlo3/root_01 LANG=en_US.UTF-8 +rd_NO_MD SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us

Hi list, I have a problem with a new laptop (reproducable on other machines too) and the xen hypervisor. When the hypervisor gets booted with VESA mode 800x600 I see some messages and then the screen contents is switched into a pattern of vertical colored lines and never comes back. In text mode all works well, but later the pattern appears when the X servers starts. I disabled VTd in the bios

Hi, I did a git pull on pv_ops tree this morning and now get a crash when eth0 is started, here is the full boot log: Booting ''Xen 3.4 / Linux 2.6.29-rc6-tip'' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /xen.gz com1=115200,8n1 console=com1,vga iommu=1 [Multiboot-elf, <0x100000:0x131748:0x8e8b8>, shtab=0x2c0078, entry=0x100000] module

On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote: > I see work-arounds for broken IOMMUs but not for > individual devices. Could you point me to a more specific > example? I think the closest example is probably quirk_ioat_snb_local_iommu(). If we see this particular device, we *know* what the topology actually looks like. We check the hardware setup, and if we're *not*

On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote: > I see work-arounds for broken IOMMUs but not for > individual devices. Could you point me to a more specific > example? I think the closest example is probably quirk_ioat_snb_local_iommu(). If we see this particular device, we *know* what the topology actually looks like. We check the hardware setup, and if we're *not*

On 05/16/2014 06:08 AM, Jan Beulich wrote: >>>> On 16.05.14 at 10:58, <ijc at hellion.org.uk> wrote: >> So it seems like dom0 is unable to (correctly) bind to some hardware >> interrupts. I wonder if these messages from Xen's dmesg are relevant. >> (XEN) Not enabling x2APIC: depends on iommu_supports_eim. >> (XEN) I/O virtualisation disabled >>

On Mon, Apr 18, 2016 at 12:24:15PM -0700, Andy Lutomirski wrote: > On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > > the truth, and even legacy kernels ought to cope with that. > > FSVO 'ought to' where I suspect some of them will actually crash with a

On Mon, Apr 18, 2016 at 12:24:15PM -0700, Andy Lutomirski wrote: > On Mon, Apr 18, 2016 at 11:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > > For x86, you *can* enable virtio-behind-IOMMU if your DMAR tables tell > > the truth, and even legacy kernels ought to cope with that. > > FSVO 'ought to' where I suspect some of them will actually crash with a

On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: > On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: > >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel <joro at 8bytes.org> wrote: > >> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S.

On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote: > On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote: > >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel <joro at 8bytes.org> wrote: > >> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S.

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

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u3 Severity: grave Hello, I am trying to install the XEN Hypervisor on a Debian Jessie Server. When I am booting without the Hypervisor, everything works fine, but when I am Booting WITH the XEN-Hypervisor, then System crashes / reboots after the "Scrubbing Free RAM" Message without any Error-message, just a blank screen.

On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote: > I balk at adding more hacks to a broken system. My goals are > merely to > - make things work correctly with an IOMMU and new guests, > ? so people can use userspace drivers with virtio devices > - prevent security risks when guest kernel mistakenly thinks > ? it's protected by an IOMMU, but in fact isn't >

On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote: > I balk at adding more hacks to a broken system. My goals are > merely to > - make things work correctly with an IOMMU and new guests, > ? so people can use userspace drivers with virtio devices > - prevent security risks when guest kernel mistakenly thinks > ? it's protected by an IOMMU, but in fact isn't >

I'm trying to pass-through my VGA card to a guest session. I found: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM - which is very frustrating because there's no date on the documentation. I suspect it's old. It does clearly say that you must have VT-d support for pci pass-through. It then goes on to say "Some work towards allowing this ["software

Hi, on a Nehalem system with VT-d enabled we are seeing strange ACPI-Table contents, especially a corrupted DMAR entry. The hypervisor shows following data on boot: (XEN) ACPI: RSDP 000F80E0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT BF7C469E, 00D4 (r1 PTLTD XSDT 60000 LTP 0) (XEN) ACPI: FACP BF7C9CC9, 00F4 (r3 FSC TYLERBRG 60000 PTL F4240) (XEN) ACPI: DSDT BF7C4772, 54D3 (r1

https://bugs.freedesktop.org/show_bug.cgi?id=66696 Priority: medium Bug ID: 66696 Assignee: nouveau at lists.freedesktop.org Summary: Nouveau does DMA to/from unexpected address QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: stijn+bugs at