From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYhxr-0004ja-2Q for qemu-devel@nongnu.org; Thu, 19 Mar 2015 17:26:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYhxj-0002b0-6S for qemu-devel@nongnu.org; Thu, 19 Mar 2015 17:26:51 -0400 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:37468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYhxj-0002ar-0A for qemu-devel@nongnu.org; Thu, 19 Mar 2015 17:26:43 -0400 Received: by wixw10 with SMTP id w10so1935956wix.0 for ; Thu, 19 Mar 2015 14:26:42 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <550B3F0C.7040306@redhat.com> Date: Thu, 19 Mar 2015 22:26:36 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20150318150358-mutt-send-email-mst@redhat.com> <1426688101.3643.367.camel@redhat.com> <20150318153207-mutt-send-email-mst@redhat.com> <1426690254.3643.375.camel@redhat.com> <20150318155731-mutt-send-email-mst@redhat.com> <1426693529.3643.382.camel@redhat.com> <20150318173752-mutt-send-email-mst@redhat.com> <1426698688.3643.397.camel@redhat.com> <20150318183916-mutt-send-email-mst@redhat.com> <1426702095.3643.414.camel@redhat.com> <20150318195506-mutt-send-email-mst@redhat.com> <1426705538.3643.425.camel@redhat.com> In-Reply-To: <1426705538.3643.425.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v5 7/7] pc: add PC_I440FX_COMPAT to disable aercap for vifo device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , "Michael S. Tsirkin" Cc: Chen Fan , izumi.taku@jp.fujitsu.com, qemu-devel@nongnu.org On 18/03/2015 20:05, Alex Williamson wrote: > > OK, so maybe it's a feature that users should have control over. > > But tying it to machine types makes no sense. > > If we were to change the default, where else would you tie it? Machine > types are the only finger hold we have to maintain VM stability afaik. I agree. Machine type are there to avoid exposing "important" changes in the behavior of the device model to the guest. These include the number and size of capabilities and BARs (and other fields in configuration space), the number of virtqueues and how they are used (virtio features), etc. Migration is definitely the main reason to introduce a new property and add compatibility glue for older machine types, but it does not have to be the only one. AER seems to me like it is a significant-enough change in how the guest sees an assigned device. You certainly don't want it to appear in a configuration that was previously stable. So, migration could be a reason why we _have_ to introduce compatibility glue, but AER to me is a perfect example of why we may sometimes _want_ to have compatibility glue. It's different, but it makes a lot of sense. The maintenance cost of the compatibility glue is small. Hiding the capability is half a dozen lines of code, and the behavior is no different than when the guest doesn't want to see errors (which has to be supported, if only because not all chipsets are PCIe). Paolo