AMD IOMMU: Share p2m table with iommu
cover AMD IOMMU: Share p2m table with iommu
Hi,
This patch set implements p2m table sharing for amd iommu. Please comment it. Thanks,
Wei
--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd
Did you test your patch in Intel platform? I see that your patch change some common iommu logic code and it should not appropriate for intel platform. And this cause our device pass-through fail to work.
best regards
yang
Quoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 3 lines · Yang Z
Did you test your patch in Intel platform? I see that your patch change some common iommu logic code and it should not appropriate for intel platform. And this cause our device pass-through fail to work.
What's the failure mode? Or better, what change in the common code are you objecting to?
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform. Add allen to CC list. Maybe he can give a more authoritative answer.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +9 -1
@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif
@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +9 -2
@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */
p2m_mmio_dm = 4, /* Reads and write go to the device model */
@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty {
/* Type is stored in the "available" bits */ #ifdef __x86_64__
- return (flags >> 9) & 0x3fff;
+ /*
+ * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be
+ * used for iommu hardware to encode next io page level. Bit 59 - bit 62
+ * are used for iommu flags, We could not use these bits to store p2m types.
+ */
+
+ return (flags >> 12) & 0x7f;
#else
return (flags >> 9) & 0x7;#endif
Quoted 44 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 5 lines · Yang Z
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform.
Thank you. In what way does it fail?
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Thanks,
Tim.
Quoted 108 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +9
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +16
-3@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */ p2m_mmio_dm = 4, /* Reads and write go to the device model */@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 44 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 1 line
Thank you. In what way does it fail?
Guest with the device assigned cannot boot up. The guest disappeared when I run "xl create guest.config". And there have no error output in console, serial and qemu log.
Quoted 2 lines
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Yes, I also hit this issue with 23339.
Best regards
Yang
Quoted 129 lines
Thanks,
Tim.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 unsigned long p2m_type_to_flags(p2m_type { · line 83
Quoted 11 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11will be
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 unsigned long p2m_type_to_flags(p2m_type { · line 84
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * used for iommu hardware to encode next io page level. Bit 59 - bit62
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 unsigned long p2m_type_to_flags(p2m_type { · line 85
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * are used for iommu flags, We could not use these bits to store p2mtypes.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 static mfn_t p2m_gfn_to_mfn_current(stru · line 1832
Quoted 8 lines
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-0+ */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN|| !p2m_is_ram(p2mt));
Quoted 11 lines
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +3
-0+ if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 line 71
Quoted 9 lines
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +6
-0@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as0.
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100
Quoted 8 lines
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +3
-2+ */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silentlydropped */
Quoted 1 line
p2m_mmio_dm= 4, /* Reads and write go to the devicemodel */
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 static inline p2m_type_t p2m_flags_to_ty { · line 383
Quoted 5 lines
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +2
-1@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11will be
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 static inline p2m_type_t p2m_flags_to_ty { · line 384
Quoted 1 line
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * used for iommu hardware to encode next io page level. Bit 59 - bit62
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 static inline p2m_type_t p2m_flags_to_ty { · line 385
Quoted 1 line
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * are used for iommu flags, We could not use these bits to store p2mtypes.
Quoted 11 lines
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +3
-0+ */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 4 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Quoted 8 lines
Quoted 8 lines
Tim.
Quoted 6 lines
best regards
yangQuoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of WeiWang
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m tablewith
Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Quoted 24 lines
iommu
Hi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-develQuoted 4 lines
Quoted 4 lines
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
The problem appear to in part caused by unconditional call of get_insn_bytes() in hvm_function_table (cs# 23238). This function interface is defined for svm but not for vmx. However, it is call unconditionally from hvm_emulate_one(). For some reason it fails silently without any indication that it is dereferencing a null function pointer.
I see there are also other unconditional for nested functions nhvm* such as nhvm_vcpu_vmext_trap() and nhvm_intr_blocked() - which not defined in hvm_function_table for vmx.
What is the appropriate way to handle asymmetric function table definition between svm and vmx? Should the caller always check for whether the function is defined or not before calling it in generic code?
Allen
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 16, 2011 1:43 AM
To: Zhang, Yang Z
Cc: Wei Wang; [email protected]; Kay, Allen M
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
Quoted 5 lines · Yang Z
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform.
Thank you. In what way does it fail?
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Thanks,
Tim.
Quoted 108 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +9
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +16
-3@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */ p2m_mmio_dm = 4, /* Reads and write go to the device model */@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 44 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 5 lines · Allen M
The problem appear to in part caused by unconditional call of
get_insn_bytes()inhvm_function_table(cs# 23238). This function interface is defined for svm but not for vmx. However, it is call unconditionally fromhvm_emulate_one(). For some reason it fails silently without any indication that it is dereferencing a null function pointer.
As you subsequently noted, this is not true.
Quoted 7 lines
I see there are also other unconditional for nested functions nhvm* such as
nhvm_vcpu_vmext_trap()andnhvm_intr_blocked()- which not defined inhvm_function_tablefor vmx.What is the appropriate way to handle asymmetric function table definition between svm and vmx? Should the caller always check for whether the function is defined or not before calling it in generic code?
If needed, a NULL check in the calling wrapper would be appropriate. But be aware that every apparently naked call is almost certainly protected by a nestedhvm_enabled(d) check, which would never be TRUE on Intel.
IOW You haven't actually found any bugs yet. :-)
-- Keir
Quoted 135 lines
Allen
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 16, 2011 1:43 AM
To: Zhang, Yang Z
Cc: Wei Wang; [email protected]; Kay, Allen M
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuQuoted 5 lines · Yang Z
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform.
Thank you. In what way does it fail?
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Thanks,
Tim.
Quoted 110 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +4
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2mtypes.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +5
-0+ */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +13
-3@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */ p2m_mmio_dm = 4, /* Reads and write go to the device model */@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2mtypes.
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +3
-0+ */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 45 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Looking closer, I have found there is indeed a check in hvm_get_insn_bytes(). However, it should return 1 instead of 0 for hvm_funcs.get_insn_bytes undefined case so that original code gets called.
return (hvm_funcs.get_insn_bytes ? hvm_funcs.get_insn_bytes(v, buf) : 0);
Should be:
return (hvm_funcs.get_insn_bytes ? hvm_funcs.get_insn_bytes(v, buf) : 1);
-----Original Message-----
From: Kay, Allen M
Sent: Monday, May 16, 2011 5:13 PM
To: 'Tim Deegan'; Zhang, Yang Z; Keir Fraser
Cc: Wei Wang; [email protected]; '[email protected]'
Subject: RE: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
The problem appear to in part caused by unconditional call of get_insn_bytes() in hvm_function_table (cs# 23238). This function interface is defined for svm but not for vmx. However, it is call unconditionally from hvm_emulate_one(). For some reason it fails silently without any indication that it is dereferencing a null function pointer.
I see there are also other unconditional for nested functions nhvm* such as nhvm_vcpu_vmext_trap() and nhvm_intr_blocked() - which not defined in hvm_function_table for vmx.
What is the appropriate way to handle asymmetric function table definition between svm and vmx? Should the caller always check for whether the function is defined or not before calling it in generic code?
Allen
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 16, 2011 1:43 AM
To: Zhang, Yang Z
Cc: Wei Wang; [email protected]; Kay, Allen M
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
Quoted 5 lines · Yang Z
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform.
Thank you. In what way does it fail?
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Thanks,
Tim.
Quoted 108 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +9
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +16
-3@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */ p2m_mmio_dm = 4, /* Reads and write go to the device model */@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 44 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 9 lines · Allen M
Looking closer, I have found there is indeed a check in
hvm_get_insn_bytes(). However, it should return 1 instead of 0 for hvm_funcs.get_insn_bytes undefined case so that original code gets called.return (hvm_funcs.get_insn_bytes ? hvm_funcs.get_insn_bytes(v, buf) : 0);Should be:
return (hvm_funcs.get_insn_bytes ? hvm_funcs.get_insn_bytes(v, buf) : 1);
Ummm, no, it's correct as it is.
-- Keir
Quoted 157 lines
-----Original Message-----
From: Kay, Allen M
Sent: Monday, May 16, 2011 5:13 PM
To: 'Tim Deegan'; Zhang, Yang Z; Keir Fraser
Cc: Wei Wang; [email protected]; '[email protected]'
Subject: RE: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuThe problem appear to in part caused by unconditional call of
get_insn_bytes()inhvm_function_table(cs# 23238). This function interface is defined for svm but not for vmx. However, it is call unconditionally fromhvm_emulate_one(). For some reason it fails silently without any indication that it is dereferencing a null function pointer.I see there are also other unconditional for nested functions nhvm* such as
nhvm_vcpu_vmext_trap()andnhvm_intr_blocked()- which not defined inhvm_function_tablefor vmx.What is the appropriate way to handle asymmetric function table definition between svm and vmx? Should the caller always check for whether the function is defined or not before calling it in generic code?
Allen
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 16, 2011 1:43 AM
To: Zhang, Yang Z
Cc: Wei Wang; [email protected]; Kay, Allen M
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuQuoted 5 lines · Yang Z
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform.
Thank you. In what way does it fail?
Have you tested with 23300:4b0692880dfa applied? It's a fix on top of this change.
Thanks,
Tim.
Quoted 110 lines
Add allen to CC list. Maybe he can give a more authoritative answer.
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +4
-1@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2mtypes.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +5
-0+ */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {diff -r
51d89366c859-r78145a98915cxen/include/asm-x86/p2m.hxen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +13
-3@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */ p2m_mmio_dm = 4, /* Reads and write go to the device model */@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty { /* Type is stored in the "available" bits */ #ifdef __x86_64__ - return (flags >> 9) & 0x3fff; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2mtypes.
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +3
-0+ */ + + return (flags >> 12) & 0x7f; #else return (flags >> 9) & 0x7; #endifQuoted 45 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Yang is correct. I was confused by what appears to be QEMU VGA or xl related issues in older changesets.
The common code that caused problem is the following.
typedef enum {
- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */
With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns. We also see the following error messages during first guest boot:
....
(XEN) memory.c:196:d0 Bad page free for domain 1
(XEN) mm.c:2137:d0 Error pfn 0: rd=ffff8301c94c6000, od=ffff8301d8039000, caf=80 00000000000001, taf=7400000000000001
(XEN) memory.c:196:d0 Bad page free for domain 1
(XEN) mm.c:2137:d0 Error pfn 0: rd=ffff8301c94c6000, od=ffff8301d8039000, caf=80 00000000000001, taf=7400000000000001
(XEN) memory.c:196:d0 Bad page free for domain 1
(XEN) mm.c:2137:d0 Error pfn 0: rd=ffff8301c94c6000, od=ffff8301d8039000, caf=80 00000000000001, taf=7400000000000001
...
If I back out the above change, the latest changeset works again so this is the only change that causes the problem. I remember we had to do a lot of special treatment of p2m_invlid quite a bit during initial enabling of vt-d device passthrough.
Allen
-----Original Message-----
From: Zhang, Yang Z
Sent: Monday, May 16, 2011 1:36 AM
To: Tim Deegan
Cc: Wei Wang; [email protected]; Kay, Allen M
Subject: RE: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
Quoted 2 lines
What's the failure mode? Or better, what change in the common code are you objecting to?
The following patch cause the vt-d fail to work. I suspect that the change is not appropriate for intel platform. Add allen to CC list. Maybe he can give a more authoritative answer.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +9 -1
@@ -80,7 +80,12 @@ unsigned long p2m_type_to_flags(p2m_type { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12; #else flags = (t & 0x7UL) << 9; #endif
@@ -1826,6 +1831,9 @@ static mfn_t p2m_gfn_to_mfn_current(stru p2mt = p2m_flags_to_type(l1e_get_flags(l1e)); ASSERT(l1e_get_pfn(l1e) != INVALID_MFN || !p2m_is_ram(p2mt)); + if ( l1e.l1 == 0 ) + p2mt = p2m_invalid; + if ( p2m_flags_to_type(l1e_get_flags(l1e)) == p2m_populate_on_demand ) {
xen/include/asm-x86/p2m.h Mon Apr 18 17:24:21 2011 +0100 renamed from xen/include/asm-x86/p2m.h Mon Apr 18 15:12:04 2011 +0100 +9 -2
@@ -63,9 +63,15 @@ * Further expansions of the type system will only be supported on * 64-bit Xen. */ + +/* + * AMD IOMMU: When we share p2m table with iommu, bit 52 -bit 58 in pte + * cannot be non-zero, otherwise, hardware generates io page faults +when + * device access those pages. Therefore, p2m_ram_rw has to be defined as 0. + */ typedef enum { - p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */ p2m_ram_logdirty = 2, /* Temporarily read-only for log-dirty */ p2m_ram_ro = 3, /* Read-only; writes are silently dropped */
p2m_mmio_dm = 4, /* Reads and write go to the device model */
@@ -375,7 +381,13 @@ static inline p2m_type_t p2m_flags_to_ty {
/* Type is stored in the "available" bits */ #ifdef __x86_64__
- return (flags >> 9) & 0x3fff;
+ /*
+ * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be
+ * used for iommu hardware to encode next io page level. Bit 59 - bit 62
+ * are used for iommu flags, We could not use these bits to store p2m types.
+ */
+
+ return (flags >> 12) & 0x7f;
#else
return (flags >> 9) & 0x7;#endif
Quoted 44 lines
BTW, this is not the patch set that was applied; when I applied the revised patches (about a month ago) I CC'd the Intel IOMMU maintainer.
Tim.
Quoted 33 lines
best regards
yangQuoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Wei Wang
Sent: Friday, March 25, 2011 6:32 PM
To: [email protected]
Subject: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
This patch set implements p2m table sharing for amd iommu. Please comment it.
Thanks,
Wei--
Advanced Micro Devices GmbH
Sitz: Dornach, Gemeinde Aschheim,
Landkreis München Registergericht München,
HRB Nr. 43632
WEEE-Reg-Nr: DE 12919551
Geschäftsführer:
Alberto Bozzo, Andrew Bowd_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Hi,
Quoted 10 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +2
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than ram_rw (e.g. ram_ro).
In the meantime, Allen, does the attached patch make things any better for you?
Cheers,
Tim.
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
xen/arch/x86/mm/p2m-ept.c +6 -1
@@ -586,6 +586,11 @@ static mfn_t ept_get_entry(struct p2m_do *t = ept_entry->sa_p2mt; *a = ept_entry->access; +if (p2m_has_emt (ept_entry->sa_p2mt) + && (!is_epte_present (ept_entry) || ept_entry->mfn ==0 ) ) +printk ("Bad EPT entry %" PRIx64" for GFN %lx\n" , + ept_entry->epte, gfn) + mfn = _mfn(ept_entry->mfn);if ( i ) {
@@ -736,7 +741,7 @@ void ept_change_entry_emt_with_range(struint64_t trunk =0 ; e =ept_get_entry_content (p2m, gfn, &level); -if ( !p2m_has_emt (e.sa_p2mt) ) +if ( !is_epte_present (&e) || !p2m_has_emt (e.sa_p2mt) )continue ; order =0 ;
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 18 lines · On Monday 23 May 2011 12:58:00 Tim Deegan wrote:
Hi,
Quoted 10 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +2
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Quoted 5 lines
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).
Tim,
Theoretically, we just need to keep bit 52 - bit 58 all zero for valid dma translation entry. Probably we could define ram_rw as 11000000000b, which is the valid r/w permission for iommu and leaves bit 52 - 58 zero? Thanks,
Wei
Quoted 6 lines
In the meantime, Allen, does the attached patch make things any better for you?
Cheers,
Tim.
Hi,
Quoted 10 lines · At 13:08 +0100 on 23 May (1306156129), Wei Wang2 wrote:
Quoted 9 lines
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).
Quoted 3 lines
Theoretically, we just need to keep bit 52 - bit 58 all zero for valid dma translation entry. Probably we could define
ram_rwas11000000000b, which is the valid r/w permission for iommu and leaves bit 52 - 58 zero?
Ugh; no, that will break EPT as well, and restricts us to only one accessible type. It looks like there are no bits that are available in both normal pagetable and IOMMU pagetables. How inconvenient.
So our only options are to harden the rest of the p2m code against blank entries looking like RAM, or to avoid sharing pagetables between p2m and AMD IOMMU. :( I guess that depends on how much of a PITA it'll be to track down the rest of the places where EPT code trips over itself. Maybe we should replace the clear_page() in allocating p2m pages with a loop that explicitly makes everything p2m_invalid. It's not a terribly hot path, after all.
But even if we do that, don't you want read-only and grant-mapped memory to work with the IOMMU?
Tim.
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 13 lines
Hi,
Quoted 10 lines · At 13:08 +0100 on 23 May (1306156129), Wei Wang2 wrote:
Quoted 9 lines
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).
Quoted 7 lines
Quoted 3 lines
Theoretically, we just need to keep bit 52 - bit 58 all zero for valid dma translation entry. Probably we could define
ram_rwas11000000000b, which is the valid r/w permission for iommu and leaves bit 52 - 58 zero?Ugh; no, that will break EPT as well, and restricts us to only one accessible type. It looks like there are no bits that are available in both normal pagetable and IOMMU pagetables. How inconvenient.
OK, understand. Indeed there are no bits available to use. I am not strictly against reversing this patch, if this causes too much changes for vtd.
Quoted 10 lines
So our only options are to harden the rest of the p2m code against blank entries looking like RAM, or to avoid sharing pagetables between p2m and AMD IOMMU. :( I guess that depends on how much of a PITA it'll be to track down the rest of the places where EPT code trips over itself. Maybe we should replace the
clear_page()in allocating p2m pages with a loop that explicitly makes everythingp2m_invalid. It's not a terribly hot path, after all.But even if we do that, don't you want read-only and grant-mapped memory to work with the IOMMU?
Ture, we lose grant mapping and RO here. But what is the use case of iommu using RO and grant-mapping in hvm? For hvm, since we could not know which parts of memory are actually used by dma transaction, should it be more safe that only r/w pages are accessed by iommu through p2m?
Thanks,
Wei
Quoted 1 line
Tim.
Another question? Does this change ok? How to covert the p2m_type whose value great than 7 to flags, like the type p2m_ram_shared which equal to 13?
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +6 -1
@@ -80,7 +80,12 @@ { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12;
best regards
yang
Quoted 42 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 6:58 PM
To: Kay, Allen M
Cc: Zhang, Yang Z; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
Quoted 10 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +2
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).In the meantime, Allen, does the attached patch make things any better for you?
Cheers,
Tim.
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 3 lines · Yang Z
Another question? Does this change ok? How to covert the
p2m_typewhose value great than 7 to flags, like the typep2m_ram_sharedwhich equal to 13?
The mask is 7F, not 7.
Tim.
Quoted 61 lines
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +6
-1@@ -80,7 +80,12 @@ { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be + * used for iommu hardware to encode next io page level. Bit 59 - bit 62 + * are used for iommu flags, We could not use these bits to store p2m types. + */ + flags = (unsigned long)(t & 0x7f) << 12;best regards
yangQuoted 42 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 6:58 PM
To: Kay, Allen M
Cc: Zhang, Yang Z; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuHi,
Quoted 10 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +2
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).In the meantime, Allen, does the attached patch make things any better for you?
Cheers,
Tim.
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
No, I mean 0x3fff doesn't mask the low 14 bits but 0x7f only leave the low 7 bits. How I get the p2m_type which between 8 to 14 bit?
best regards
yang
Quoted 91 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 9:41 PM
To: Zhang, Yang Z
Cc: Kay, Allen M; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuQuoted 3 lines · Yang Z
Another question? Does this change ok? How to covert the
p2m_typewhose value great than 7 to flags, like the typep2m_ram_sharedwhich equal to 13?The mask is 7F, not 7.
Tim.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 84
Quoted 10 lines
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-1@@ -80,7 +80,12 @@ { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11will be
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 85
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * used for iommu hardware to encode next io page level. Bit 59 - bit62
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 86
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * are used for iommu flags, We could not use these bits to store p2mtypes.
Quoted 13 lines
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-0+ */ + flags = (unsigned long)(t & 0x7f) << 12;best regards
yangQuoted 6 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 6:58 PM
To: Kay, Allen M
Cc: Zhang, Yang Z; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m tablewith
Quoted 10 lines
Quoted 10 lines
iommu
Hi,
Quoted 5 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +0
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM*/
Quoted 1 line
Quoted 1 line
Quoted 1 line
+
p2m_ram_rw= 0, /* Normal read/write guest RAM*/
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
+
p2m_invalid= 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so
we
Quoted 1 line
Quoted 1 line
can store the p2m type somewhere that's not required to be zero? If not,
I'm
Quoted 6 lines
Quoted 6 lines
inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).In the meantime, Allen, does the attached patch make things any better for you?
Quoted 8 lines
Quoted 8 lines
Cheers,
Tim.
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 2 lines · Yang Z
No, I mean
0x3fffdoesn't mask the low 14 bits but0x7fonly leave the low 7 bits. How I get thep2m_typewhich between 8 to 14 bit?
p2m_types lie between 0 and 14, i.e. four bits. Cutting from 14 bits to 7 bits still leaves space for another 113 types.
Tim.
Quoted 95 lines
best regards
yangQuoted 91 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 9:41 PM
To: Zhang, Yang Z
Cc: Kay, Allen M; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommuQuoted 3 lines · Yang Z
Another question? Does this change ok? How to covert the
p2m_typewhose value great than 7 to flags, like the typep2m_ram_sharedwhich equal to 13?The mask is 7F, not 7.
Tim.
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 84
Quoted 10 lines
diff -r
51d89366c859-r78145a98915cxen/arch/x86/mm/p2m.cxen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-1@@ -80,7 +80,12 @@ { unsigned long flags; #ifdef __x86_64__ - flags = (unsigned long)(t & 0x3fff) << 9; + /* + * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11will be
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 85
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * used for iommu hardware to encode next io page level. Bit 59 - bit62
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 line 86
Quoted 1 line
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +1
-0+ * are used for iommu flags, We could not use these bits to store p2mtypes.
Quoted 13 lines
xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100 renamed from xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100 +2
-0+ */ + flags = (unsigned long)(t & 0x7f) << 12;best regards
yangQuoted 6 lines
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 6:58 PM
To: Kay, Allen M
Cc: Zhang, Yang Z; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m tablewith
Quoted 10 lines
Quoted 10 lines
iommu
Hi,
Quoted 5 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +0
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM*/
Quoted 1 line
Quoted 1 line
Quoted 1 line
+
p2m_ram_rw= 0, /* Normal read/write guest RAM*/
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
+
p2m_invalid= 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so
we
Quoted 1 line
Quoted 1 line
can store the p2m type somewhere that's not required to be zero? If not,
I'm
Quoted 6 lines
Quoted 6 lines
inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than
ram_rw(e.g.ram_ro).In the meantime, Allen, does the attached patch make things any better for you?
Quoted 8 lines
Quoted 8 lines
Cheers,
Tim.
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 1 line
In the meantime, Allen, does the attached patch make things any better for you?
Yes, your patch fixed the issue ... just missing a ";".
Allen
-----Original Message-----
From: Tim Deegan [mailto:[email protected]]
Sent: Monday, May 23, 2011 3:58 AM
To: Kay, Allen M
Cc: Zhang, Yang Z; Wei Wang; [email protected]
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
Hi,
Quoted 10 lines · Allen M
The common code that caused problem is the following.
typedef enum {
(quoted diff) +2
-2- p2m_invalid = 0, /* Nothing mapped here */ - p2m_ram_rw = 1, /* Normal read/write guest RAM */ + p2m_ram_rw = 0, /* Normal read/write guest RAM */ + p2m_invalid = 1, /* Nothing mapped here */With the above change, guest with device direct assignment fails to boot. QEMU VGA displays some weird color patterns.
Unfortunately this change seems to be necessary for AMD IOMMU to share pagetables with the p2m. I'd rather we didn't have it, because it means empty ptes look like RAM mappings of frame 0. :(
Wei, is there any way we can reorganise the AMD IOMMU pagetables so we can store the p2m type somewhere that's not required to be zero? If not, I'm inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least we'd like to be able to handle types other than ram_rw (e.g. ram_ro).
In the meantime, Allen, does the attached patch make things any better for you?
Cheers,
Tim.
--
Tim Deegan <[email protected]>
Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
Quoted 3 lines · Allen M
Quoted 1 line
In the meantime, Allen, does the attached patch make things any better for you?
Yes, your patch fixed the issue ... just missing a ";".
Great. I've applied the useful part; I think that grants a stay of execution to the AMD p2m-sharing patch.
Cheers,
Tim.
Signature · 3 lines
Tim Deegan <[email protected]> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)