Re: kvm crashes with spice while loading qxl

[Avi Kivity <avi@redhat.com>]

On 03/07/2011 06:13 PM, Marcelo Tosatti wrote:
> On Sun, Mar 06, 2011 at 12:38:44PM +0200, Avi Kivity wrote:
> >  On 03/05/2011 06:35 PM, Marcelo Tosatti wrote:
> >  >Regarding global mutex, TCG and KVM execution behaviour can become more
> >  >similar wrt locking by dropping qemu_global_mutex during generation and
> >  >execution of TBs.
> >
> >  How can you do that?  During generation, a device can assert the
> >  reset line, changing cpu modes,
>
> Writes to CPUState fields needs can moved to vcpu thread context
> (run_on_cpu), and reads performed under a lock.
>
> Good thing is most CPUState accesses are local to vcpu context.

That's a really good idea.  And in fact that's what we do in kvm, if we 
have something to do to a cpu we queue it up in vcpu->requests and let 
the vcpu thread process it.

> >   or move the memory map.
>
> Memory map can be protected by a read-write lock initially, so that vcpu
> thread holds it for read. Later can be converted to URCU.

rwlock is insufficient, need a way to force the vcpu off so a writer can 
actually do something.

So we need some kind of priority rwlock where a reader lets the lock 
know how it can force it off in case a writer comes along.

> Is write access to memory map necessary from vcpu context?

Yes, examples writes to PCI BARs or the VGA windows at 0xa0000.

We can move them to a device thread, but the vcpu thread will have to 
wait for it (so it needs to drop any locks anyway).

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