From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] KVM: SVM: check for progress after IRET interception Date: Thu, 03 Feb 2011 18:20:35 +0200 Message-ID: <4D4AD5D3.1030706@redhat.com> References: <1296745369-12066-1-git-send-email-avi@redhat.com> <1296745369-12066-3-git-send-email-avi@redhat.com> <4D4AC4B5.7060009@redhat.com> <4D4AC7E3.7070408@siemens.com> <4D4ACA0D.4090707@redhat.com> <4D4ACFD9.9000203@siemens.com> <4D4AD0B7.4090809@redhat.com> <4D4AD481.1020603@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , Joerg Roedel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19688 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753786Ab1BCQVf (ORCPT ); Thu, 3 Feb 2011 11:21:35 -0500 In-Reply-To: <4D4AD481.1020603@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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