Hi Thomas Gleixner,
Thank you for review, and you are right, it seems more like a XEN internal issue. We are discussing it and maybe will fix it in Xen code next version.
On 2023/12/4 16:13, Thomas Gleixner wrote:
> On Fri, Nov 24 2023 at 18:31, Jiqian Chen wrote:
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
>> index 5a96b6c66c07..b83d02bcc76c 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -357,6 +357,7 @@ static int pcistub_match(struct pci_dev *dev)
>> static int pcistub_init_device(struct pci_dev *dev)
>> {
>> struct xen_pcibk_dev_data *dev_data;
>> + struct irq_desc *desc = NULL;
>> int err = 0;
>>
>> dev_dbg(&dev->dev, "initializing...\n");
>> @@ -399,6 +400,12 @@ static int pcistub_init_device(struct pci_dev *dev)
>> if (err)
>> goto config_release;
>>
>> + if (xen_initial_domain() && xen_pvh_domain()) {
>> + if (dev->irq <= 0 || !(desc = irq_to_desc(dev->irq)))
>
> Driver code has absolutely no business to access irq_desc.
>
>> + goto config_release;
>> + unmask_irq(desc);
>
> Or to invoke any internal function.
>
>> --- a/kernel/irq/chip.c
>> +++ b/kernel/irq/chip.c
>> @@ -439,6 +439,7 @@ void unmask_irq(struct irq_desc *desc)
>> irq_state_clr_masked(desc);
>> }
>> }
>> +EXPORT_SYMBOL_GPL(unmask_irq);
>
> Not going to happen.
>
>> --- a/kernel/irq/irqdesc.c
>> +++ b/kernel/irq/irqdesc.c
>> @@ -380,7 +380,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
>> {
>> return mtree_load(&sparse_irqs, irq);
>> }
>> -#ifdef CONFIG_KVM_BOOK3S_64_HV_MODULE
>> +#if defined CONFIG_KVM_BOOK3S_64_HV_MODULE || defined CONFIG_XEN_PVH
>
> Neither that.
>
> This all smells badly like a XEN internal issue and we are not going to
> hack around it by exposing interrupt internals.
>
> Thanks,
>
> tglx
--
Best regards,
Jiqian Chen.
