Displaying 8 results from an estimated 8 matches for "acpi_drhd_units".
Did you mean:
acpi_drhd_unit
2012 Nov 28
2
[PATCH] VT-d: make scope parsing code type safe
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
2012 Oct 24
5
[PATCH v3] IOMMU: keep disabled until iommu_setup() is called
...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/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2086,7 +2086,10 @@ int __init intel_vtd_setup(void)...
2008 May 27
3
[PATCH] VT-d: IOTLB flush fixups
...en/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(*pte, (paddr_t)mfn <<...
2012 Jan 05
9
[PATCHv2 0 of 2] Deal with IOMMU faults in softirq context.
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
2013 Mar 19
7
[PATCH 0/3] IOMMU errata treatment adjustments
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
2010 Mar 11
0
[PATCH] VT-d: various initialization fixes
Detect invalid/unsupported configurations in iommu_alloc() - offsets
read from hardware must not lead to exceeding a single page (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
2008 Jul 14
14
Workaround for the corrupted Intel X48 DMAR table
hi,
I am trying the Xen unstable on X48 chipset these days but it failed due to
an corrupted RMRR table in the ACPI. The following is the acpi dump of DMAR.
DMAR @ 0x7fef1000
0000: 44 4d 41 52 20 01 00 00 01 d1 49 4e 54 45 4c 20 DMAR .....INTEL
0010: 44 58 34 38 42 54 32 20 12 06 00 00 4d 53 46 54 DX48BT2 ....MSFT
0020: 13 00 00 01 23 00 00 00 00 00 00 00 00 00 00 00 ....#...........
2010 Sep 17
27
Problem: Pattern with vertical colored lines on the dom0 screen
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