From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyk0b-00079W-Fe for qemu-devel@nongnu.org; Wed, 21 Mar 2018 16:06:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyk0Y-0006LZ-BP for qemu-devel@nongnu.org; Wed, 21 Mar 2018 16:06:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43536) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eyk0Y-0006L6-4Z for qemu-devel@nongnu.org; Wed, 21 Mar 2018 16:06:50 -0400 Date: Wed, 21 Mar 2018 17:06:46 -0300 From: Eduardo Habkost Message-ID: <20180321200646.GD3417@localhost.localdomain> References: <20180320173500.32065-1-vkuznets@redhat.com> <20180320173500.32065-3-vkuznets@redhat.com> <46c08ea1-27f7-e581-f93f-cf635950062f@redhat.com> <87605p768t.fsf@vitty.brq.redhat.com> <20180321171755.GJ14983@rkaganb.sw.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180321171755.GJ14983@rkaganb.sw.ru> Subject: Re: [Qemu-devel] [PATCH v3 2/2] i386/kvm: lower requirements for Hyper-V frequency MSRs exposure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Kagan , Vitaly Kuznetsov , Paolo Bonzini , Richard Henderson , Marcelo Tosatti , qemu-devel@nongnu.org On Wed, Mar 21, 2018 at 08:17:55PM +0300, Roman Kagan wrote: > On Wed, Mar 21, 2018 at 05:17:38PM +0100, Vitaly Kuznetsov wrote: > > (What I'm worried about with all our hv_* knobs is that more of them we > > have easier it is to assemble some frankenstien which won't look like > > any existing Hyper-V version; we're probably not doing a very good job > > tesing all possible hv_* combinations as people probably use 'all or > > nothing'. In case we end up finding a bug in Windows with some weird > > hv_* combination it's unlikely Microsoft will bother fixing at as it > > doesn't reproduce on any existent Hyper-V version. > > I agree that this is getting cumbersome, but, given that features get > added incrementally and we need to be able to maintain backwards > compatibility, I'm afraid this is unavoidable. > > > That said, it would be great to eventually have something like > > 'hv_ws2012r2' property making us look exactly the same real WS2012R2 > > looks like. Unfortunatelly, I'm unsure about a path to get there). > > I'm tempted to delegate this -- combining features into user-friendly > sets -- to the upper layers: libvirt or even something on top of it. Sounds simpler to me, otherwise we would need a mechanism to tell the upper layers which of those named are usable on the current host. -- Eduardo