public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -tip] x86: fix iommu=soft boot option
Date: Tue, 01 Dec 2009 23:55:28 -0800	[thread overview]
Message-ID: <4B161D70.3030301@kernel.org> (raw)
In-Reply-To: <20091202162510Q.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Tue, 01 Dec 2009 22:57:37 -0800
> Yinghai Lu <yinghai@kernel.org> wrote:
> 
>> FUJITA Tomonori wrote:
>>> On Mon, 30 Nov 2009 23:42:00 -0800
>>> Yinghai Lu <yinghai@kernel.org> wrote:
>>>
>>>> FUJITA Tomonori wrote:
>>>>> On Thu, 26 Nov 2009 23:45:33 -0800
>>>>> Yinghai Lu <yinghai@kernel.org> wrote:
>>>>>
>>>>>>>> when AMD64 mem > 4g, no AGP, BIOS set all gart iommu on all nodes size to 32M, and enable bit are set.
>>>>>>> I have such machine (with sane BIOS).
>>>>>>>
>>>>>>> But if BIOS is broken, early_gart_iommu_check() disables GART_EN bit
>>>>>>> (bits 0)?
>>>>>> not for 32M small size.
>>>>>>
>>>>>> that function only clear that bit when different nodes have different setting.
>>>>>>
>>>>>>>> 1. iommu=soft, will go through POINT A and POINT B
>>>>>>> Not always. if aperture_valid() is true, it doesn't go POINT A. My
>>>>>>> GART machine doesn't go.
>>>>>> maybe your bios set GART iommu set to 64M?
>>>>> Yeah, my machine has sane BIOS.
>>>>>
>>>>>
>>>>>>>> 2. no "iommu=soft", will go through POINT A and POINT C
>>>>>>> As I said, it's not true about POINT A.
>>>>>> maybe your bios set GART iommu set to 64M?
>>>>>>
>>>>>>>> and all will reach POINT X to make sure ENABLE bit is not set.
>>>>>>> POINT X doesn't look make sure ENABLE bit is not set. It just fixes up
>>>>>>> (sets) the address and its size.
>>>>>>                         write_pci_config(bus, slot, 3, AMD64_GARTAPERTURECTL, aper_order << 1);
>>>>>>
>>>>>> that bit is that bit 0 of AMD64_GARTAPERTURECTL reg.
>>>>> Oops, thanks.
>>>>>
>>>>> But as I wrote in the previous mail, can you tell me why we need this?
>>>>> With 2.6.31 my machine uses swiotlb with GART_EN bit enabled.
>>>>>
>>>>> My another question is that why can't early_gart_iommu_check()
>>>>> _always_ disable GART_EN bit?
>>>> please check
>>> Thanks.
>>>
>>> As I said, it looks cleaner if early_gart_iommu_check() disables
>>> GART_EN bit. So this patch looks better but I still have some
>>> questions.
>>>
>>>
>>>> [PATCH] x86: fix gart iommu using for amd 64 bit system -v4
>>>>
>>>> after
>>>> |commit 75f1cdf1dda92cae037ec848ae63690d91913eac
>>>> |Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>>>> |Date:   Tue Nov 10 19:46:20 2009 +0900
>>>> |
>>>> |    x86: Handle HW IOMMU initialization failure gracefully
>>>> |    
>>>> |    If HW IOMMU initialization fails (Intel VT-d often does this,
>>>> |    typically due to BIOS bugs), we fall back to nommu. It doesn't
>>>> |    work for the majority since nowadays we have more than 4GB
>>>> |    memory so we must use swiotlb instead of nommu.
>>>> ...
>>>>
>>>> amd 64 systems that
>>>> 1. do not have  AGP
>>>> 2. do not have IOMMU
>>>> 3. mem > 4g
>>>> 4. BIOS do not allocate  correct gart in NB.
>>>> will leave them to use SWIOTLB forcely.
>>> As I asked earlier, can you tell me what dma ops such system is
>>> supposed to use?
>> gart_dma_ops
> 
> How does gart_dma_ops work on systems without IOMMU?

?

