From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>,
Roman Kagan <rkagan@virtuozzo.com>,
"Denis V . Lunev" <den@openvz.org>
Subject: Re: [PATCH v2 2/3] x86/kvm/hyper-v: remove stale entries from vec_bitmap/auto_eoi_bitmap on vector change
Date: Fri, 9 Mar 2018 16:45:16 +0100 [thread overview]
Message-ID: <20180309154516.GA21100@flask> (raw)
In-Reply-To: <87muzhe0ls.fsf@vitty.brq.redhat.com>
2018-03-09 16:21+0100, Vitaly Kuznetsov:
> Radim Krčmář <rkrcmar@redhat.com> writes:
> > This looks like it solves the problem when we get two SINTs with the
> > same vector back-to-back , but shouldn't these bits really be cleared on
> > EOI (either auto or manual)?
>
> Hmm,
>
> I was trying to address the following issue: guest programs SynIC's
> SINTx with some vector but later re-programs it with a different
> one. Without the patch synic->vec_bitmap and synic->auto_eoi_bitmap keep
> stale data. If there's no concurrent interrupt than we're safe, but what
> happens if there is one...
>
> kvm_hv_synic_send_eoi() already goes through all SINTx but we already
> updated vector so it won't find any. We could've added something like
> 'old_vector' but what if the request with this vector came _after_ we
> re-programed SynIC (and, so, it wasn't meant to be serviced by SynIC?)?
I now read that TLFS puts the responsitiblity on guest OS when toggling
auto-EOI, so let's assume that the OS is to blame for disabling/changing
vectors with pending interrupts as well.
Applied all, thanks.
next prev parent reply other threads:[~2018-03-09 15:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 14:15 [PATCH v2 0/4] x86/kvm/hyper-v: More fixes for TSC page clocksource for Hyper-V on KVM Vitaly Kuznetsov
2018-03-01 14:15 ` [PATCH v2 1/3] x86/kvm/hyper-v: add reenlightenment MSRs support Vitaly Kuznetsov
2018-03-01 14:15 ` [PATCH v2 2/3] x86/kvm/hyper-v: remove stale entries from vec_bitmap/auto_eoi_bitmap on vector change Vitaly Kuznetsov
2018-03-08 21:08 ` Radim Krčmář
2018-03-09 15:21 ` Vitaly Kuznetsov
2018-03-09 15:45 ` Radim Krčmář [this message]
2018-03-01 14:15 ` [PATCH v2 3/3] x86/kvm/hyper-v: inject #GP only when invalid SINTx vector is unmasked Vitaly Kuznetsov
2018-03-01 14:59 ` Roman Kagan
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=20180309154516.GA21100@flask \
--to=rkrcmar@redhat.com \
--cc=Michael.H.Kelley@microsoft.com \
--cc=den@openvz.org \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkagan@virtuozzo.com \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.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.