All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Paul Durrant <paul@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] x86/dpci: EOI interrupt regardless of it's masking status
Date: Wed, 6 Jan 2021 12:22:03 +0100	[thread overview]
Message-ID: <696e5198-9634-bf5f-d870-99614aeb5c2a@suse.com> (raw)
In-Reply-To: <20210105183143.94547-1-roger.pau@citrix.com>

On 05.01.2021 19:31, Roger Pau Monne wrote:
> Modify hvm_pirq_eoi to always EOI the interrupt if required, instead
> of not doing such EOI if the interrupt is routed through the vIO-APIC
> and the entry is masked at the time the EOI is performed.
> 
> Further unmask of the vIO-APIC pin won't EOI the interrupt, and thus
> the guest OS has to wait for the timeout to expire and the automatic
> EOI to be performed.
> 
> This allows to simplify the helpers and drop the vioapic_redir_entry
> parameter from all of them.
> 
> Fixes: ccfe4e08455 ('Intel vt-d specific changes in arch/x86/hvm/vmx/vtd.')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> ---
> Kind of RFC, I've been trying to figure out how this was supposed to
> work, and couldn't find any reason why the EOI is not performed if the
> interrupt is masked on the emulated IO-APIC. I might be missing
> something, but relying on the EOI timeout in that case seems wrong.

Fully agree. If archeology didn't surface an explanation, I'd
assume the dependency was put in mistakenly, perhaps because
most other operations need to respect the mask bit.

Jan


  reply	other threads:[~2021-01-06 11:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 18:31 [PATCH] x86/dpci: EOI interrupt regardless of it's masking status Roger Pau Monne
2021-01-06 11:22 ` Jan Beulich [this message]
2021-01-06 21:04 ` Wei Liu
2021-01-07  9:41   ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=696e5198-9634-bf5f-d870-99614aeb5c2a@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.