From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 20 of 20] n2 MSR handling and capability exposure Date: Thu, 02 Jun 2011 20:20:06 +0100 Message-ID: References: <20110602151128.GQ5098@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110602151128.GQ5098@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Eddie Dong Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 02/06/2011 16:11, "Tim Deegan" wrote: >> BTW, I don't really like defining all these REMOVED_* macros, each >> of which is used only once a few lines from the definition (here and >> elsewhere in the series). It just adds clutter for no benefit. >> > > Oh, I forgot to say: will this feature-blacklisting work over live > migration to a machine with a different CPU? There isn't an equivalnet > of the CPUID masking feature to make all the machines in a cluster seem > to have the same VMX features. > > Elsewhere we use whitelisting for passsing hardware capability flags to > HVM guests; I think we should use whitelists here too. Blacklists create a total mess of doom. We should absolutely disallow the creation of any new ones. I think HVM guests are currently clean in this regard and should stay that way. -- Keir