qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instru


From: Daniel P . Berrangé
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception
Date: Fri, 6 Apr 2018 13:37:27 +0100
User-agent: Mutt/1.9.2 (2017-12-15)

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]