From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 2/3] KVM: x86: Save&restore interrupt shadow mask Date: Wed, 17 Feb 2010 12:54:35 -0200 Message-ID: <20100217145435.GA15508@amt.cnet> References: <0bc4d8c46c0868cff70568bb5ee6df25162ddab6.1266227138.git.jan.kiszka@siemens.com> <20100217003941.GA1110@amt.cnet> <4B7BB0FE.4020607@siemens.com> <20100217091007.GM2995@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , Avi Kivity , kvm To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19753 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752721Ab0BQOyv (ORCPT ); Wed, 17 Feb 2010 09:54:51 -0500 Content-Disposition: inline In-Reply-To: <20100217091007.GM2995@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Feb 17, 2010 at 11:10:07AM +0200, Gleb Natapov wrote: > On Wed, Feb 17, 2010 at 10:03:58AM +0100, Jan Kiszka wrote: > > > > > > Also, as Avi mentioned it would be better to avoid this. Is it not > > > possible to disallow migration while interrupt shadow is present? > > > > Which means disallowing user space exists while the shadow it set? Or > > should we introduce some flag for user space that tells it "do not > > migration now, resume the guest till next exit"? > > > I think disabling migration is a slippery slope. Guest may abuse it. May > be it will be hard to do with interrupt shadow, but the mechanism will be > used for other cases too. I remember there was an argument that we > should not migrate while vcpu is in a nested guest mode. Agree that guest may abuse it. Better to save/restore blocking-by-sti/by-mov-ss individually. I was thinking the writeback of interrupt shadow / interruptibility state would be too complicated (eg necessary to care about ordering, etc), but now i see its handled in kernel (inject_pending_event and friends).