From: Anthony Liguori <anthony@codemonkey.ws>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
Date: Tue, 25 Jan 2011 18:18:17 -0600 [thread overview]
Message-ID: <4D3F6849.2060701@codemonkey.ws> (raw)
In-Reply-To: <AANLkTi=JbDFZyjLgBePSMe5g2UDpGX6MVXXez10wFE8W@mail.gmail.com>
On 01/25/2011 01:59 PM, Stefan Hajnoczi wrote:
> int kvm_cpu_exec(CPUState *env)
> {
> struct kvm_run *run = env->kvm_run;
> int ret;
>
> DPRINTF("kvm_cpu_exec()\n");
>
> do {
>
> This is broken because a signal handler could change env->exit_request
> after this check:
>
> #ifndef CONFIG_IOTHREAD
> if (env->exit_request) {
> DPRINTF("interrupt exit requested\n");
> ret = 0;
> break;
> }
> #endif
>
Yeah, this is classic signal/select race with ioctl(KVM_RUN) subbing in
for select. But this is supposed to be mitigated by the fact that we
block SIG_IPI except for when we execute KVM_RUN which means that we can
reliably send SIG_IPI.
Of course, that doesn't help for SIGALRM unless we send a SIG_IPI from
the SIGALRM handler which we do with the I/O thread but not w/o it. At
any rate, post stable-0.14, I want to enable I/O thread by default so I
don't know that we really need to fix this...
> if (kvm_arch_process_irqchip_events(env)) {
> ret = 0;
> break;
> }
>
> if (env->kvm_vcpu_dirty) {
> kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
> env->kvm_vcpu_dirty = 0;
> }
>
> kvm_arch_pre_run(env, run);
> cpu_single_env = NULL;
> qemu_mutex_unlock_iothread();
>
> env->exit_request might be set but we still reenter, possibly without
> rearming the timer:
> ret = kvm_vcpu_ioctl(env, KVM_RUN, 0);
>
>
>>> I can think of two solutions:
>>> 1. Block SIGALRM during critical regions, not sure if the necessary
>>> atomic signal mask capabilities are there in KVM. Haven't looked at
>>> TCG yet either.
>>> 2. Make a portion of the timer code signal-safe and rearm the timer
>>> from within the SIGLARM handler.
>>>
>>>
>> Or, switch to timerfd and stop using a signal based alarm timer.
>>
> Doesn't work for !CONFIG_IOTHREAD.
>
Yeah, we need to get rid of !CONFIG_IOTHREAD. We need to run select()
in parallel with TCG/KVM and interrupt the VCPUs appropriately when
select() returns.
Regards,
Anthony Liguori
> Stefan
>
>
next prev parent reply other threads:[~2011-01-26 0:18 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-12 15:02 [Qemu-devel] [PATCH v5 0/4] virtio: Use ioeventfd for virtqueue notify Stefan Hajnoczi
2010-12-12 15:02 ` [Qemu-devel] [PATCH v5 1/4] virtio-pci: Rename bugs field to flags Stefan Hajnoczi
2010-12-12 15:02 ` [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify Stefan Hajnoczi
2011-01-24 18:54 ` Kevin Wolf
2011-01-24 19:36 ` Michael S. Tsirkin
2011-01-24 19:48 ` Kevin Wolf
2011-01-24 19:47 ` Michael S. Tsirkin
2011-01-24 20:05 ` Kevin Wolf
2011-01-25 7:12 ` Stefan Hajnoczi
2011-01-25 9:49 ` Stefan Hajnoczi
2011-01-25 9:54 ` Stefan Hajnoczi
2011-01-25 11:27 ` Michael S. Tsirkin
2011-01-25 13:20 ` Stefan Hajnoczi
2011-01-25 14:07 ` Stefan Hajnoczi
2011-01-25 19:18 ` Anthony Liguori
2011-01-25 19:45 ` Stefan Hajnoczi
2011-01-25 19:51 ` Anthony Liguori
2011-01-25 19:59 ` Stefan Hajnoczi
2011-01-26 0:18 ` Anthony Liguori [this message]
2010-12-12 15:02 ` [Qemu-devel] [PATCH v5 3/4] virtio-pci: Don't use ioeventfd on old kernels Stefan Hajnoczi
2010-12-12 15:02 ` [Qemu-devel] [PATCH v5 4/4] docs: Document virtio PCI -device ioeventfd=on|off Stefan Hajnoczi
2010-12-12 15:14 ` [Qemu-devel] Re: [PATCH v5 0/4] virtio: Use ioeventfd for virtqueue notify Stefan Hajnoczi
2010-12-12 20:41 ` Michael S. Tsirkin
2010-12-12 20:42 ` Michael S. Tsirkin
2010-12-12 20:56 ` Michael S. Tsirkin
2010-12-12 21:09 ` Michael S. Tsirkin
2010-12-13 10:24 ` Stefan Hajnoczi
2010-12-13 10:38 ` Michael S. Tsirkin
2010-12-13 13:11 ` Stefan Hajnoczi
2010-12-13 13:35 ` Michael S. Tsirkin
2010-12-13 13:36 ` Michael S. Tsirkin
2010-12-13 14:06 ` Stefan Hajnoczi
2010-12-13 15:27 ` Stefan Hajnoczi
2010-12-13 16:00 ` Michael S. Tsirkin
2010-12-13 16:29 ` Stefan Hajnoczi
2010-12-13 16:30 ` Michael S. Tsirkin
2010-12-13 16:12 ` Michael S. Tsirkin
2010-12-13 16:28 ` Stefan Hajnoczi
2010-12-13 17:57 ` Stefan Hajnoczi
2010-12-13 18:52 ` Michael S. Tsirkin
2010-12-15 11:42 ` Stefan Hajnoczi
2010-12-15 11:48 ` Stefan Hajnoczi
2010-12-15 12:00 ` Michael S. Tsirkin
2010-12-15 12:14 ` Michael S. Tsirkin
2010-12-15 12:59 ` Stefan Hajnoczi
2010-12-16 16:40 ` Stefan Hajnoczi
2010-12-16 23:39 ` Michael S. Tsirkin
2010-12-19 14:49 ` Michael S. Tsirkin
2011-01-06 16:41 ` Stefan Hajnoczi
2011-01-06 17:04 ` Michael S. Tsirkin
2011-01-06 18:00 ` Michael S. Tsirkin
2011-01-07 8:56 ` Stefan Hajnoczi
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=4D3F6849.2060701@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).