[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>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 24 Nov 2022 10:33:58 +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=cbWtRUD6295XrWrZxbiIlgQl0Q7ZXI2GS91OHkIterU=; b=jyG2ev2HS/3tkrx5zrhmOrMNpgPN/2wy+P4Faxfn4G/IRCOpDzwhrkZNKF/sWSRqGLFloJjLFtiHmR1Q05/pbf0Oj6rpKiY8D+6Ar7BXeGn1HfyPdeApcBQYEihyd23Q87GQVXVgRP141sib6Qpd8f8X2K727bNi+3VdLrZEyHB1iv87gSaBbDXLHiUJvHOWzflCevQ6ZMShWjq2ihS+GfWpT3xGpIsfqtB9xz/nC8EQKGBRQNcsVpUINZ+NxxK9yDTpTwh2FIP4sy6BHIlIhUCrhI8uaVTSqGWigqI2FjgsSsnUXbl/oNNNkBof5EpRf1AxxlwlUFxYcj4HH57OrQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KEHS/fVEsUekBGFOuLxckT5PenW4/8lUyuBuemZ6RaMVTyIeQNbNi+ymwm6Nof+WthJIbBbd+1fyEjtw7x8K3P7CSpk7ZN9sagb3dVdM9wR+BxR3CNDPUH86e06sg1mSYAO0zdxyPzihi4Z2Vfub0YQMyegQ1RJYZS8xLuIlZYKI8x/slnR7q6ZrTJex534TrrngCSJ0zbMVphTai9ykVqWf7xneILGKGe7gAgcnWZNj6cixPRYDUbb1c2iZcOgwmyOXEsc/VYLVmD0LKce3jtMHfMEMS1r3PX10kqAWkiPWRimY8Pax6jD+J3A1DEe1GTeTBasmyRbHRlwM25C61Q==
- 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>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 24 Nov 2022 09:34:28 +0000
- Ironport-data: A9a23:DYYajaLSm1WI3ncTFE+R5JQlxSXFcZb7ZxGr2PjKsXjdYENShjZWz WBNWTyGO/uMNGKhKtB1aNi2oUJUv8fdyIMxHFRlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/rOHv+kUrWs1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpJrfPdwP9TlK6q4mlB5wZiPaojUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c4oHDB+9 e42AQkVYzbdlb6yzbSWYddF05FLwMnDZOvzu1lG5BSAVLMMZ8CGRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/dnpTGNnGSd05C0WDbRUsaNSshP2F6Ru 0rN/njjAwFcP9uaodaA2iLx3rKQxHukMG4UPK2EzPtvmAy9+mUSLCEuRWfrm/KotmfrDrqzL GRRoELCt5Ma9kamU938VB2Qu2Ofs1gXXN84O/I+wBGAzOzT+QnxLnANUzppeNEg8sgsSlQCx lKP2t/kGzFrmLmUUm6GsKeZqyuoPioYJnNEYjULJTbp+PHmqYA3yxjJHtBqFffsisWvQG+gh TeXsCI5mrMfy9YR0Lm29kzGhDTqoYXVSgky5UPcWWfNAh5FWbNJrreAsTDzhcus5q7AJrVdl BDoQ/Sj0d0=
- Ironport-hdrordr: A9a23:sI3iW6zcuYSpmmFr8plnKrPxTOgkLtp133Aq2lEZdPULSKGlfp GV9sjziyWetN9wYh4dcB67Scy9qFfnhOZICO4qTMyftWjdyRKVxeRZgbcKrAeBJ8STzJ8/6U 4kSdkFNDSSNykEsS+Z2njeLz9I+rDunsGVbKXlvhFQpGlRGt1dBmxCe2Km+yNNNWt77c1TLu vg2iMLnUvXRV0nKuCAQlUVVenKoNPG0LrgfB49HhYirCWekD+y77b+Mh6AmjMTSSlGz7sO+X XM11WR3NToj9iLjjvnk0PD5ZVfn9XsjvNFGcy3k8AQbhn8lwqyY4xlerua+BQ4uvum5loGmM TF5z0gI8NwwXXMeXzdm2qn5yDQlBIVr1Pyw16RhnXu5eT/WTIBEsJEwaZUaAHQ5UYMtMx1lP sj5RPQi7NnSTf72Ajt7dnBUB9n0mKyvHoZiOYWy1hSS5EXZrN9pZEWuGlVDJADNiTn751PKp gmMOjsoNJtNX+KZXHQuWdihPSqQ3QIBx+DBnMPv8SEugIm6UxR/g89/ogyj30A/JUyR91v/O LfKJllk7lIU4s/cb99LP1pe7r4NkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLQV0ZoJno jbWl8wjx98R6vXM7zP4HR3yGGPfI3kNg6diP22pqIJ9oEUfYCbcBFqEzsV4o6dS/Z2OLyoZx /8AuMTPxbZFxqfJW945XyBZ3BsEwhubCQ0gKdOZ7vcmLO9FqTa8srmTd30GJ3BVR4ZZ0KXOA pxYNG0HrQM0nyW
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, Nov 24, 2022 at 10:11:05AM +0100, Jan Beulich wrote:
> On 24.11.2022 10:06, Roger Pau Monné wrote:
> > On Thu, Nov 24, 2022 at 09:42:40AM +0100, Roger Pau Monné wrote:
> >> On Thu, Nov 24, 2022 at 08:59:00AM +0100, Jan Beulich wrote:
> >>> - problematic wrt evtchn_upcall_pending, once set, preventing event
> >>> injection later on.
> >>> As you may have inferred already, I'm inclined to suggest to drop the
> >>> the is_vcpu_online() check from hvm_set_callback_via().
> >>>
> >>> One related question here is whether vlapic_do_init() shouldn't have
> >>> the non-architectural side effect of clearing evtchn_upcall_pending.
> >>> While this again violates the principle of the hypervisor only ever
> >>> setting that bit, it would deal with the risk of no further event
> >>> injection once the flag is set, considering that vlapic_do_init()
> >>> clears IRR (and ISR).
> >>
> >> That would seem sensible to me, and was kind of what I was suggesting
> >> in:
> >>
> >> https://lore.kernel.org/xen-devel/Y3eO0bMKRPYJc2yQ@Air-de-Roger/
> >
> > Another option would be for vcpu_mark_events_pending() to
> > unconditionally call hvm_assert_evtchn_irq() regardless of the state
> > of evtchn_upcall_pending.
>
> I think you said so before, and ...
>
> > This will create some spurious events.
>
> ... I continue to be afraid of s/some/many/.
Not _that_ many I think, as we can only queue one pending interrupt in
IRR.
> This event delivery is meant
> to be kind of edge triggered, and I think it is a reasonable model to treat
> the flag going from 0 to 1 as the "edge".
Hm, it's a weird interrupt model I would say. In some aspects it's
similar to level (as the line stays asserted until it's cleared), but
we don't get new interrupts injected into the APIC.
Maybe the right mode would be to treat evtchn_upcall_pending as a
level triggered line and keep injecting interrupts until the line is
deasserted (ie: evtchn_upcall_pending == 0)?
Sorry, I feel like I'm asking more questions that providing answers.
Roger.
|
