qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
>
>    

  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).