[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/HVM: don't mark evtchn upcall vector as pending when vLAPIC is disabled
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Fri, 18 Nov 2022 13:51:56 +0100
- 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=b8RNHA89uM0j2X61JYjokoiSPQ3LqYMtOeXQ5jYT2Xk=; b=lXMcCAZkp1mf9evurSi+ckfbHZJE5iyK2bFR6eKKkHhz0+dJr3Ne6zN/BiCXyd/9bptdAntShlEekJlT4Xiaoa0CoVYItdzTrLkYUG5AHBKnsyIOckWhswK5bTk+GChuII3Dki2J+Ga53hvJ+82BQI354i33p9TlyR4IPBK4g9b+bSgzNC0MjWCqJDkvsbc3jCEwCmhKf7gq8hsuC6j8bekJXR7/qQ15cy1MWQq2evSHr2u++256RaI69nbh5and3lGK0CaSqYKHXoz3wNZ0XOwzObIkd6LQasx59ZkYRsSgRNskXmswy+XOwC28SyR1c8fmW4SIlHejY2zFJkP7Ow==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ix/BDmO+mWR6tWqBelzifYh1yEB5Npb7j0x1zlM+RH71VJ/Cj8DYD8yg85jnxQmV/Bx8btcyVezPA4bEIOtlaFs3AlExTnafARexBqKx0Ykha2VVbqDXTBdTMi8voFcAYRDWkFexbwhTIIrJp1a6/Z0aF80wulHlQ5a6SHFlTe4sQb+FjqA7HL8SE5WRuPlDblbLZ4hAJuvpTQglYyTv79jCvRF4NZJUKdruEle8hfaPEZhYMDpYBZBpfy/HnJ6DRkKXVnouhQe/cyr8FFWDzHkTtakrQvHpUYIhvL/4xEodpW8fOSAZyU3PgFleRosuIod0hh/TWcVjtS2aHeCd/A==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>
- Delivery-date: Fri, 18 Nov 2022 12:52:24 +0000
- Ironport-data: A9a23:DLyTkaO8AtH/WtXvrR2QlsFynXyQoLVcMsEvi/4bfWQNrUp2gmQPz GEcD2iEbPaPMzTzL992b9m2pkoPsZDVzddlHQto+SlhQUwRpJueD7x1DKtS0wC6dZSfER09v 63yTvGacajYm1eF/k/F3oDJ9CU6jufQA+KmU4YoAwgpLSd8UiAtlBl/rOAwh49skLCRDhiE/ Nj/uKUzAnf8s9JPGj9SuvzrRC9H5qyo4mpB5wxmP5ingXeF/5UrJMNHTU2OByOQrrl8RoaSW +vFxbelyWLVlz9F5gSNy+uTnuUiG9Y+DCDW4pZkc/HKbitq/0Te5p0TJvsEAXq7vh3S9zxHJ HehgrTrIeshFvWkdO3wyHC0GQkmVUFN0OevzXRSLaV/ZqAJGpfh66wGMa04AWEX0tZdP21Ux NEmE2gERD+Djf+Yh5Wma+Y506zPLOGzVG8ekldJ6GmFSNMZG9XESaiM4sJE1jAtgMwIBezZe 8cSdTtoalLHfgFLPVAUTpk5mY9EhFGmK2Ee9A3T+vFxujaCpOBy+OGF3N79YNuFSN8Thk+Fj mnH4374ElcRM9n3JT+toi712L6ezHmTtIQ6DL6h2dFyx2Wv7DZMDh0ScHiCpNX+hRvrMz5YA wlOksY0loAw/kG2Stj2XzWjvWWJ+BUbXrJ4A+A8rQ2A1KfQywKYHXQfCC5MbsQ8s807TiBs0 UWG9/v2ARR/vbvTTmiSnp+MpC62ETgYKykFfyBscOcey9zqoYV2iw2VSN9mSPKxloesR2C2x C2Wpi8jgblVldQMy6iw4VHAhXSru4TNSQk2oA7QWwpJ8z9EWWJsXKTwgXCz0BqKBN/xooWp1 JTcp/Wj0Q==
- Ironport-hdrordr: A9a23:6fg7XKlbx3tJpjDd7Yh13ioAF7npDfNMiWdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcLC7V5Voj0mskKKdxbNhRYtKOzOWw1dATbsSlLcKpgeNJ8SQzI5gPM tbAstD4ZjLfCJHZKXBkXaF+rQbsb66GcmT7I+xrkuFDzsaDZ2Ihz0JdjpzeXcGIDWua6BJdq Z1saF81kedkDksH7KGL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftxK/mHwOe1hI+VSoK5bs562 DKnyHw+63m6piAu1Xh/l6Wy64TtMrqy9NFCsDJos8JKg/0ggLtSJV9V6aEtDUVpvjqzFoxit HDrzopIsw2wXLMeWOepwfrxmDboX0Twk6n7WXdrWrooMT/Sj5/I81dhbhBeh+cz0Y7ptlz3I 9Cwmrc7vNsfFv9tRW4w+KNewBhl0Kyr3ZnuekPj0ZHWY9bTLNKt4QQ8G5cDZ9FNiPn74IMFv VoEajnlb9rWGLfS0qcknhkwdSqUHh2NhCaQnIassjQ6DRSlGAR9Tps+OUv2lM7sL4tQZhN4O rJdo5ykqtVc8MQZaVhQM8cXMqeEAX2MFzxGVPXBW6iOLAMOnrLpZKyyq4y/vuWdJsBy4Z3sI jdUWlfqXU5dyvVeIKzNaVwg1DwqViGLHfQIpk03ek6hlS8fsumDcS7ciFuryP6yM9vR/EyWJ 6ISeBr6rHYXC/T8L1yrn3DsqlpWAcjufIuy6cGsnK107b2w97Rx5vmWceWAobROhAZfU66Kk c/fVHIVbZ9BwaQKzLFvCQ=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Nov 18, 2022 at 12:33:00PM +0000, Andrew Cooper wrote:
> On 18/11/2022 10:31, Jan Beulich wrote:
> > Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has
> > exposed a problem with the marking of the respective vector as
> > pending: For quite some time Linux has been checking whether any stale
> > ISR or IRR bits would still be set while preparing the LAPIC for use.
> > This check is now triggering on the upcall vector, as the registration,
> > at least for APs, happens before the LAPIC is actually enabled.
> >
> > In software-disabled state an LAPIC would not accept any interrupt
> > requests and hence no IRR bit would newly become set while in this
> > state. As a result it is also wrong for us to mark the upcall vector as
> > having a pending request when the vLAPIC is in this state.
>
> I agree with this.
>
> > To compensate for the "enabled" check added to the assertion logic, add
> > logic to (conditionally) mark the upcall vector as having a request
> > pending at the time the LAPIC is being software-enabled by the guest.
>
> But this, I don't think is appropriate.
>
> The point of raising on enable is allegedly to work around setup race
> conditions. I'm unconvinced by this reasoning, but it is what it is,
> and the stated behaviour is to raise there and then.
>
> If a guest enables evtchn while the LAPIC is disabled, then the
> interrupt is lost. Like every other interrupt in an x86 system.
>
> I don't think there is any credible way a guest kernel author can expect
> the weird evtchn edgecase to wait for an arbitrary point in the future,
> and it's a corner case that I think is worth not keeping.
We would then need some kind of fix in order to clear
evtchn_upcall_pending, because having that set without an interrupt
pending on the vLAPIC will result in no further event channel callback
interrupts being injected (see vcpu_mark_events_pending()).
Maybe we want to change vcpu_mark_events_pending() so that it always
tries to inject the vector even if evtchn_upcall_pending is already
set by calling hvm_assert_evtchn_irq() unconditionally?
Thanks, Roger.
|
