[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: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Fri, 18 Nov 2022 12:33:00 +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=zL55OUZT4Sr4OkWMRHz8kqZ0mKqRB9gitDIWm5zUuEI=; b=lJE3gOXpQ39M5bKUl7/3zUoCmhhoMyz1+Poi45YfCBVShUZoJc0tCqDntsNQHNxQSw5hMVi61RrXWvpHi7RTtdOiCSx5/ZzqV9Uw78ZcdH9avJPMebbcOyoNRwH0dDt+Uca4F2aIdjNMHg1CRUgpG3pgkheaCsafh3U6YDkyu19qubcHhLD2yray+BNsLknAx75OyAFL6GAjZamNyXbE3mv6i5RLcRwXZtjBgYf7laVmII09VyBgCXCBnBMTm3s7kA2LJzAw+BU2wSuxM8N9ndD31hvkE9KbeDkYM51JXIwjmTWc8rtUg64lkR+JLzU19lrV+MsFJzYmJ7hdjB3qIw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dlf0CX2djrbbYInKr2uS/VolwbkKcSAbI9OXEBgCbqhMS2TMV717P5dZlChLhZyB7VlWb/K7OEc/rpslkCVVtQAVofNnWHkoZS52AkG/RHQpwc9m76+RFena05VxzyE92SM9bWwY4VhY3reeUqivo8hsEp508f/BSKbzZVi9Wjbj9BBi6pjpM2raMg7q4vUTcRZTKqvgNN1OU1cbmF1WT1p/pPcvbY84p8TZGz+KzHXpMZRrpct1891xaratRSaUTbJtgeJcSAHsTO8W7622niCJ70xYSABt8ElWaTkp9YAtCP7o6mJy7xOgnD3tvkoAVI9caYJxicifWl0hglHlPg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>
- Delivery-date: Fri, 18 Nov 2022 12:33:27 +0000
- Ironport-data: A9a23:dskmgap76krcykSpT184FB3EtTteBmIoZBIvgKrLsJaIsI4StFCzt garIBnTa/qCY2Gkco9wb4qwoU8Av8OBz4MwSwY++CxkECtG+JuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpAFc+E0/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06W1wUmAWP6gR5gaHzilNVvrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAGspQRDSvruw+bKmcM41qMkaffb7I7pK7xmMzRmBZRonabbqZvySoPV+g3I3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3j+CraYKPEjCJbZw9ckKwj 2TK5WnmRDodM8SS02Gt+XOwnO7f2yj8Xer+EZXoqaA32QDDmgT/DjUmT3jimdzi1HWCQslEK GIPoDIEtbc9oRnDot7VGkfQTGS/lhwWVsdUEuY6wBqQ0aeS6AGcbkAUQzgEZNE4ucseQT0xy kTPj97vHSZosrCeVTSa7Lj8hSy2ETgYKykFfyBsZRMM/t3LsIw1yBXVQb5e/LWdi9T0HXT6x W+MpS1n37EL15dTjeO84EzNhC+qqt7RVAkp6w7LX2WjqARkeIqiYI/u4l/ehRpdELukopC6l CBss6CjAComXPlhSATlrD0xIYyU
- Ironport-hdrordr: A9a23:2Cb2B6FyAVNG4blzpLqFwJLXdLJyesId70hD6qkvc3Fom52j/f xGws5x6fatskdrZJkh8erwW5Vp2RvnhNNICPoqTM2ftW7dySeVxeBZnMHfKljbdxEWmdQtsp uIH5IeNDS0NykDsS+Y2nj2Lz9D+qjgzEnAv463oBlQpENRGthdBmxCe2Sm+zhNNW177O0CZf +hD6R8xwaISDAyVICWF3MFV+/Mq5nik4/nWwcPA1oK+RSDljSh7Z/9Cly90g0FWz1C7L8++S yd+jaJp5mLgrWe8FvxxmXT55NZlJ/IzcZCPtWFjow4OyjhkQGhYaVmQvmnsCouqO+ixV42mJ 3nogsmPe5093TNF1vF7yfF6k3F6nID+nXiwViXjT/IusriXg83DMJHmMZwbgbZw1BIhqA+7I t7m0ai87ZHBxLJmyrwo/LSUQtxq0ayqX0+1cYOkn1kV5cEYrM5l/1cwKoVKuZEIMvJ0vFhLA BcNrCb2B+QSyLCU5nthBgq/DVrZAVqIv7JeDlYhiXf6UkqoJkw9Tpl+CVYpAZByHt1ceg72w yPWJ4Y641mX4sYa7lwC/wGRtbyAmvRQQjUOGbXOlj/ErobUki94qIfzY9Fk91CQqZ4uqcaid DEShdVpGQyc0XhBYmH24BK6AnERCG4US72ws9T6pBlsvmkLYCbehGrWRQriY+tsv8fCsrUV7 K6P49XGebqKS/rFZxS1wPzVpFOIT0VUdETuNw8R1WSy/i7YrHCp6jearLeNbDtGTErVif2BW YCRiH6IIFa4kWiShbD8WzssrPWCznCFL5LYdvnFrIoufkw36V3w3gooEX84N2XIjtftaFzdF diIdrc49GGmVU=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHY+zjv47cM7GZ23kWVhiI/91aGOa5EnVaA
- Thread-topic: [PATCH] x86/HVM: don't mark evtchn upcall vector as pending when vLAPIC is disabled
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.
~Andrew
|
