Re: [PATCH 2/2] KVM: SVM: check for progress after IRET interception

[Avi Kivity <avi@redhat.com>]

On 02/03/2011 06:14 PM, Jan Kiszka wrote:
> On 2011-02-03 16:58, Avi Kivity wrote:
> >  On 02/03/2011 05:55 PM, Jan Kiszka wrote:
> >>>
> >>>   What's an interrupt window without IRET interception?
> >>
> >>  I don't the details, but I thought you could get something like an
> >>  interrupt-window-open interception by (fake-)injecting an IRQ and
> >>  intercepting on VIRQ acceptance. That will not work if returning to and
> >>  staying in irq-disabled guest code, therefore the timeout, but it should
> >>  be most efficient (specifically if the guest uses NMIs for things like
> >>  perf).
> >>
> >
> >  Since NMIs are used to break out of irq-disabled regions (watchdog, NMI
> >  IPIs during reboots) I'm wary of such a solution.
>
> Right, but we already use it for Intel. The timeout ensures that you
> can't get stuck forever. I think Xen works this way as well (minus the
> timeout - last time I checked).

Only without vnmi support, yes?  In that case, we can't do any better.  
In this case, we can, and we should, even at the expense of performance 
or ridiculous complexity.

> I hope AMD would finally realize what the left behind and improve it so
> that we can declare whatever "nice" solution just a temporary
> workaround. Will still take a few years, but we had the same situation
> on Intel.

Me, too, except that I'd like a correct implementation on the existing 
ISA.  As time goes by, it becomes more and more difficult to declare 
that all previous processors are an unimportant minority.

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