[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: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 10 May 2022 17:46:12 +0200
- 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=yqdWI16gotw1b+24r2GL66eTxF9CTPtNeEtGucldqiY=; b=loSVK6mmm2B8MvF+obc7NGpz5+PTZdQPMByFrLxkKF/rQawDrEsuedYQ36KZfgtjZyqUg7lf37dWEpup65sQtE0yJMecfgYY/C14V3lyh9jhMAwFoJTNy4yvIN5LrByNWYE+wPcQm9xEeq/DkkqIk8VEHlsG/obJ3IRpSP0zwcNYbnCXFyATYWJkiTjtKP2QMdF0RyEgpXG6Ku9OqbIFZifZQ4Ui6bhmE1YtLmYTdXWIRHKBgSPTFcCnV0ajF0iYR6/LAvoLOd61P4By8PavT+QruJIW+n3pCHnCGigFdCvvkKl27lEiCAWpt7ixasBFzO0wNUqkEveesmLPzx5fbA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HhJfiUDyCWNMUQPWMwAkIndLqZT1FJzMYz9+5E9aT2tHQKmWUw9z4UHUY7S3qooCmkqPHNGyZ/jX9OMYFh+nvt0MYmXOZU+nuXPLP1tj5jz//YaCagHSfjmiLy4nIdzjvp0mT5UJR8rsYsR/vIjH31FVOD5b9rCkdZecNokNgRVX3MsM/TIF8kQGAdsPe1rXRNhi8cgKYqbARLadt6h4ED0bdMy+zjpFyX18VIwYB0iVEZKn23yOk0TOhajOmY2GVKsqUCkut5Aws0Fdv1ETWrY9QTG77i+ZmcE8THVYOdAz2NG3Xo4h8k4OS7SfOaQZc0ubg3gi4Yv9MePfTzCyBQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, 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 15:46:30 +0000
- Ironport-data: A9a23:aLM9rK8Xu+oBSKS5RkSkDrUDvH+TJUtcMsCJ2f8bNWPcYEJGY0x3y 2ZJC2qOM/bZZGSmLdskPY6y8h8G7JPUztEyTVBt/iA8E34SpcT7XtnIdU2Y0wF+jyHgoOCLy +1EN7Es+ehtFie0Si+Fa+Sn9T8mvU2xbuKU5NTsY0idfic5DnZ44f5fs7Rh2NQw3IHhW1nlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnZDgbBoRZ5eSo+YEaz5mLC4iYupWo4aSdBBTseTLp6HHW13F5qw0SWQJZ8gf8OsxBnxS/ /sFLjxLdgqEm++93LO8TK9rm9gnK87oeogYvxmMzxmAVapgHc+FHfuMuYIwMDQY36iiGd7EY MUUc3x3ZQnoaBxTIFYHTpk5mY9Eg1GgKmUA9gPL9cLb5UCIwV0y2aX3bubqa+fRY+ResGCa+ 2DZqjGR7hYycYb3JSC+2nelnOrGhy74cIMUCryj9/RujUGTx2ocExkfXx2wpvzRol6zXZdTJ lIZ/gIqrLMu7wq7Q9/lRRq6rXWY+BkGVLJ4Eec39QWMwar8+BuCCy4PSTspQN47sM47QxQ62 1nPmMnmbRR0q6GcQ3+Z8raSrBuxNDITIGtEYjULJSMa5/HzrYd1iQjAJuuPC4awh9zxXDTvm TaDqXFkg61J1ZJWkaKm4VrAnjSg4IDTSRI47RnWWWTj6R5lYImiZMqj7l2zAet8Ebt1h2Kp5 BAs8/VyJshQZX1RvERhmNkwIYw=
- Ironport-hdrordr: A9a23:Ax9eu6MzGWo22cBcT1P155DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jztSWatN/eYgBEpTmlAtj5fZq6z+8P3WBxB8baYOCCggeVxe5ZjbcKrweQeBEWs9Qtr5 uIEJIOd+EYb2IK6voSiTPQe7hA/DDEytHPuQ639QYQcegAUdAF0+4WMHf4LqUgLzM2eKbRWa Dsr/Zvln6FQzA6f867Dn4KU6zqoMDKrovvZVojCwQ84AeDoDu04PqieiLolSs2Yndq+/MP4G LFmwv26uGKtOy68AbV0yv2445NkNXs59NfDIini9QTKB/rlgG0Db4RE4GqjXQQmqWC+VwqmN 7Dr1MJONly0WrYeiWPrR7ky2DboUITwk6n7WXdrWrooMT/Sj5/IdFGn5hlfhzQ7FdllM1g0Y pQtljp+KZ/PFflpmDQ9tLIXxZlmg6funw5i9MeiHRZTM83dKJRl4oC50lYea1wUB4S0LpXUd WGMfuspMq/KTihHjPkVyhUsZGRt00Ib1m7qhNogL3W79BU9EoJunfwivZv20voz6hNOqWs19 60TJiAq4s+PvP+TZgNc9vpEvHHfFAkf3r3QRGvCGWiMp07EFTwjLOyyIkJxYiRCe41Jd0J6d 78bG8=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, May 10, 2022 at 02:30:41PM +0000, Andrew Cooper wrote:
> 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.
I've finally found the reference for it in (one) PCI specification.
It's in the PCI Local Bus Specification Revision 3.0 (from 2004) as a
footnote, so for the reference I'm going to paste it here:
Interrupt Line
The Interrupt Line register is an eight-bit register used to
communicate interrupt line routing information. The register is
read/write and must be implemented by any device (or device function)
that uses an interrupt pin. POST software will write the routing
information into this register as it initializes and configures the
system. The value in this register tells which input of the system
interrupt controller(s) the device's interrupt pin is connected to.
The device itself does not use this value, rather it is used by device
drivers and operating systems. Device drivers and operating systems
can use this information to determine priority and vector information.
Values in this register are system architecture specific. [43]
[...]
[43] For x86 based PCs, the values in this register correspond to IRQ
numbers (0-15) of the standard dual 8259 configuration. The value 255
is defined as meaning "unknown" or "no connection" to the interrupt
controller. Values between 15 and 254 are reserved.
That note however is completely missed on the newer PCI Express
specifications.
Marek, can you please adjust the code as suggested by Andrew and add
the reference to the commit message?
Thanks, Roger.
|