Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1cbe7daa-8003-562b-06fa-5a50f7ee6ed2@huawei.com>
Date:   Fri, 4 Mar 2022 12:53:31 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: PCI MSI issue for maxcpus=1
From:   John Garry <john.garry@huawei.com>
To:     Marc Zyngier <maz@kernel.org>
CC:     Thomas Gleixner <tglx@linutronix.de>,
        chenxiang <chenxiang66@hisilicon.com>,
        Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "liuqi (BA)" <liuqi115@huawei.com>, <wangxiongfeng2@huawei.com>
References: <78615d08-1764-c895-f3b7-bfddfbcbdfb9@huawei.com>
 <87a6g8vp8k.wl-maz@kernel.org>
 <19d55cdf-9ef7-e4a3-5ae5-0970f0d7751b@huawei.com>
 <87v8yjyjc0.wl-maz@kernel.org> <87k0ey9122.wl-maz@kernel.org>
 <5f529b4e-1f6c-5a7d-236c-09ebe3a7db29@huawei.com>
In-Reply-To: <5f529b4e-1f6c-5a7d-236c-09ebe3a7db29@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

> ...

> 
> [ 7.961007]  valid_col+0x14/0x24
> [ 7.964223]  its_send_single_command+0x4c/0x150
> [ 7.968741]  its_irq_domain_activate+0xc8/0x104
> [ 7.973259]  __irq_domain_activate_irq+0x5c/0xac
> [ 7.977865]  __irq_domain_activate_irq+0x38/0xac
> [ 7.982471]  irq_domain_activate_irq+0x3c/0x64
> [ 7.986902]  __msi_domain_alloc_irqs+0x1a8/0x2f4
> [ 7.991507]  msi_domain_alloc_irqs+0x20/0x2c
> [ 7.995764]  __pci_enable_msi_range+0x2ec/0x590
> [ 8.000284]  pci_alloc_irq_vectors_affinity+0xe0/0x140
> [ 8.005410]  hisi_sas_v3_probe+0x300/0xbe0
> [ 8.009494]  local_pci_probe+0x44/0xb0
> [ 8.013232]  work_for_cpu_fn+0x20/0x34
> [ 8.016969]  process_one_work+0x1d0/0x354
> [ 8.020966]  worker_thread+0x2c0/0x470
> [ 8.024703]  kthread+0x17c/0x190
> [ 8.027920]  ret_from_fork+0x10/0x20
> [ 8.031485] ---[ end trace bb67cfc7eded7361 ]---
> 

...

> Ah, of course. the CPU hasn't booted yet, so its collection isn't
> mapped. I was hoping that the core code would keep the interrupt in
> shutdown state, but it doesn't seem to be the case...
> 
>  > Apart from this, I assume that if another cpu comes online later in
>  > the affinity mask I would figure that we want to target the irq to
>  > that cpu (which I think we would not do here).
> 
> That's probably also something that should come from core code, as
> we're not really in a position to decide this in the ITS driver.
> .


Hi Marc,

Have you had a chance to consider this issue further?

So I think that x86 avoids this issue as it uses matrix.c, which handles 
CPUs being offline when selecting target CPUs for managed interrupts.

So is your idea still that core code should keep the interrupt in 
shutdown state (for no CPUs online in affinity mask)?

Thanks,
John