[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from r
From: |
Glauber Costa |
Subject: |
[Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from reset handlers |
Date: |
Fri, 11 Sep 2009 11:28:47 -0300 |
User-agent: |
Jack Bauer |
On Fri, Sep 11, 2009 at 02:28:41PM +0200, Jan Kiszka wrote:
> Glauber Costa wrote:
> > On Fri, Sep 11, 2009 at 01:52:05PM +0200, Jan Kiszka wrote:
> >> Glauber Costa wrote:
> >>> On Fri, Sep 11, 2009 at 01:15:49PM +0200, Jan Kiszka wrote:
> >>>> Anthony Liguori wrote:
> >>>>> From: Glauber Costa <address@hidden>
> >>>>>
> >>>>> Doing this will make the vcpu ioctl be issued from the I/O thread,
> >>>>> instead
> >>>>> of cpu thread. The correct behaviour is to call it from within the cpu
> >>>>> thread,
> >>>>> as soon as we are ready to go.
> >>>> Note that in the good old days, this used to work properly (in qemu-kvm)
> >>>> as registers write-back was routed through on_vcpu.
> >>> I believe we should avoid the use of those things, specially at
> >>> initialization. They are
> >>> totally racy and fragile. One way to do that, is to do all the reset
> >>> functions inside the
> >>> cpu thread.
> >> As all this used to work fine in practice in upstream as well as in
> >> qemu-kvm, I'm slightly unhappy about the current situation.
> >>
> >>> I already have something hacked up for this, will send as soon as I
> >>> finish testing.
> >> OK, looking forward.
> >>
> >> BTW, what's the state of the fix for the guest-debug regression under KVM?
> > The last proposal I sent for queue_work would fix it, but it is a too big
> > job, for just a fix.
> > If you are not using the IO thread, I can do what I did in there: define
> > on_vcpu to be
> > conditional to the I/O thread, and in case it is not defined, just call the
> > function
> >
> > What do you think?
>
> IIUC, iothread and kvm is still broken in many ways here, so I'm fine
> with a temporary workaround. Just make sure that it doesn't cause too
> much merging pain downstream.
Actually, with the fixes I sent this week, it should work fine.