[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/2] ns16550: reject IRQ above nr_irqs_gsi
- To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Tue, 10 May 2022 14:30:41 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xd+pqv0zgKIEDhjCh+UnuP1k0P82s3oSW9CqZZhRKRg=; b=Ukc8kCFfogoFzNAZ+oeesIeHosyTjYyG+a4x9YRKKsKUitJ/wQCGxeatudaZf22J5YcTW+8SXlEnjvwHF3JKXx/c1L3V2SEUJNh0R5bnGqizIrU1avQA0q3i6qMH+KPvaYIz6DR/13Jk3171k1mlsRKxgAD/KC5rozlFlM3xjZRr8KAWI70R5pwPRX5SaRqudYlB8yCVsFfQsjzivrY5kY2LZ+DPpt85IUv2hjifLYY7VbTkjQ/ri77kSfAwJcIZKoPl2T3DOuDocyWLLPDOWC7lEU1/NDkz1Ff3HKdpPJWshVyxdTC3VZ3Ceuuu+8n0D19fzx6ZoAj9VbyiFQ6p6Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZph9p7M4SFpMpZvuBoaKjIv9ormIkhki4/85M5WiyPgCuNBhM/27EoJRKhUbnU249b3ViGxZJ+X1b+UoNBAGUrbUCBMVUMgH1i4Y4pNw7GCkgqutDjRQzelhvbv3/65ETj1O1Hh49BmwJxH927GEXlWuRIndpDnmGfOsiyz3iKCsGkXn6crJnANnYA3k8GQ1ufEaoqzfMth0OPpJoQkE1hMbGr+jWorRDit8IT/AQbKCiAH+mxZ1W4DtxXzYg/fwS5znVJWphHgd8x3NEXGrbq++GXjwnXqgUUn9pHFq2qRMh24NBuBrbzZ4oCpxGTCbTrXY4/LJeiEEztEAYcqxw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Tue, 10 May 2022 14:30:48 +0000
- Ironport-data: A9a23:xsEMEKBifatBNxVW/xPiw5YqxClBgxIJ4kV8jS/XYbTApDIg3zMGx mZKWz2CM/iJZTejKdsnOtjk8R8B7MOBnYdkQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuOU5NXsZ2YgHGeIdA970Ug5w7Ng2tYy6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPh96 P5KkaSZCj4yI6LcktY/fyJ5NSRxaPguFL/veRBTsOS15mifKz7A5qsrC0s7e4oF5uxwHGdCs +QCLywAZQyCgOTwx6+nTu5rhYIoK8yD0IE34yk8i22GS6t2B8mbG80m5vcBtNs0rulIEezTe Iwybj13YQ6bSxZOJk0WGNQ1m+LAanzXLGYE9wnF9fNfD277xQwqk6fJa/7pId2wZphNuHq4r 2PM8DGsav0dHJnFodafyVqpj/XKlDn2W6oTEqO57f9ghFCPxm0VBwYSXFH9qv684mauVtQaJ 0EK9y4Gqakp6FftXtT7Rwe/onOPolgbQdU4O+8w5RyJy6HUyx2EHWVCRTlEAPQkqcs3SDoCx lKP2dTzClRHq6aJQHiQ8rOVqzKaOiUPK2IGIygeQmMt/N3LsIw1yBXVQb5e/LWdi9T0HXT8x m6MpS1n37EL15dTj+O84EzNhC+qqt7RVAkp6w7LX2WjqARkeIqiYI/u4l/ehRpdELukopC6l CBss6CjAComVPlhSATlrD0xIYyU
- Ironport-hdrordr: A9a23:SIToBqizlF62dn+UrqyfyJ3Qt3BQX4N23DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03IwerwQ5VpQRvnhP1ICRF4B8bvYOCUghrTEGgE1/qs/9SAIVyyygc578 tdmsdFebrN5DRB7PoSpTPIa+rIo+P3vpxA592uqUuFJDsCA84P0+46MHfjLqQcfnglOXNNLu v52iMxnUvERZ14VKSGL0hAe9KGi8zAlZrgbxJDLQUg8hOygTSh76O/OwSE3z8FOgk/gYsKwC zgqUjU96+ju/a0xlv3zGnI9albn9Pn159qGNGMsM4IMT/h4zzYJ7iJGofy/gzdktvfrGrCo+ O85CvI+P4DrU85S1vF5CcFHTOQiQrGpUWSkWNwykGT3PARDAhKd/apw7gpMycxonBQwu2Vms hwrh2knosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfdsRKEkjTVo+a07bWvHAUEcYZ tTJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYYit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tXKyaRw4PvvdI0DzZM0lp iEWFREtXQqc0arEsGK1I0jyGG7fIx8Z0WY9ihz3ekIhlSnfsubDcSqciFcr+Kw5/MCH8bcR/ G/fJpLHv6LFxqaJbp0
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYZGTv0L0FedIJ8kmYH2hX6mR3t60YLEEA
- Thread-topic: [PATCH v2 1/2] ns16550: reject IRQ above nr_irqs_gsi
On 10/05/2022 12:55, Marek Marczykowski-Górecki wrote:
> Intel LPSS has INTERRUPT_LINE set to 0xff by default, that can't
> possibly work. While a proper IRQ configuration may be useful,
> validating value retrieved from the hardware is still necessary. If it
> fails, use the device in poll mode, instead of crashing down the line
> (at smp_initr_init()). Currently it's
> x86-specific, as the surrounding code is guarded with CONFIG_X86 anyway.
>
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
This isn't invalid per say. It explicitly means unknown/no connection
and is used in practice to mean "never generate line interrupts, even
when MSI is disabled". It's part of PCI 3.0 if the internet is to be
believed, but ISTR is mandatory for SRIOV devices where the use of line
interrupts is prohibited by the spec.
Also, there are systems where nr_irq_gsi is greater than 0xff.
I'd recommend handling 0xff specially as "no legacy irq", and not
involving nr_irq_gsi at all.
~Andrew
|
