search for: drhd

...d *end, struct dmar_scope *scope, + int type, u16 seg) { - struct dmar_scope *scope = acpi_entry; struct acpi_ioapic_unit *acpi_ioapic_unit; const struct acpi_dmar_device_scope *acpi_scope; u16 bus, sub_bus, sec_bus; const struct acpi_dmar_pci_path *path; + struct acpi_drhd_unit *drhd = type == DMAR_TYPE ? + container_of(scope, struct acpi_drhd_unit, scope) : NULL; int depth, cnt, didx = 0; if ( (cnt = scope_device_count(start, end)) < 0 ) @@ -359,9 +361,8 @@ static int __init acpi_parse_dev_scope( dprintk(VTDPREFIX, " MSI H...

...(since only that much gets mapped). This covers the apparently not uncommon case of the address pointed to by a DMAR reading as all ones (Linux for example also checks for this). Further correct error handling of that function: Without storing the allocated "struct iommu" instance in the drhd, iommu_free() won''t do anything, and hence all successfully set up pieces would be leaked. Also keep iommu_free() from calling destroy_irq() when no irq was ever set up. Additionally, clear_fault_bits() has no need to read the capabilities field from I/O memory - it''s already ca...

Xen 3.4 xen-unstable.hg from yesterday with debian etch on 64bit arch Intel/Lenovo Q35 Mainboard with VT-d enabled Bootoptions iommu=1 vtd=1 pci.backhide for a PCI-E nvidia graphiccard xm dmesg Error messages includes: [VT-D] iommu.c: 1694:d32767 iommu: mapping reserved region failed [VT-D] iommu.c: 1542:d0 intel_iommu_add_device: context mapping failed If i try to start my HVM by xm create

...talked about using ACPI to report IOMMU bypass > to guest. > If that happens, we don't need a feature bit. I thought about this again, and I'm not sure anymore if we can use ACPI to "black-list" the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not...

...talked about using ACPI to report IOMMU bypass > to guest. > If that happens, we don't need a feature bit. I thought about this again, and I'm not sure anymore if we can use ACPI to "black-list" the incompatible virtio devices. Reason: hotplug. To my understanding, the ACPI DRHD tables won't change during runtime when a device shows up or disappears. We would have to isolate virtio devices from the rest of the system by using separate buses for it (and avoid listing those in any DRHD table) and enforce that they only get plugged into those buses. I suppose that is not...

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

...td/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Tue May 27 11:46:52 2008 +0100 +++ b/xen/drivers/passthrough/vtd/iommu.c Tue May 27 17:16:51 2008 +0100 @@ -1525,6 +1525,7 @@ struct iommu *iommu; struct dma_pte *page = NULL, *pte = NULL; u64 pg_maddr; + int pte_present; drhd = list_entry(acpi_drhd_units.next, typeof(*drhd), list); iommu = drhd->iommu; @@ -1540,6 +1541,7 @@ return -ENOMEM; page = (struct dma_pte *)map_vtd_domain_page(pg_maddr); pte = page + (gfn & LEVEL_MASK); + pte_present = dma_pte_present(*pte); dma_set_pte_addr...

...schmidt wrote: > On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: >> I thought about this again, and I'm not sure anymore if we can use >> ACPI >> to "black-list" the incompatible virtio devices. Reason: hotplug. To >> my >> understanding, the ACPI DRHD tables won't change during runtime when a >> device shows up or disappears. We would have to isolate virtio devices >> from the rest of the system by using separate buses for it (and avoid >> listing those in any DRHD table) and enforce that they only get >> plugged >...

...schmidt wrote: > On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: >> I thought about this again, and I'm not sure anymore if we can use >> ACPI >> to "black-list" the incompatible virtio devices. Reason: hotplug. To >> my >> understanding, the ACPI DRHD tables won't change during runtime when a >> device shows up or disappears. We would have to isolate virtio devices >> from the rest of the system by using separate buses for it (and avoid >> listing those in any DRHD table) and enforce that they only get >> plugged >...

...ult(struct iommu_page_fault_do_one(iommu, type, fault_reason, source_id, guest_addr); - /* Tell the device to stop DMAing; we can''t rely on the guest to - * control it for us. */ - cword = pci_conf_read16(iommu->intel->drhd->segment, - PCI_BUS(source_id), PCI_SLOT(source_id), - PCI_FUNC(source_id), PCI_COMMAND); - pci_conf_write16(iommu->intel->drhd->segment, PCI_BUS(source_id), - PCI_SLOT(source_id), PCI_FUNC(sour...

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 (cap_sps_2mb(iommu->cap)) + printk(", 2MB"); + + if (cap_sps_1gb(iommu->cap)) + printk(", 1GB"); + + printk(".\n"); + if ( iom...

...cted IOVA overflow (iova=0x1d40000030c0) qemu-system-x86_64: vtd_iommu_translate: detected translation failure (dev=00:03:00, iova=0x1d40000030c0) qemu-system-x86_64: New fault is not recorded due to compression of faults Guest kernel messages: [ 44.940872] DMAR: DRHD: handling fault status reg 2 [ 44.941989] DMAR: [DMA Read] Request device [00:03.0] PASID ffffffff fault addr ffff88W [ 49.785884] DMAR: DRHD: handling fault status reg 2 [ 49.788874] DMAR: [DMA Read] Request device [00:03.0] PASID ffffffff fault addr ffff88W QEMU...

...[ DRM] allocated 1920x1200 fb: 0x9000, bo ffff8808528bf800 [ 2.068437] fbcon: nouveaufb (fb0) is primary device [ 2.078765] nouveau [ DRM] 0xD1A1: Parsing digital output script table [ 2.139034] nouveau [ DRM] 0xD1F1: Parsing digital output script table [ 2.189610] dmar: DRHD: handling fault status reg 2 [ 2.189612] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 0 [ 2.189612] DMAR:[fault reason 06] PTE Read access is not set [ 2.190017] dmar: DRHD: handling fault status reg 102 [ 2.190019] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr...

...->flags; - if ( !iommu_enabled ) + if ( !iommu_enable && !iommu_intremap ) { ret = -EINVAL; goto out; --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -149,8 +149,7 @@ int iommu_supports_eim(void) struct acpi_drhd_unit *drhd; int apic; - if ( !iommu_enabled || !iommu_qinval || !iommu_intremap || - list_empty(&acpi_drhd_units) ) + if ( !iommu_qinval || !iommu_intremap || list_empty(&acpi_drhd_units) ) return 0; /* We MUST have a DRHD unit for each IOAPIC. */ --- a/...

On Wed, 2014-10-22 at 16:17 +0200, Jan Kiszka wrote: > I thought about this again, and I'm not sure anymore if we can use > ACPI > to "black-list" the incompatible virtio devices. Reason: hotplug. To > my > understanding, the ACPI DRHD tables won't change during runtime when a > device shows up or disappears. We would have to isolate virtio devices > from the rest of the system by using separate buses for it (and avoid > listing those in any DRHD table) and enforce that they only get > plugged > into those buse...

...mu=on' enabled in kernel cmdline, then reboot guest 3. log in guest to check: # dmesg | grep -i DMAR [ 0.000000] ACPI: DMAR 000000007d83f000 00050 (v01 BOCHS BXPCDMAR 00000001 BXPC 00000001) [ 0.000000] DMAR: IOMMU enabled [ 0.155178] DMAR: Host address width 39 [ 0.155180] DMAR: DRHD base: 0x000000fed90000 flags: 0x1 [ 0.155221] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 12008c22260286 ecap f00f5e [ 0.155228] DMAR: ATSR flags: 0x1 [ 0.155231] DMAR-IR: IOAPIC id 0 under DRHD base 0xfed90000 IOMMU 0 [ 0.155232] DMAR-IR: Queued invalidation will be enabled to sup...

Hello everyone, Reposting with after having applied the (minor) fixes suggested by Wei and Jan. Allen, if you can tell us what you think about this, or suggest someone else to ask some feedback to, if you''re no longer involved with VT-d, that would be great! :-) -- As already discussed here [1], dealing with IOMMU faults in interrupt context may cause nasty things to happen, up to

...d IOMMUs, > regardless of the underlying architecture. It isn't defined solely for the > ARM SMMU, but serves a more general purpose of describing a map of > device > identifiers communicated from one components to another. Both DMAR and > IVRS have such description (respectively DRHD and IVHD), but they are > designed for a specific IOMMU, whereas IORT could host other kinds. I'll take a look at IORT definition. DRHD includes information more than device mapping. > > It seems that all we really need is an interface that says "there is a > virtio-iommu at...

...d IOMMUs, > regardless of the underlying architecture. It isn't defined solely for the > ARM SMMU, but serves a more general purpose of describing a map of > device > identifiers communicated from one components to another. Both DMAR and > IVRS have such description (respectively DRHD and IVHD), but they are > designed for a specific IOMMU, whereas IORT could host other kinds. I'll take a look at IORT definition. DRHD includes information more than device mapping. > > It seems that all we really need is an interface that says "there is a > virtio-iommu at...

On Tue, 07 Oct 2014 18:24:22 -0700 Andy Lutomirski <luto at amacapital.net> wrote: > On 10/07/2014 07:39 AM, Cornelia Huck wrote: > > This patchset aims to get us some way to implement virtio-1 compliant > > and transitional devices in qemu. Branch available at > > > > git://github.com/cohuck/qemu virtio-1 > > > > I've mainly focused on: >