From: David Hildenbrand <david@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>,
Alexander Graf <agraf@suse.de>,
Yi Min Zhao <zyimin@linux.vnet.ibm.com>,
Halil Pasic <pasic@linux.vnet.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Jason J . Herne" <jjherne@linux.vnet.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH/RFC 3/3] s390x/ais: disable ais for compat machines
Date: Tue, 26 Sep 2017 15:00:09 +0200 [thread overview]
Message-ID: <49e66ee4-2df2-c310-93a7-e4ec91217c32@redhat.com> (raw)
In-Reply-To: <fc891aa4-d6f1-7348-3de7-cfa06ffa20c8@de.ibm.com>
On 26.09.2017 14:45, Christian Borntraeger wrote:
>
>
> On 09/26/2017 02:26 PM, David Hildenbrand wrote:
>> On 22.09.2017 10:38, Christian Borntraeger wrote:
>>> With newer kernels that do support the ais feature (4.13) a qemu 2.11
>>> will not only enable the ais feature for the 2.11 machine, but also
>>> for a <=2.10 compat machine. As this feature is not available in
>>> QEMU <=2.9 (and QEMU 2.10.1), this guest will fail to migrate
>>> back to an older qemu like 2.9 with:
>>>
>>> _snip_
>>> error while loading state for instance 0x0 of device 's390-flic'
>>> _snip_
>>>
>>> making the whole compat machine dis-functional. As a permanent fix, we
>>> need to fence the ais feature for machines <= 2.10
>>>
>>> Due to ais being enabled on 2.10.0 (fixed in 2.10.1) this will prevent
>>> migration of ais-enabled guests from 2.10.0 with
>>>
>>> _snip_
>>> qemu-system-s390x: Failed to load s390-flic/ais:tmp
>>> qemu-system-s390x: error while loading state for instance 0x0 of device 's390-flic'
>>> qemu-system-s390x: load of migration failed: Function not implemented
>>> _snip_
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
>>> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>> ---
>>> hw/intc/s390_flic_kvm.c | 4 +++-
>>> hw/s390x/s390-virtio-ccw.c | 10 ++++++++++
>>> include/hw/s390x/s390-virtio-ccw.h | 3 +++
>>> 3 files changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/intc/s390_flic_kvm.c b/hw/intc/s390_flic_kvm.c
>>> index a655567..2a94bfc 100644
>>> --- a/hw/intc/s390_flic_kvm.c
>>> +++ b/hw/intc/s390_flic_kvm.c
>>> @@ -22,6 +22,7 @@
>>> #include "hw/s390x/s390_flic.h"
>>> #include "hw/s390x/adapter.h"
>>> #include "hw/s390x/css.h"
>>> +#include "hw/s390x/s390-virtio-ccw.h"
>>> #include "trace.h"
>>>
>>> #define FLIC_SAVE_INITIAL_SIZE getpagesize()
>>> @@ -559,7 +560,8 @@ static void kvm_s390_flic_realize(DeviceState *dev, Error **errp)
>>> KVM_HAS_DEVICE_ATTR, test_attr);
>>> /* try enable the AIS facility */
>>> test_attr.group = KVM_DEV_FLIC_AISM_ALL;
>>> - if (!ioctl(flic_state->fd, KVM_HAS_DEVICE_ATTR, test_attr)) {
>>> + if (ais_allowed() &&
>>> + !ioctl(flic_state->fd, KVM_HAS_DEVICE_ATTR, test_attr)) {
>>> kvm_vm_enable_cap(kvm_state, KVM_CAP_S390_AIS, 0);
>>> }
>>>
>>
>> Wondering if this is really necessary. Shouldn't the CPU model feature
>> make sure that migration works?
>
> older QEMUs complain like when migrating a 2.9 machine to 2.9
>
> qemu-system-s390x: Failed to load s390-flic/ais:tmp
> qemu-system-s390x: error while loading state for instance 0x0 of device 's390-flic'
> qemu-system-s390x: load of migration failed: Function not implemented
>
> e.g. when using the host model.
>
Wonder when we can finally let go of these hacks. The host cpu model is
not migration safe, therefore such things are expected to not work. Just
think about trying to migrate from a kernel without AIS support to a
kernel with AIS support. It is broken.
AIS is just one feature that actually tells you that you are currently
doing something evil. Other CPU features you lose on the way simply
don't result in an error, but still migration could break silently
afterwards, when the guest assumes it has certain CPU features.
The main problem is that we have machines <= 2.7 that had no CPU model
support. For these machines, migration should work just fine, as
s390_has_feat(S390_FEAT_ADAPTER_INT_SUPPRESSION)
will always return false.
However, the guest will be presented the AIS bit, as soon as the
capability is enabled (as we then don't manually set the stfle bitmap
from QEMU), which is bad.
So my point would be: don't turn on these new facilities if the cpu
model is not allowed (<=2.7), but don't add ais_allowed() compat
handling for any newer machines. If they use the host model, they have
to assume that migration can break.
I think using cpu_model_allowed() would be just fine to be used instead
of ais_allowed().
--
Thanks,
David
next prev parent reply other threads:[~2017-09-26 13:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 8:38 [Qemu-devel] [PATCH/RFC 0/3] ais fixups for 2.11 Christian Borntraeger
2017-09-22 8:38 ` [Qemu-devel] [PATCH/RFC 1/3] s390x/ais: disable ais facility as it is broken Christian Borntraeger
2017-09-26 12:01 ` David Hildenbrand
2017-09-22 8:38 ` [Qemu-devel] [PATCH/RFC 2/3] s390x/ais: enable ais when migration is available Christian Borntraeger
2017-09-22 12:13 ` Pierre Morel
2017-09-22 12:40 ` Christian Borntraeger
2017-09-22 13:49 ` Cornelia Huck
2017-09-22 14:02 ` Pierre Morel
2017-09-22 14:07 ` Christian Borntraeger
2017-09-22 14:27 ` Halil Pasic
2017-09-25 10:07 ` Cornelia Huck
2017-09-25 10:12 ` Christian Borntraeger
2017-09-25 11:45 ` Cornelia Huck
2017-09-25 11:47 ` Christian Borntraeger
2017-09-26 9:14 ` Yi Min Zhao
2017-09-26 13:04 ` Boris Fiuczynski
2017-09-22 14:38 ` Pierre Morel
2017-09-26 12:23 ` David Hildenbrand
2017-09-26 12:29 ` Christian Borntraeger
2017-09-26 12:33 ` David Hildenbrand
2017-09-26 12:33 ` Christian Borntraeger
2017-09-22 8:38 ` [Qemu-devel] [PATCH/RFC 3/3] s390x/ais: disable ais for compat machines Christian Borntraeger
2017-09-26 12:26 ` David Hildenbrand
2017-09-26 12:45 ` Christian Borntraeger
2017-09-26 13:00 ` David Hildenbrand [this message]
2017-09-26 13:32 ` Christian Borntraeger
2017-09-26 13:43 ` Cornelia Huck
2017-09-26 13:45 ` Christian Borntraeger
2017-09-22 11:27 ` [Qemu-devel] [PATCH/RFC 0/3] ais fixups for 2.11 Christian Borntraeger
2017-09-22 13:08 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49e66ee4-2df2-c310-93a7-e4ec91217c32@redhat.com \
--to=david@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=zyimin@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).