On Sun, Apr 19, 2009 at 05:06:29PM +0200, Jan Kiszka wrote: > Jan Kiszka wrote: > > Gleb Natapov wrote: > >> On Sat, Apr 18, 2009 at 07:28:20PM +0300, Gleb Natapov wrote: > >>>> So this patch may either expose a bug in the svm emulation of qemu or > >>>> comes with a subtle regression that only triggers due to qemu's timing. > >>>> This needs to be understood. Gleb, any progress on reproducing it on > >>>> your side? > >>>> > >>> I reproduced it and I am debugging it. In my case the boot hangs on sti;hlt > >>> sequence. Instrumentation thus far shows that at this point interrupts no longer > >>> injected because ppr value is too big. Need to see why, but tpr handling > >>> is not complete in qemu svm. May be this is the reason. Will know more > >>> tomorrow. > >>> > >> I've looked into this and my conclusion is that if you are not going to > >> develop SVM in qemu don't use it just yet. > > > > We had a resource conflict regarding SVM capable AMD boxes and a tight > > schedule, so we decided to pick qemu as initial development platform. > > Turns out that this has was a bit too optimistic. :) > > > >> QEMU doesn't handle exceptions > >> during event injection properly. Actually it does not handle it at all, > >> so if PF happens during interrupt injection interrupt is lost and, what > >> worse, is never acked. If interrupt was high prio it blocks all other > >> interrupts. > >> > >> The patch below adds exception handling during event injection. Valid > >> flag removed from EVENTINJ only after successful injection and EVENTINJ > >> is copied to EXITINTINFO on exit. Can you give it a try? > > > > Ah, great, thanks. Will test. > > I can confirm: patch below makes my kvm-in-qemu test case happy, too. > Maybe you want to post this with changelog and signed-off to qemu-devel. > Yeah, I'll reformat and submit. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
