From mboxrd@z Thu Jan 1 00:00:00 1970 From: Izik Eidus Subject: Re: [PATCH] RFC: alias rework Date: Mon, 25 Jan 2010 22:40:32 +0200 Message-ID: <20100125224032.19bc6890@redhat.com> References: <20100125155344.327ba0d8@redhat.com> <20100125194553.GB20572@amt.cnet> <20100125215743.6442b1e4@redhat.com> <20100125202039.GB21800@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1646 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752702Ab0AYUkk (ORCPT ); Mon, 25 Jan 2010 15:40:40 -0500 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o0PKed0O029802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jan 2010 15:40:40 -0500 In-Reply-To: <20100125202039.GB21800@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 25 Jan 2010 18:20:39 -0200 Marcelo Tosatti wrote: > With current code, if a memslot is deleted, access through any aliases > that use it will fail (BTW it looks this is not properly handled, but > thats a separate problem). Yea I had some still open concerns about this code (this why I sent it on RFC) > > So AFAICS there is no requirement for an alias to continue "operable" > if its parent memslot is deleted. With this patch alias will stop to opearte when the parent is deleted just like the behivor with the current code... base_gfn will be set to 0 and npages will be set to 0 as well (the true values wil be hide in real_base_gfn...), so gfn_to_memslot and gfn_to_page will fail.... > > Or is this a feature you need? I dont need it (I asked Avi to do something), So he said he want to nuke the aliasing from kvm and keep supporting the old userspace`s Do you have any other way to achive this? Btw I do realize it might be better not to push this patch and just keep the old way of treating aliasing as we have now, I really don`t mind. > > Motivation is that nukeing aliases is simpler than adjusting them. > Agree.