From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4Qch-0005f6-LA for qemu-devel@nongnu.org; Fri, 06 Apr 2018 08:37:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4Qce-0005Dy-Ix for qemu-devel@nongnu.org; Fri, 06 Apr 2018 08:37:43 -0400 Date: Fri, 6 Apr 2018 13:37:27 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Message-ID: <20180406123727.GD19949@redhat.com> Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <4d76348b-e1de-7d92-3434-5213d092c6d0@redhat.com> <0b957a5c-1a87-7952-292d-f65052bb6c5a@linux.vnet.ibm.com> <20180403113619.54ff1e18.cohuck@redhat.com> <20180406104024.51e9e826.cohuck@redhat.com> <0244b89c-e8c4-72a1-9b25-d69341ec721d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Halil Pasic Cc: David Hildenbrand , Cornelia Huck , mjrosato@linux.vnet.ibm.com, peter.maydell@linaro.org, Tony Krowiak , eskultet@redhat.com, qemu-s390x@nongnu.org, heiko.carstens@de.ibm.com, alifm@linux.vnet.ibm.com, Pierre Morel , qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, alex.williamson@redhat.com, jjherne@linux.vnet.ibm.com, schwidefsky@de.ibm.com, pbonzini@redhat.com, bjsdjshi@linux.vnet.ibm.com, eric.auger@redhat.com, rth@twiddle.net On Fri, Apr 06, 2018 at 02:32:49PM +0200, Halil Pasic wrote: > > > On 04/06/2018 02:09 PM, Halil Pasic wrote: > > Yes it is conceptually ugly. I'm 100% with you. That's why it should go > > away soon. From the practicality perspective however I would even argue that it's > > helpful to the user: tells 'oops you have forgotten something'. IMHO > > it's a shortcut of type make the problem smaller. Regarding what is > > harder and what is easier: the author is probably the most fit to decide > > that. If it is harder, it makes no sense, as this is all about cutting > > corners. > > I've just realized, I have overlooked something. And that is using > what libvirt calls host-model and host-passthrough mode. There the > user does not explicitly ask for ap=on. So the user would get slapped > in the face by this 'needs vfio-ap device' message (AFAIU) after > upgrading stuff (without even knowing that AP was added) which is > extremely ugly! I need to think about this some more. Typically in this kind of scenario, enablement of the new feature is tied to QEMU machine type. IOW, existing machine types should not get the new feature, only the very latest machine type. That way existing guests are not exposed to it when upgrading QEMU, unless they also change their machine type. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|