Re: [RFC] QEMU/KVM: dedicated IO thread

[Avi Kivity <avi@qumranet.com>]

Marcelo Tosatti wrote:
> Avi was concerned that this would cause problems with migration. I
> haven't specifically tested it yet, but it seems there will be no
> problems introduced by this change: the IO thread will stop all vcpu's
> in the same way the vcpu0 thread did before.
>   

I believe this is broken for smp_cpus > 1, and will with this change 
will be broken even for non smp.  The pause/resume logic is rotten.

> QEMU/KVM: separate thread for IO handling
>
> Move IO processing from vcpu0 to a dedicated thread.
>
> This removes load on vcpu0 by allowing better cache locality and also
> improves latency.
>
> We can now block signal handling for IO events, so sigtimedwait won't
> race with handlers:
>
> - Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because
> the "next_cpu" variable is not initialized in the KVM path, meaning that
> processing of timer expiration might be delayed until the next vcpu0 exit.
>   

I think we call main_loop_wait() is called unconditionally after every 
signal.

> - Processing of IO events will not be unnecessarily interrupted.
>
>
> Index: kvm-userspace.io/libkvm/libkvm.c
> ===================================================================
> --- kvm-userspace.io.orig/libkvm/libkvm.c
> +++ kvm-userspace.io/libkvm/libkvm.c
> @@ -388,9 +388,6 @@ int kvm_create(kvm_context_t kvm, unsign
>  	if (r < 0)
>  	        return r;
>  	kvm_create_irqchip(kvm);
> -	r = kvm_create_vcpu(kvm, 0);
> -	if (r < 0)
> -		return r;
>  
>  	return 0;
>  }
>   

Please put this and the corresponding qemu change in a separate patch.

[...lots more...]

Looks good.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/