From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] KVM: VMX: Initialize vm86 TSS only once. Date: Sun, 27 Feb 2011 18:18:25 +0200 Message-ID: <4D6A7951.2040701@redhat.com> References: <1298282879-23075-1-git-send-email-gleb@redhat.com> <1298282879-23075-2-git-send-email-gleb@redhat.com> <4D6A710B.7070705@redhat.com> <20110227155219.GA22252@redhat.com> <4D6A74BE.6020303@redhat.com> <20110227161239.GB22252@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58311 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186Ab1B0QS3 (ORCPT ); Sun, 27 Feb 2011 11:18:29 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1RGIT2U002004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 27 Feb 2011 11:18:29 -0500 In-Reply-To: <20110227161239.GB22252@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/27/2011 06:12 PM, Gleb Natapov wrote: > On Sun, Feb 27, 2011 at 05:58:54PM +0200, Avi Kivity wrote: > > On 02/27/2011 05:52 PM, Gleb Natapov wrote: > > >> > > >> According to my reading of the code, if KVM_SET_TSS_ADDR is not > > >> invoked, the guest would fail both before and after the patch, yes? > > >> > > >Hmmm. Actually no. Before the patch guest that doesn't use KVM_SET_TSS_ADDR > > >will use the top of slot zero. Should I fix that (how?), or should we > > >drop support for those old guests? > > > > I don't think we have a problem with older qemus, but perhaps we do > > with non-qemu users. The API clearly requires the ioctl to be > > called, but I don't think we can blame anyone for forgetting to do > > so, especially if it worked silently. > > > It may have worked as in "no error returned from KVM_RUN", but if > userspace does not call to KVM_SET_TSS_ADDR kvm silently uses part of > a guest memory to store its data which may cause guest to fail long after > it was started. It is true that for that to happen guest needs to enter > protected mode during its lifetime and not many guests do that usually. > The only cases I can think of are during some guests installation and > S3 suspend/resume. Right. I prefer to keep this partially working state if users didn't have a problem with it. > > >The problem with using top of slot > > >zero is that this memory is available for guest use and we do not even > > >put it into e820 map as far as I see. Also there are patches floating > > >around that re-arrange memslots or even put them in a tree. They will > > >break old guests too. > > > > Well, slot 0 still exists even if it is moved somewhere else. > > > > Something we can do is put the tss slot just below the highest slot > > that is still below 4G, and hope there is no mmio there. Once the > > user issues KVM_SET_TSS_ADDR, use that. We'll have to keep juggling > > that slot as the user creates more slots, icky. > > > I have a question about our current placement of tss addr. Qemu-kvm > places it at 4G-16M and comment says that this is just below BIOS ROM, > but BIOS ROM takes only upper 128K. Are you surprised that a comment is inaccurate? Likely it was moved to make room for larger bioses. -- error compiling committee.c: too many arguments to function