In one of my previous email I detailed a bug I was seeing when passing
through a Intel GPU on a guest that has more that 4G or RAM.
Allen suggested that I go for the Plan B but after a discussion with Tim
we agreed that Plan B was way to disruptive in term of code change.
This patch series implements Plan A.
http://xen.1045712.n5.nabble.com/VTD-Intel-iommu-IOTLB-flush-really-slow-td4952866.html
Changes between v2 and v3:
- Check for the presence iotlb_flush_all callback before calling it.
Changes between v1 and v2:
- Move size in struct xen_add_to_physmap in padding between .domid and
.space.
- Store iommu_dont_flush per cpu
- Change the code in hvmloader to relocate by batch of 64K, .size is now
16 bits.
Jean Guyader (6):
vtd: Refactor iotlb flush code
iommu: Introduce iommu_flush and iommu_flush_all.
add_to_physmap: Move the code for XENMEM_add_to_physmap.
mm: New XENMEM, XENMEM_add_to_physmap_gmfn_range
hvmloader: Change memory relocation loop when overlap with PCI hole.
Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb
flush
tools/firmware/hvmloader/pci.c | 20 +++-
xen/arch/x86/mm.c | 203 +++++++++++++++++++++--------------
xen/drivers/passthrough/iommu.c | 25 +++++
xen/drivers/passthrough/vtd/iommu.c | 100 ++++++++++--------
xen/include/public/memory.h | 4 +
xen/include/xen/iommu.h | 7 ++
6 files changed, 230 insertions(+), 129 deletions(-)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Factorize the iotlb flush code from map_page and unmap_page into it''s own function. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- 1 files changed, 43 insertions(+), 43 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-07 18:25 UTC
[Xen-devel] [PATCH 2/6] iommu: Introduce iommu_flush and iommu_flush_all.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- xen/drivers/passthrough/iommu.c | 20 ++++++++++++++++++++ xen/drivers/passthrough/vtd/iommu.c | 12 ++++++++++++ xen/include/xen/iommu.h | 5 +++++ 3 files changed, 37 insertions(+), 0 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-07 18:25 UTC
[Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for XENMEM_add_to_physmap.
Move the code for the XENMEM_add_to_physmap case into it''s own function (xenmem_add_to_physmap). Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- xen/arch/x86/mm.c | 188 ++++++++++++++++++++++++++++------------------------- 1 files changed, 99 insertions(+), 89 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-07 18:25 UTC
[Xen-devel] [PATCH 4/6] mm: New XENMEM, XENMEM_add_to_physmap_gmfn_range
XENMEM_add_to_physmap_gmfn_range is like XENMEM_add_to_physmap on the gmfn space but the number of pages on which xen will iterate. Use the 16 bits padding between .domid and .space in struct xen_add_to_physmap to keep compatibility with older versions. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- xen/arch/x86/mm.c | 22 +++++++++++++++++++++- xen/include/public/memory.h | 4 ++++ 2 files changed, 25 insertions(+), 1 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-07 18:25 UTC
[Xen-devel] [PATCH 5/6] hvmloader: Change memory relocation loop when overlap with PCI hole.
Change the way we relocate the memory page if they overlap with pci hole. Use new map space (XENMAPSPACE_gmfn_range) to move the loop into xen. This code usually get triggered when a device is pass through to a guest and the PCI hole has to be extended to have enough room to map the device BARs. The PCI hole will starts lower and it might overlap with some RAM that has been alocated for the guest. That usually happen if the guest has more than 4G of RAM. We have to relocate those pages in high mem otherwise they won''t be accessible. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- tools/firmware/hvmloader/pci.c | 20 ++++++++++++++------ 1 files changed, 14 insertions(+), 6 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-07 18:25 UTC
[Xen-devel] [PATCH 6/6] Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
Add cpu flag that will be checked by the iommu low level code to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> --- xen/arch/x86/mm.c | 15 ++++++++++++++- xen/drivers/passthrough/iommu.c | 5 +++++ xen/drivers/passthrough/vtd/iommu.c | 6 ++++-- xen/include/xen/iommu.h | 2 ++ 4 files changed, 25 insertions(+), 3 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2011-Nov-08 03:10 UTC
[Xen-devel] RE: [PATCH 1/6] vtd: Refactor iotlb flush code
Jean,
The original code does not call iommu_flush_iotlb_dsi(). What is the reason the
refractored code need to use domain selective invalidation?
Allen
-----
+ if ( page_count > 1 || gfn == -1 )
+ {
+ if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
+ 0, flush_dev_iotlb) )
+ iommu_flush_write_buffer(iommu);
+ }
+ else
+ {
+ if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
+ (paddr_t)gfn << PAGE_SHIFT_4K, 0,
+ !dma_old_pte_present, flush_dev_iotlb) )
+ iommu_flush_write_buffer(iommu);
-----Original Message-----
From: Jean Guyader [mailto:jean.guyader@eu.citrix.com]
Sent: Monday, November 07, 2011 10:25 AM
To: xen-devel@lists.xensource.com
Cc: tim@xen.org; Kay, Allen M; Jean Guyader
Subject: [PATCH 1/6] vtd: Refactor iotlb flush code
Factorize the iotlb flush code from map_page and unmap_page into it's own
function.
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++-----------------
1 files changed, 43 insertions(+), 43 deletions(-)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-08 07:42 UTC
[Xen-devel] Re: [PATCH 1/6] vtd: Refactor iotlb flush code
Allen, You are probably talking about __intel_iommu_iotlb_flush. This function takes a range of address to flush. I haven''t found a function in the vtd code to invalidate a range on address without doing a loop of flush_iotlb_psi, so I thought that the most efficient and quick way to flush a range would be to use a domain selective invalidation. Jean On 08/11 03:10, Kay, Allen M wrote:> Jean, > > The original code does not call iommu_flush_iotlb_dsi(). What is the reason the refractored code need to use domain selective invalidation? > > Allen > ----- > > + if ( page_count > 1 || gfn == -1 ) > + { > + if ( iommu_flush_iotlb_dsi(iommu, iommu_domid, > + 0, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > + } > + else > + { > + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, > + (paddr_t)gfn << PAGE_SHIFT_4K, 0, > + !dma_old_pte_present, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > > -----Original Message----- > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > Sent: Monday, November 07, 2011 10:25 AM > To: xen-devel@lists.xensource.com > Cc: tim@xen.org; Kay, Allen M; Jean Guyader > Subject: [PATCH 1/6] vtd: Refactor iotlb flush code > > > Factorize the iotlb flush code from map_page and unmap_page into it''s own function. > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > --- > xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- > 1 files changed, 43 insertions(+), 43 deletions(-) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Nov-08 09:20 UTC
Re: [Xen-devel] [PATCH 4/6] mm: New XENMEM, XENMEM_add_to_physmap_gmfn_range
>>> On 07.11.11 at 19:25, Jean Guyader <jean.guyader@eu.citrix.com> wrote:Sorry, noticed this only now, but neither title nor description of this are in sync with the actual patch. Jan> XENMEM_add_to_physmap_gmfn_range is like XENMEM_add_to_physmap on > the gmfn space but the number of pages on which xen will iterate. > > Use the 16 bits padding between .domid and .space in struct > xen_add_to_physmap > to keep compatibility with older versions. > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > --- > xen/arch/x86/mm.c | 22 +++++++++++++++++++++- > xen/include/public/memory.h | 4 ++++ > 2 files changed, 25 insertions(+), 1 deletions(-)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Nov-08 13:24 UTC
Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for XENMEM_add_to_physmap.
At 18:25 +0000 on 07 Nov (1320690324), Jean Guyader wrote:> > Move the code for the XENMEM_add_to_physmap case into it''s own > function (xenmem_add_to_physmap). > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>Acked-by: Tim Deegan <tim@xen.org> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Nov-08 13:32 UTC
Re: [Xen-devel] [PATCH 4/6] mm: New XENMEM, XENMEM_add_to_physmap_gmfn_range
At 02:20 -0700 on 08 Nov (1320718835), Jan Beulich wrote:> >>> On 07.11.11 at 19:25, Jean Guyader <jean.guyader@eu.citrix.com> wrote: > > Sorry, noticed this only now, but neither title nor description of this > are in sync with the actual patch.Indeed; they should be updated. But otherwise: Acked-by: Tim Deegan <tim@xen.org>> > XENMEM_add_to_physmap_gmfn_range is like XENMEM_add_to_physmap on > > the gmfn space but the number of pages on which xen will iterate. > > > > Use the 16 bits padding between .domid and .space in struct > > xen_add_to_physmap > > to keep compatibility with older versions. > > > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > > --- > > xen/arch/x86/mm.c | 22 +++++++++++++++++++++- > > xen/include/public/memory.h | 4 ++++ > > 2 files changed, 25 insertions(+), 1 deletions(-) > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Nov-08 13:39 UTC
Re: [Xen-devel] [PATCH 4/6] mm: New XENMEM, XENMEM_add_to_physmap_gmfn_range
At 13:32 +0000 on 08 Nov (1320759148), Tim Deegan wrote:> At 02:20 -0700 on 08 Nov (1320718835), Jan Beulich wrote: > > >>> On 07.11.11 at 19:25, Jean Guyader <jean.guyader@eu.citrix.com> wrote: > > > > Sorry, noticed this only now, but neither title nor description of this > > are in sync with the actual patch. > > > Indeed; they should be updated. But otherwise: > Acked-by: Tim Deegan <tim@xen.org>No, wait, that was the other patch, which I already acked! ENOCOFFEE. :( I have a few other comments on this patch...> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index f75011e..cca64b8 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4714,9 +4714,29 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg) > return -EPERM; > } > > - xenmem_add_to_physmap(d, xatp); > + if ( xatp.space != XENMAPSPACE_gmfn_range ) > + xatp.size = 1; > + > + for ( ; xatp.size > 0; xatp.size-- ) > + { > + if ( hypercall_preempt_check() ) > + { > + rc = -EAGAIN; > + break; > + } > + xenmem_add_to_physmap(d, xatp); > + xatp.idx++; > + xatp.gpfn++; > + }Having moved XATP into its own function, this loop probably belongs in that function. While I''m looking at it, updating two loop vars explicitly and one in the header is a bit ugly - why not just use a while() and update all three together?> rcu_unlock_domain(d); > + if ( rc == -EAGAIN ) > + { > + if ( copy_to_guest(arg, &xatp, 1) ) > + return -EFAULT; > + rc = hypercall_create_continuation( > + __HYPERVISOR_memory_op, "ih", op, arg); > + }I think this might need some compat glue in arch/x86/x86_64/compat/mm.c for it to work with 32-bit callers. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Nov-08 13:45 UTC
Re: [Xen-devel] [PATCH 6/6] Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
At 18:25 +0000 on 07 Nov (1320690327), Jean Guyader wrote:> > Add cpu flag that will be checked by the iommu low level code > to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.The general approach is OK. I think the explicit flush on the xatp path belongs in the inner xatp function, along with the reat of the loop. Also, please add a comment beside the declaration in iommu.h to explain what the falg does and how it should be used. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2011-Nov-09 02:41 UTC
[Xen-devel] RE: [PATCH 1/6] vtd: Refactor iotlb flush code
Jean, Page 122 of VT-d spec indicates you can invalidate multiple pages by setting the Address Mask (AM) field. Will this achieve what you wanted to do? http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf Allen -----Original Message----- From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] Sent: Monday, November 07, 2011 11:42 PM To: Kay, Allen M Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) Subject: Re: [PATCH 1/6] vtd: Refactor iotlb flush code Allen, You are probably talking about __intel_iommu_iotlb_flush. This function takes a range of address to flush. I haven''t found a function in the vtd code to invalidate a range on address without doing a loop of flush_iotlb_psi, so I thought that the most efficient and quick way to flush a range would be to use a domain selective invalidation. Jean On 08/11 03:10, Kay, Allen M wrote:> Jean, > > The original code does not call iommu_flush_iotlb_dsi(). What is the reason the refractored code need to use domain selective invalidation? > > Allen > ----- > > + if ( page_count > 1 || gfn == -1 ) > + { > + if ( iommu_flush_iotlb_dsi(iommu, iommu_domid, > + 0, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > + } > + else > + { > + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, > + (paddr_t)gfn << PAGE_SHIFT_4K, 0, > + !dma_old_pte_present, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > > -----Original Message----- > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > Sent: Monday, November 07, 2011 10:25 AM > To: xen-devel@lists.xensource.com > Cc: tim@xen.org; Kay, Allen M; Jean Guyader > Subject: [PATCH 1/6] vtd: Refactor iotlb flush code > > > Factorize the iotlb flush code from map_page and unmap_page into it''s own function. > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > --- > xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- > 1 files changed, 43 insertions(+), 43 deletions(-) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2011-Nov-09 02:50 UTC
[Xen-devel] RE: [PATCH 1/6] vtd: Refactor iotlb flush code
The fourth parameter, currently 0, is supposed to be the AM field. It is named order now. + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, + (paddr_t)gfn << PAGE_SHIFT_4K, 0, + !dma_old_pte_present, flush_dev_iotlb) ) -----Original Message----- From: Kay, Allen M Sent: Tuesday, November 08, 2011 6:42 PM To: ''Jean Guyader'' Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) Subject: RE: [PATCH 1/6] vtd: Refactor iotlb flush code Jean, Page 122 of VT-d spec indicates you can invalidate multiple pages by setting the Address Mask (AM) field. Will this achieve what you wanted to do? http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf Allen -----Original Message----- From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] Sent: Monday, November 07, 2011 11:42 PM To: Kay, Allen M Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) Subject: Re: [PATCH 1/6] vtd: Refactor iotlb flush code Allen, You are probably talking about __intel_iommu_iotlb_flush. This function takes a range of address to flush. I haven''t found a function in the vtd code to invalidate a range on address without doing a loop of flush_iotlb_psi, so I thought that the most efficient and quick way to flush a range would be to use a domain selective invalidation. Jean On 08/11 03:10, Kay, Allen M wrote:> Jean, > > The original code does not call iommu_flush_iotlb_dsi(). What is the reason the refractored code need to use domain selective invalidation? > > Allen > ----- > > + if ( page_count > 1 || gfn == -1 ) > + { > + if ( iommu_flush_iotlb_dsi(iommu, iommu_domid, > + 0, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > + } > + else > + { > + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, > + (paddr_t)gfn << PAGE_SHIFT_4K, 0, > + !dma_old_pte_present, flush_dev_iotlb) ) > + iommu_flush_write_buffer(iommu); > > -----Original Message----- > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > Sent: Monday, November 07, 2011 10:25 AM > To: xen-devel@lists.xensource.com > Cc: tim@xen.org; Kay, Allen M; Jean Guyader > Subject: [PATCH 1/6] vtd: Refactor iotlb flush code > > > Factorize the iotlb flush code from map_page and unmap_page into it''s own function. > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > --- > xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- > 1 files changed, 43 insertions(+), 43 deletions(-) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Guyader
2011-Nov-09 22:15 UTC
[Xen-devel] Re: [PATCH 1/6] vtd: Refactor iotlb flush code
Allen, The addresses in input are not necessarily aligned, to be able to use this feature I will have to break the range into aligned chunks of different sizes and flush them separatly. I personally don''t think this optimization is worth the effort. Jean On 09/11 02:41, Kay, Allen M wrote:> Jean, > > Page 122 of VT-d spec indicates you can invalidate multiple pages by setting the Address Mask (AM) field. Will this achieve what you wanted to do? > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf > > Allen > > -----Original Message----- > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > Sent: Monday, November 07, 2011 11:42 PM > To: Kay, Allen M > Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) > Subject: Re: [PATCH 1/6] vtd: Refactor iotlb flush code > > > Allen, > > You are probably talking about __intel_iommu_iotlb_flush. > This function takes a range of address to flush. I haven''t found a function in the vtd code to invalidate a range on address without doing a loop of flush_iotlb_psi, so I thought that the most efficient and quick way to flush a range would be to use a domain selective invalidation. > > Jean > > On 08/11 03:10, Kay, Allen M wrote: > > Jean, > > > > The original code does not call iommu_flush_iotlb_dsi(). What is the reason the refractored code need to use domain selective invalidation? > > > > Allen > > ----- > > > > + if ( page_count > 1 || gfn == -1 ) > > + { > > + if ( iommu_flush_iotlb_dsi(iommu, iommu_domid, > > + 0, flush_dev_iotlb) ) > > + iommu_flush_write_buffer(iommu); > > + } > > + else > > + { > > + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, > > + (paddr_t)gfn << PAGE_SHIFT_4K, 0, > > + !dma_old_pte_present, flush_dev_iotlb) ) > > + iommu_flush_write_buffer(iommu); > > > > -----Original Message----- > > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > > Sent: Monday, November 07, 2011 10:25 AM > > To: xen-devel@lists.xensource.com > > Cc: tim@xen.org; Kay, Allen M; Jean Guyader > > Subject: [PATCH 1/6] vtd: Refactor iotlb flush code > > > > > > Factorize the iotlb flush code from map_page and unmap_page into it''s own function. > > > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > > --- > > xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- > > 1 files changed, 43 insertions(+), 43 deletions(-) > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2011-Nov-09 23:25 UTC
[Xen-devel] RE: [PATCH 1/6] vtd: Refactor iotlb flush code
Jean, I think this is fine. Ack for VT-d related changes. Allen -----Original Message----- From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] Sent: Wednesday, November 09, 2011 2:16 PM To: Kay, Allen M Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) Subject: Re: [PATCH 1/6] vtd: Refactor iotlb flush code Allen, The addresses in input are not necessarily aligned, to be able to use this feature I will have to break the range into aligned chunks of different sizes and flush them separatly. I personally don''t think this optimization is worth the effort. Jean On 09/11 02:41, Kay, Allen M wrote:> Jean, > > Page 122 of VT-d spec indicates you can invalidate multiple pages by setting the Address Mask (AM) field. Will this achieve what you wanted to do? > > http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_ > Direct_IO.pdf > > Allen > > -----Original Message----- > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > Sent: Monday, November 07, 2011 11:42 PM > To: Kay, Allen M > Cc: Jean Guyader; xen-devel@lists.xensource.com; Tim (Xen.org) > Subject: Re: [PATCH 1/6] vtd: Refactor iotlb flush code > > > Allen, > > You are probably talking about __intel_iommu_iotlb_flush. > This function takes a range of address to flush. I haven''t found a function in the vtd code to invalidate a range on address without doing a loop of flush_iotlb_psi, so I thought that the most efficient and quick way to flush a range would be to use a domain selective invalidation. > > Jean > > On 08/11 03:10, Kay, Allen M wrote: > > Jean, > > > > The original code does not call iommu_flush_iotlb_dsi(). What is the reason the refractored code need to use domain selective invalidation? > > > > Allen > > ----- > > > > + if ( page_count > 1 || gfn == -1 ) > > + { > > + if ( iommu_flush_iotlb_dsi(iommu, iommu_domid, > > + 0, flush_dev_iotlb) ) > > + iommu_flush_write_buffer(iommu); > > + } > > + else > > + { > > + if ( iommu_flush_iotlb_psi(iommu, iommu_domid, > > + (paddr_t)gfn << PAGE_SHIFT_4K, 0, > > + !dma_old_pte_present, flush_dev_iotlb) ) > > + iommu_flush_write_buffer(iommu); > > > > -----Original Message----- > > From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] > > Sent: Monday, November 07, 2011 10:25 AM > > To: xen-devel@lists.xensource.com > > Cc: tim@xen.org; Kay, Allen M; Jean Guyader > > Subject: [PATCH 1/6] vtd: Refactor iotlb flush code > > > > > > Factorize the iotlb flush code from map_page and unmap_page into it''s own function. > > > > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> > > --- > > xen/drivers/passthrough/vtd/iommu.c | 86 +++++++++++++++++----------------- > > 1 files changed, 43 insertions(+), 43 deletions(-) > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel