[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 1/6] x86/ioapic: set disable hook for masking edge interrupts
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Fri, 3 Jun 2022 16:53:08 +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=eEO5KEH84xBGRvwftGa85g4axL+WqYFNwUoCvf48EYk=; b=apmP4dKebxJllrqkAD076+G9NVJIngM8Jg1bqJLDx72ZIcqNsI+/jnkeczcmoiLl4KXs4gsDUGg8Li1pGi5D9jNmmedeRwXbFCbx5NpArRg3OLnYTWwOMnftBx9w6q4ognqgbG6CRLiZyPBXqdE67nJ+I4iWV3i6iOo9TwHDcNHN3LkjvjehNdYtMj+LKSAeqgbnTQj425bJP2hT1fFl0UAU2BogFdOGhqvSyLC14ZSmkldHqhVxqYoeUq6P3IrHAFYDlSPLi5mexueOmwKUwXnUgJCsovaRAWcBPQanVoDbdCLwJLXv9Vl6v99vXl9UBnBo6ZVVaWL6Ce/ZzgaBDg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BZ/6qmbTf4Jsx6RBMcJxSsatizHoGq7cBjbX8LDbe+AF24Z2EC5QvGea/DKuhVEg5+0T/+yHDWEFhOZEgLdcxq4hfZJhkIFWRQ2fXcngrFigSmZAbiqkDgS0YSa5N/SNFaMefegE2E6OLfNEHBM24e17eEVEybi8Ki24b3jIzi7xc/n+2SjLE6haZuvlkcy85muN9mALdiPYqhKmy3vgJF54aclKYfhi7Ry8WrqDIPQvBicIFMwMpWeed2o7by6KXxPknrCis12Qs6rA8yhwZuQzseMy70uVOaT8LhhOUvm8puuIDsj1zttNisZ/B1deMg0DNrpf3eQDUeYRgvEZgg==
- 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: Fri, 03 Jun 2022 14:53:31 +0000
- Ironport-data: A9a23:ASaJ7aka32R7ggLnL7i7Cwvo5gz1J0RdPkR7XQ2eYbSJt1+Wr1Gzt xJKXmmDaK3YYmDzLd52bdux8koG7JKEyYdrSQpprCkxQiMWpZLJC+rCIxarNUt+DCFioGGLT Sk6QoOdRCzhZiaE/n9BCpC48T8kk/vgqoPUUIYoAAgoLeNfYHpn2EsLd9IR2NYy24DnW1jV4 7senuWEULOb828sWo4rw/rrRCNH5JwebxtB4zTSzdgS1LPvvyF94KA3fMldHFOhKmVgJcaoR v6r8V2M1jixEyHBqD+Suu2TnkUiGtY+NOUV45Zcc/DKbhNq/kTe3kunXRa1hIg+ZzihxrhMJ NtxWZOYZT0NNKzBwtohFDJZSxwmFvx2yKfLPi3q2SCT5xWun3rE5dxLVRhzF6tIv+F9DCdJ6 OASLy0LYlabneWqzbmnS+5qwMM+MM3sO4BZsXZlpd3bJa9+HdafHOOXtZkBg2pYasNmRJ4yY +IDbjVidlLYagBnMVYLEpMu2uyvgxETdhUH9QnI//FmuwA/yiQt1+DVYMXpReCVRP5FkEGz/ 0DvrjzQV0Ry2Nu3jGDtHmiXru3FkD7/WYkSPKal7fMsi1qWrkQMDDUGWF39puO24mauVtQaJ 0EK9y4Gqakp6FftXtT7Rwe/onOPolgbQdU4LgEhwASEy66R6QDJAGEBF2dFcIZ/65JwQiE23 FiUmd+vHSZorLCeVXOa8PGTsC+2Pi8Wa2QFYEfoUDc43jUqm6lr5jqnczqpOPTdYgHdcd0o/ w23kQ==
- Ironport-hdrordr: A9a23:nW9dn6gj59+8FBmNyp7jow0qkHBQX0Z13DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03I+eruBEBPewK4yXdQ2/hoAV7CZniehILMFu1fBOTZowEIdxeOldK1kJ 0QCJSWa+eAcWSS7/yKhzVQeuxIqLfnzEnrv5a5854Ed3AWV0gK1XYcNu/0KDwVeOEQbqBJbq Z0q/A30QaISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oC5BOVhT2lxbbmG1zAty1uGw9n8PMHyy zoggb57qKsv7WSzQLd7Xba69BzlMH6wtVOKcSQgow+KynqiCyveIN9Mofy9QwdkaWK0hIHgd PMqxAvM4Ba7G7QRHi8pV/X1wzpwF8Vmgrf4G7dpUGmjd3yRTo8BcYEr5leaAHl500pu8w5+L 5X3kqC3qAnQS/orWDY3ZzlRhtqnk27rT4JiugIlUFSVoMYdft4sZEfxkVIC50NdRiKpbzPKN MeQv002cwmMG9zNxvizylSKZ2XLz4O9y69Mwc/Upf/6UkUoJh7p3FotvD30E1wtq7VcKM0md gsAp4Y642mcfVmHJ6VJN1xNfdfWVa9Ni4lDgqpUCTaPZBCHU7xgLjKx5hwzN2WWfUzvegPcd L6IRhliVI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Jun 03, 2022 at 03:19:34PM +0200, Jan Beulich wrote:
> On 21.04.2022 15:21, Roger Pau Monne wrote:
> > Allow disabling (masking) IO-APIC pins set to edge trigger mode. This
> > is required in order to safely migrate such interrupts between CPUs,
> > as the write to update the IO-APIC RTE (or the IRTE) is not done
> > atomically,
>
> For IRTE on VT-d we use cmpxchg16b if available (i.e. virtually always).
>
> > so there's a window where there's a mismatch between the
> > destination CPU and the vector:
> >
> > (XEN) CPU1: No irq handler for vector b5 (IRQ -11, LAPIC)
> > (XEN) IRQ10 a=0002[0002,0008] v=bd[b5] t=IO-APIC-edge s=00000030
>
> I think this needs some further explanation, as we generally move
> edge IRQs only when an un-acked interrupt is in flight (and hence
> no further one can arrive).
A further one can arrive as soon as you modify either the vector or
the destination fields of the IO-APIC RTE, as then the non-EOI'ed
lapic vector is no longer there (because you have moved to a different
destination or vector).
This is the issue with updating the IO-APIC RTE using two separate
writes: even when using interrupt remapping the IRTE cannot be
atomically updated and there's a window where the interrupt is not
masked, but the destination and vector fields are not in sync, because
they reside in different parts of the RTE (destination is in the high
32bits, vector in the low 32bits part of the RTE).
Thanks, Roger.
|
