[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86/i8259: do not assume interrupts always target CPU0
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 24 Oct 2023 15:11:57 +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=saZVC/6Vw8v4dE76WXhpe7fw/ov4sSCfoCLR6/1spmM=; b=WzCF/p0QZl4yUFg4oGQigCJ5zs71/mvnh5SafLIRdel6wIm14tWX6K7pCf1Z/dezyMJmZvIYOBpTC6gyUlexCRmNvBv5htI0zu9e/pmd8wGtJRk5ppPuSGDo6Tp6hD/1P4mm1BySwMLdpiMGcYM/sDpc+Lwom8xVg0oIxWSujtk6P4SOvLnaLwg93IH+r0oGaZdBNrdBVWpXlqi36GC82QJ/pu2GO+mXFjISoNcOGED1ynNPP07jYukUX/FsBb12hvqyFTsRjCaEODqPwbVXrvR6Bn4rXP45amkRAo/hXpWDqMifCW8tyRzJL7NBLIqn6mZEm5R4W729Xb1yB3/7xQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VjXXslDTGGofjR3mzdoclNkeyi5ADWV9AfzYPOmxp0o98metT2M0f81Fvxq+KqH2w/Olpg1K9bAXlbBpq8Lxi1sKq03VEVffw1LGZ8s7PNYJMYjt+lCPdANIr+OJ0jZLgVK4BfGBpogU7P1o6fJgFvcxnImxsThTz4pLIk2+QHmxNoFp151OOxal9NL5OauUznWyvPLDVB8ABNu5mQFwKrSQluERst6BE1oaasZq2Y/BGngtQuZqebxpvqabMu7ZeacPacK+ilV2RYb8aCLdVmUnBlP5Cu3u4D1zE3tNsgW/2C7X9SP6nVfJyduTLenzg+CsR/1QGz7bVjBAMUs/QA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 24 Oct 2023 13:12:25 +0000
- Ironport-data: A9a23:mzxwV6u4JJsJcGd0VxCSeiGPCufnVHBfMUV32f8akzHdYApBsoF/q tZmKWqDM/feYDHxc9x3Odu/ox5UvZCEmt5mS1Bpryg9FyIb+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVaicfHg3HFc4IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4rKq41v0gnRkPaoQ5QeEyyFMZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwAhc1cxKFjcKP6YmxV9VOwcV+MJH7I9ZK0p1g5Wmx4fcOZ7nmGvyPyfoGmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osj/60bou9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAtNISuPkracCbFu7zEBNCT0me1+Aj9a6u0GjRuADK RAVw397xUQ13AnxJjXnZDW6qnOZuh8XW/JLDvY3rgqKz8L8/AKxFmUCCDlbZ7QOpMIwADAny FKNt9foHiB09q2YT2qH8bWZpi/0PjIaRVLufgcBRAoBptXm/oc6i0uWSs45SfDkyNroBTv33 jaG6jAkgKkehtIK0KP9+k3bhzWrpd7CSQtdChjrY19JJzhRPOaND7FEI3CChRqcBO51lmW8g UU=
- Ironport-hdrordr: A9a23:LpBY7aA7FSHq4enlHela55DYdb4zR+YMi2TDt3oddfWaSKylfq GV7ZImPHrP4gr5N0tOpTntAse9qDbnhPxICOoqTNCftWvdyQiVxehZhOOP/9SjIVyaygc078 xdmsNFebnN5DZB7PoT4GODYqkdKNvsytHXuQ8JpU0dPD2DaMtbnndE4h7wKDwOeOHfb6BJaa Z14KB81kKdUEVSVOuXLF8fUdPOotXa/aiWHSLvV3YcmXKzZSrD0s+BLySl
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Oct 24, 2023 at 02:08:42PM +0200, Jan Beulich wrote:
> On 24.10.2023 14:06, Jan Beulich wrote:
> > On 24.10.2023 13:36, Roger Pau Monné wrote:
> >> What is your reasoning for wanting the smp_processor_id() check in
> >> the caller rather than bogus_8259A_irq()? It does seem fine to me to
> >> do such check in bogus_8259A_irq(), as whether the IRQ is bogus also
> >> depends on whether it fired on the BSP or any of the APs.
> >
> > bogus_8259A_irq() shouldn't be concerned about the CPU it runs on; it
> > should solely deal with 8259A aspects.
>
> Or to put it differently: The function is supposed to tell whether an
> IRQ is bogus from the pov of the PIC. The caller decides under what
> conditions to actually invoke this checking.
I understand that the PIC itself is agnostic as to which the CPU the
irq (vector) has been injected, but the added CPU vendor checks are
there to deal with possibly a bogus PIC implementation, and hence
doesn't feel that off place IMO.
Anyway, will adjust as requested, albeit I think it hampers
readability and that's more valuable than whether the check is
contextually better fit in do_IRQ() or bogus_8259A_irq().
Thanks, Roger.
|