> 
> 
>>>> -v2: call shutdown when no agp is there
>>> Is this change related with my above patchset?
>> looks like one bug that is exposed by
>> commit 338bac527ed0e35b4cb50390972f15d3cbce92ca
>> Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>> Date:   Tue Oct 27 16:34:44 2009 +0900
>>
>>     x86: Use x86_platform for iommu_shutdown
>>     
>>     This patch cleans up pci_iommu_shutdown() a bit to use
>>     x86_platform (similar to how IA64 initializes an IOMMU driver).
>>     
>>     This adds iommu_shutdown() to x86_platform to avoid calling
>>     every IOMMUs' shutdown functions in pci_iommu_shutdown() in
>>     order. The IOMMU shutdown functions are platform specific (we
>>     don't have multiple different IOMMU hardware) so the current way
>>     is pointless.
>>     
>>     An IOMMU driver sets x86_platform.iommu_shutdown to the shutdown
>>     function if necessary.
>>     
>>     Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>>     Cc: joerg.roedel@amd.com
>>     LKML-Reference: <20091027163358F.fujita.tomonori@lab.ntt.co.jp>
>>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>
>> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
>> index a7f1b64..a9bcdf7 100644
>> --- a/arch/x86/kernel/pci-gart_64.c
>> +++ b/arch/x86/kernel/pci-gart_64.c
>> @@ -39,6 +39,7 @@
>>  #include <asm/swiotlb.h>
>>  #include <asm/dma.h>
>>  #include <asm/k8.h>
>> +#include <asm/x86_init.h>
>>  
>>  static unsigned long iommu_bus_base;   /* GART remapping area (physical) */
>>  static unsigned long iommu_size;       /* size of remapping area bytes */
>> @@ -688,12 +689,12 @@ static struct dma_map_ops gart_dma_ops = {
>>         .free_coherent                  = gart_free_coherent,
>>  };
>>  
>> -void gart_iommu_shutdown(void)
>> +static void gart_iommu_shutdown(void)
>>  {
>>         struct pci_dev *dev;
>>         int i;
>>  
>> -       if (no_agp && (dma_ops != &gart_dma_ops))
>> +       if (no_agp)
>>                 return;
>>  
>>         for (i = 0; i < num_k8_northbridges; i++) {
>> @@ -838,6 +839,7 @@ void __init gart_iommu_init(void)
>>  
>>         flush_gart();
>>         dma_ops = &gart_dma_ops;
>> +       x86_platform.iommu_shutdown = gart_iommu_shutdown;
>>  }
>>  
>>  void __init gart_parse_options(char *p)
>>
>> on system without agp, the gart should be shutdown during system shutdown. so make next kexeced kernel happy.
> 
> Ah, I see. Sorry about this mess-up.
> 
> 
>>>> -v3: add check_store to restore state for swiotlb
>>>>      separate pci_swiotlb_detect and pci_swiotlb_init from FUJITA
>>>> -v4: disable translating in early_gart_iommu_check according to FUJITA
>>> Why can't we always disable translation in early_gart_iommu_check? We
>>> really need search_agp_bridge() in early_gart_iommu_check()?
>> just don't want to messed them up.
> 
> Sorry, I can't follow you. What does 'always disabling' mess up?

the AMD K8 system with AGP etc...those systems are some kind of 5 years old.

and don't have those kind of system to verify...

YH

  reply	other threads:[~2009-12-02  7:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 23:46 [PATCH -tip] x86: fix iommu=soft boot option FUJITA Tomonori
2009-11-24 23:55 ` Yinghai Lu
2009-11-25  0:05   ` FUJITA Tomonori
2009-11-25  8:18   ` Ingo Molnar
2009-11-25  8:54     ` Yinghai Lu
2009-11-25  9:05       ` FUJITA Tomonori
2009-11-25  9:10         ` Ingo Molnar
2009-11-25  9:45           ` Yinghai Lu
2009-11-25 11:03             ` FUJITA Tomonori
2009-11-25 22:33               ` Yinghai Lu
2009-11-27  7:29                 ` FUJITA Tomonori
2009-11-27  7:45                   ` Yinghai Lu
2009-11-27  8:06                     ` FUJITA Tomonori
2009-12-01  7:42                       ` Yinghai Lu
2009-12-02  5:44                         ` FUJITA Tomonori
2009-12-02  6:57                           ` Yinghai Lu
2009-12-02  7:25                             ` FUJITA Tomonori
2009-12-02  7:55                               ` Yinghai Lu [this message]
2009-12-02  8:07                                 ` FUJITA Tomonori
2009-12-08  0:24                                   ` FUJITA Tomonori
2009-12-08  0:51                                     ` Yinghai Lu
2009-11-25 10:17   ` Joerg Roedel
2009-11-25 13:30 ` [tip:core/iommu] x86: Fix " tip-bot for FUJITA Tomonori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B161D70.3030301@kernel.org \
    --to=yinghai@kernel.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox