Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2)

Avi Kivity
2010-12-02T15:34:16Z

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