From: Carsten Otte <carsteno@de.ibm.com>
To: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
Cc: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Marcelo Tosatti
<mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 0/7] Consolidate vcpu ioctl locking
Date: Fri, 21 May 2010 07:35:03 +0000 [thread overview]
Message-ID: <4BF637A7.3010203@de.ibm.com> (raw)
In-Reply-To: <20442124-2400-4273-A256-6846017D3141-l3A5Bk7waGM@public.gmane.org>
On 15.05.2010 10:26, Alexander Graf wrote:
> On S390, I'm also still sceptical if the implementation we have really works. A device injects an S390_INTERRUPT with its address and on the next vcpu_run, an according interrupt is issued. But what happens if two devices trigger an S390_INTERRUPT before the vcpu_run? We'd have lost an interrupt by then...
We're safe on that: the interrupt info field in both struct kvm (for
floating interrupts) and struct vcpu (for cpu local interrupts) have
their own locking and can queue up interrupts.
cheers,
Carsten
next prev parent reply other threads:[~2010-05-21 7:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 11:17 [PATCH 0/7] Consolidate vcpu ioctl locking Avi Kivity
2010-05-13 11:17 ` [PATCH 1/7] KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls Avi Kivity
2010-05-13 11:17 ` [PATCH 3/7] KVM: move vcpu locking to dispatcher for generic " Avi Kivity
[not found] ` <20100515000316.GD2502@amt.cnet>
[not found] ` <20100515000316.GD2502-I4X2Mt4zSy4@public.gmane.org>
2010-05-16 11:22 ` [PATCH 3/7] KVM: move vcpu locking to dispatcher for generic Avi Kivity
[not found] ` <1273749459-622-1-git-send-email-avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-13 11:17 ` [PATCH 2/7] KVM: x86: Add missing locking to arch specific vcpu ioctls Avi Kivity
2010-05-13 11:17 ` [PATCH 4/7] KVM: x86: Lock arch specific vcpu ioctls centrally Avi Kivity
2010-05-13 11:17 ` [PATCH 5/7] KVM: s390: Centrally lock arch specific vcpu ioctls Avi Kivity
2010-05-13 11:17 ` [PATCH 6/7] KVM: PPC: Centralize locking of " Avi Kivity
2010-05-13 11:57 ` [PATCH 0/7] Consolidate vcpu ioctl locking Alexander Graf
2010-05-13 12:01 ` Avi Kivity
2010-05-13 12:03 ` Avi Kivity
[not found] ` <4BEBEA7E.80202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-13 12:03 ` Avi Kivity
[not found] ` <4BEBEAAE.9030502-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-13 12:18 ` Alexander Graf
[not found] ` <24423079-CDE0-4DEA-BC73-3B6976BE0CA6-l3A5Bk7waGM@public.gmane.org>
2010-05-13 12:29 ` Avi Kivity
2010-05-13 19:49 ` Alexander Graf
[not found] ` <4BEE3C56.2070007@redhat.com>
[not found] ` <F7406BC6-90A8-43B9-A57F-6B9350B6D356@suse.de>
[not found] ` <4BEE544B.50405@redhat.com>
[not found] ` <20442124-2400-4273-A256-6846017D3141@suse.de>
[not found] ` <20442124-2400-4273-A256-6846017D3141-l3A5Bk7waGM@public.gmane.org>
2010-05-15 17:30 ` Avi Kivity
[not found] ` <4BEEDA37.2080209-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-16 1:00 ` Alexander Graf
[not found] ` <6BE91F3A-C60C-47C0-9EA4-E5F5971B09C2-l3A5Bk7waGM@public.gmane.org>
2010-05-16 8:23 ` Avi Kivity
[not found] ` <4BEFAB6D.9000904-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-16 9:01 ` Alexander Graf
[not found] ` <DE2111D3-1AC9-45A3-A2BE-B6D012ECCAFE-l3A5Bk7waGM@public.gmane.org>
2010-05-16 9:09 ` Avi Kivity
[not found] ` <4BEFB666.50107-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-16 9:35 ` Alexander Graf
[not found] ` <04ED5A08-BE13-4C60-B152-EA5541975779-l3A5Bk7waGM@public.gmane.org>
2010-05-16 9:47 ` Avi Kivity
[not found] ` <4BEFBF42.6020208-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-05-16 10:19 ` Alexander Graf
2010-05-21 7:35 ` Carsten Otte [this message]
2010-05-13 11:17 ` [PATCH 7/7] KVM: Consolidate arch specific " Avi Kivity
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=4BF637A7.3010203@de.ibm.com \
--to=carsteno@de.ibm.com \
--cc=agraf-l3A5Bk7waGM@public.gmane.org \
--cc=avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox