From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49308 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1POBAo-00006f-OM
	for qemu-devel@nongnu.org; Thu, 02 Dec 2010 10:34:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1POBAj-0004vt-Jr
	for qemu-devel@nongnu.org; Thu, 02 Dec 2010 10:34:18 -0500
Received: from mx1.redhat.com ([209.132.183.28]:42954)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1POBAj-0004vc-Cy
	for qemu-devel@nongnu.org; Thu, 02 Dec 2010 10:34:13 -0500
Message-ID: <4CF7BC54.2080909@redhat.com>
Date: Thu, 02 Dec 2010 17:33:40 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1291220718.32004.1696.camel@laptop>
	<20101201172953.GF8073@linux.vnet.ibm.com>
	<1291225502.32004.1787.camel@laptop>
	<20101201180040.GH8073@linux.vnet.ibm.com>
	<1291230582.32004.1927.camel@laptop> <4CF76440.30500@redhat.com>
	<20101202114700.GA18445@linux.vnet.ibm.com>
	<4CF793FF.4010504@redhat.com>
	<20101202131312.GC18445@linux.vnet.ibm.com>
	<4CF7A3F8.1010802@redhat.com>
	<20101202152716.GA16411@linux.vnet.ibm.com>
In-Reply-To: <20101202152716.GA16411@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to
	start/stop a VCPU (v2)
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: vatsa@linux.vnet.ibm.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, kvm@vger.kernel.org, Mike Galbraith <efault@gmx.de>, qemu-devel@nongnu.org, Chris Wright <chrisw@sous-sol.org>, Anthony Liguori <aliguori@linux.vnet.ibm.com>

On 12/02/2010 05:27 PM, Srivatsa Vaddagiri wrote:
> >  >Even that would require some precaution in directed yield to ensure that it
> >  >doesn't unduly inflate vruntime of target, hurting fairness for other guests on
> >  >same cpu as target (example guest code that can lead to this situation
> >  >below):
> >  >
> >  >vcpu0:				vcpu1:
> >  >
> >  >				spinlock(A);
> >  >
> >  >spinlock(A);
> >  >
> >  >                          	while(1)
> >  >				;
> >  >
> >  >			 	spin_unlock(A);
> >
> >  directed yield should preserve the invariant that sum(vruntime) does
> >  not change.
>
> Hmm don't think I understand this invariant sum() part. Lets take a simple
> example as below:
>
>
> p0	->  A0 B0 A1
>
> p1	->  B1 C0 C1
>
> A/B/C are VMs and A0 etc are virtual cpus. p0/1 are physical cpus
>
> Let's say A0/A1 hit AB-BA spin-deadlock (which one can write in userspace
> delibrately). When A0 spins and exits (due to PLE) what does its directed yield
> do? Going by your statement, it can put target before current, leading to
> perhaps this arrangement in runqueue:
>
> p0	->  A1 B0 A0
>
> Now A1 spins and wants to do a directed yield back to A0, leading to :
>
> p0	->  A0 B0 A1
>
> This can go back and forth, starving B0 (iow leading to some sort of DoS
> attack).
>
> Where does the "invariant sum" part of directed yield kick in to avoid such
> nastiness?

A0 and A1's vruntime will keep growing, eventually B will become 
leftmost and become runnable (assuming leftmost == min vruntime, not 
sure what the terminology is).

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