[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH 2/2] Introduce xen_swiotlb variable that is set when Xen is running.



On 09/24/09 16:37, Jeremy Fitzhardinge wrote:
> On 09/24/09 15:43, Konrad Rzeszutek Wilk wrote:
>   
>> Having the 'xen_swiotlb' variable enabled causes all of the
>> IOMMU's to be disabled (except the Xen-SWIOTLB). It is in
>> essence a copy of what swiotlb variable does. However the swiotlb variable
>> cannot be used because it would turn on the non-Xen SWIOTLB.
>> ---
>>  arch/x86/include/asm/dma-mapping.h |    1 +
>>  arch/x86/include/asm/xen/swiotlb.h |    4 +++-
>>  arch/x86/kernel/amd_iommu_init.c   |    2 +-
>>  arch/x86/kernel/aperture_64.c      |    2 +-
>>  arch/x86/kernel/pci-calgary_64.c   |    2 +-
>>  arch/x86/kernel/pci-dma.c          |    4 ++--
>>  arch/x86/kernel/pci-gart_64.c      |    2 +-
>>  arch/x86/kernel/pci-swiotlb.c      |    4 ++--
>>  arch/x86/xen/pci-swiotlb.c         |    3 +++
>>  9 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/dma-mapping.h 
>> b/arch/x86/include/asm/dma-mapping.h
>> index 1c3f943..01ef814 100644
>> --- a/arch/x86/include/asm/dma-mapping.h
>> +++ b/arch/x86/include/asm/dma-mapping.h
>> @@ -12,6 +12,7 @@
>>  #include <linux/dma-attrs.h>
>>  #include <asm/io.h>
>>  #include <asm/swiotlb.h>
>> +#include <asm/xen/swiotlb.h>
>>  #include <asm-generic/dma-coherent.h>
>>  
>>  extern dma_addr_t bad_dma_address;
>> diff --git a/arch/x86/include/asm/xen/swiotlb.h 
>> b/arch/x86/include/asm/xen/swiotlb.h
>> index d094f89..fd7e48a 100644
>> --- a/arch/x86/include/asm/xen/swiotlb.h
>> +++ b/arch/x86/include/asm/xen/swiotlb.h
>> @@ -2,9 +2,11 @@
>>  #define _ASM_X86_XEN_SWIOTLB_H
>>  
>>  #ifdef CONFIG_PCI_XEN
>> +extern int xen_swiotlb;
>>  extern void xen_swiotlb_init(void);
>>  #else
>> -static void xen_swiotlb_init(void) { }
>> +#define xen_swiotlb 0
>> +static inline void xen_swiotlb_init(void) { }
>>  #endif
>>  
>>  #endif
>> diff --git a/arch/x86/kernel/amd_iommu_init.c 
>> b/arch/x86/kernel/amd_iommu_init.c
>> index c1b17e9..78ec74b 100644
>> --- a/arch/x86/kernel/amd_iommu_init.c
>> +++ b/arch/x86/kernel/amd_iommu_init.c
>> @@ -1304,7 +1304,7 @@ static int __init early_amd_iommu_detect(struct 
>> acpi_table_header *table)
>>  
>>  void __init amd_iommu_detect(void)
>>  {
>> -    if (swiotlb || no_iommu || (iommu_detected && !gart_iommu_aperture))
>> +    if (swiotlb || xen_swiotlb || no_iommu || (iommu_detected && 
>> !gart_iommu_aperture))
>>              return;
>>  
>>      if (acpi_table_parse("IVRS", early_amd_iommu_detect) == 0) {
>> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
>> index 676debf..6a50006 100644
>> --- a/arch/x86/kernel/aperture_64.c
>> +++ b/arch/x86/kernel/aperture_64.c
>> @@ -369,7 +369,7 @@ void __init gart_iommu_hole_init(void)
>>      int fix, slot, valid_agp = 0;
>>      int i, node;
>>  
>> -    if (gart_iommu_aperture_disabled || !fix_aperture ||
>> +    if (gart_iommu_aperture_disabled || !fix_aperture || xen_swiotlb ||
>>          !early_pci_allowed())
>>              return;
>>  
>> diff --git a/arch/x86/kernel/pci-calgary_64.c 
>> b/arch/x86/kernel/pci-calgary_64.c
>> index 971a3be..f7b8e1c 100644
>> --- a/arch/x86/kernel/pci-calgary_64.c
>> +++ b/arch/x86/kernel/pci-calgary_64.c
>> @@ -1357,7 +1357,7 @@ void __init detect_calgary(void)
>>       * if the user specified iommu=off or iommu=soft or we found
>>       * another HW IOMMU already, bail out.
>>       */
>> -    if (swiotlb || no_iommu || iommu_detected)
>> +    if (swiotlb || xen_swiotlb || no_iommu || iommu_detected)
>>              return;
>>  
>>      if (!use_calgary)
>> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
>> index 6b76948..1101a9f 100644
>> --- a/arch/x86/kernel/pci-dma.c
>> +++ b/arch/x86/kernel/pci-dma.c
>> @@ -122,6 +122,8 @@ void __init pci_iommu_alloc(void)
>>       * The order of these functions is important for
>>       * fall-back/fail-over reasons
>>       */
>> +    xen_swiotlb_init();
>> +
>>      gart_iommu_hole_init();
>>  
>>      detect_calgary();
>> @@ -130,8 +132,6 @@ void __init pci_iommu_alloc(void)
>>  
>>      amd_iommu_detect();
>>  
>> -    xen_swiotlb_init();
>> -
>>      pci_swiotlb_init();
>>  }
>>  
>> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
>> index d2e56b8..f2c9f19 100644
>> --- a/arch/x86/kernel/pci-gart_64.c
>> +++ b/arch/x86/kernel/pci-gart_64.c
>> @@ -730,7 +730,7 @@ void __init gart_iommu_init(void)
>>              (agp_copy_info(agp_bridge, &info) < 0);
>>  #endif
>>  
>> -    if (swiotlb)
>> +    if (swiotlb || xen_swiotlb)
>>              return;
>>  
>>      /* Did we detect a different HW IOMMU? */
>> diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
>> index e8a3501..54a0fa9 100644
>> --- a/arch/x86/kernel/pci-swiotlb.c
>> +++ b/arch/x86/kernel/pci-swiotlb.c
>> @@ -47,10 +47,10 @@ void __init pci_swiotlb_init(void)
>>      /* don't initialize swiotlb if iommu=off (no_iommu=1) */
>>  #ifdef CONFIG_X86_64
>>      if ((!iommu_detected && !no_iommu && max_pfn > MAX_DMA32_PFN) ||
>> -            iommu_pass_through)
>> +            iommu_pass_through || !xen_swiotlb)
>>   
>>     
> This doesn't apply to the xen/dom0/swiotlb-new branch.
>   

OK, its against xen/master.

>>             swiotlb = 1;
>>  #endif
>> -    if (swiotlb_force)
>> +    if (swiotlb_force || !xen_swiotlb)
>>   
>>     
> Are you sure this is right?  This will always enable swiotlb if
> !xen_swiotlb.
>   

I went with this instead:

diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 9640e17..e2d739e 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -45,6 +45,9 @@ static struct dma_map_ops swiotlb_dma_ops = {
 void __init pci_swiotlb_init(void)
 {
        /* don't initialize swiotlb if iommu=off (no_iommu=1) */
+       if (xen_swiotlb)
+               return;
+
 #ifdef CONFIG_X86_64
        if (!iommu_detected && !no_iommu && max_pfn > MAX_DMA32_PFN)
               swiotlb = 1;

Does that work?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.