Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On Thu, Oct 26, 2017 at 10:09:46 +0200, David Hildenbrand wrote: > On 25.10.2017 18:45, Marc Hartmayer wrote: > > On Wed, Oct 25, 2017 at 05:50 PM +0200, David Hildenbrand > > wrote: > >> On 25.10.2017 17:09, Boris Fiuczynski wrote: > >>> David, I disagree if your proposal is to generally tolerate new cpu > >>> features in old machine types. This *might* work for gs but how do you > >>> guaranty that guests do not behave differently/wrong when suddenly new > >>> cpu features are made available to guest when (re-)starting them. > >>> That is my feedback for the qemu side of this mater. > >> > >> Just re-reading this section, so what you mean is: > >> > >> a) guest is started, host model is copied and used. guest works. > >> b) guest is stopped. > >> c) QEMU/KVM/HW is updated. > >> d) guest is started, new host model is copied. guest no longer works. > >> > >> d) could be because there are now some additional features with e.g. > >> broken guest implementation or now missing features. > >> > >> > >> What you propose (if I am not wrong) is a to bind features somehow to a > >> QEMU machine. I think that should never be done. You could not catch now > >> missing features. > > > > What exactly do you mean by the last sentence? > > In general, up/downgrading QEMU/KVM/HW can lead to the removal of features. > > Another example is the "nested" flag for KVM. toggling that can lead to > the host feature looking differently (+/- SIE features). > > So if you really want to make sure that a VM XML that once ran perfectly > fine on a host will still run after any QEMU/KVM/HW changes on that host: > > a) specify an explicit CPU model, not the host model (e.g. "z13") > b) copy the host model to the XML persistently. > > Linking any of that to the machine types is in my opinion the very wrong > approach. I agree, we should do that only if it's really impossible to even create a machine with a given machine type in combination with some CPU models. And I believe this is not the case. The host-model CPU guarantees guest ABI only while a domain is running. Once it stops and a user starts it again, the ABI seen by the guest OS may be different and this may sometimes cause the guest OS won't start. It's pretty similar to what can happen when you change the machine type. Of course, machine type doesn't change automatically while host-model CPUs do change. But that's just how host-model is defined. If you don't want this to happen, you should use a specific CPU model; you can copy it from domain capabilities XML to make a persistent version of a host-model CPU. BTW, using host-model CPU may actually break migration to host with older QEMU even though an old machine type is used. This is OK since host-model may bring features which are not supported on the older host and backward migration is only supported when no new features are used. However, if a domain with a host-model CPU was started on the old host and migrated to the new one, migrating it back to the old one is supported and it will work. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On Fri, 20 Oct 2017 16:54:37 +0200 Christian Borntraeger wrote: > Starting a guest with > > hvm > > > > on an IBM z14 results in > > "qemu-system-s390x: Some features requested in the CPU model are not > available in the configuration: gs" > > This is because guarded storage is fenced for compat machines that did not > have > guarded storage support, but libvirt expands the cpu model according to the > latest available machine. > > While this prevents future migration abort (by not starting the guest at all), > not being able to start a "host-model" guest is very much unexpected. As it > turns out, even if we would modify libvirt to not expand the cpu model to > contain "gs" for compat machines, it cannot guarantee that a migration will > succeed. For example if the kernel changes its features (or the user has > nested=1 on one host but not on the other) the migration will fail > nevertheless. So instead of fencing "gs" for machines <= 2.9 lets allow it > for > all machine types that support the CPU model. This will make "host-model" > runnable all the time, while relying on the CPU model to reject invalid > migration attempts. > > Suggested-by: David Hildenbrand > Signed-off-by: Christian Borntraeger > --- > hw/s390x/s390-virtio-ccw.c | 8 > include/hw/s390x/s390-virtio-ccw.h | 3 --- > target/s390x/kvm.c | 2 +- > 3 files changed, 1 insertion(+), 12 deletions(-) Acked-by: Cornelia Huck -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On 25.10.2017 18:45, Marc Hartmayer wrote: > On Wed, Oct 25, 2017 at 05:50 PM +0200, David Hildenbrand > wrote: >> On 25.10.2017 17:09, Boris Fiuczynski wrote: >>> On 10/25/2017 12:23 PM, David Hildenbrand wrote: On 25.10.2017 12:18, Christian Borntraeger wrote: > Ping, I plan to submit belows patch for 2.11. We can then still look into > a libvirt<->qemu interface for limiting host-model depending on machine > versions > (or not). I think this would be sufficient for now. Having different host models, depending on the the machine type sounds wrong. But maybe we'll need it in the future. >>> >>> David, I disagree if your proposal is to generally tolerate new cpu >>> features in old machine types. This *might* work for gs but how do you >>> guaranty that guests do not behave differently/wrong when suddenly new >>> cpu features are made available to guest when (re-)starting them. >>> That is my feedback for the qemu side of this mater. >> >> Just re-reading this section, so what you mean is: >> >> a) guest is started, host model is copied and used. guest works. >> b) guest is stopped. >> c) QEMU/KVM/HW is updated. >> d) guest is started, new host model is copied. guest no longer works. >> >> d) could be because there are now some additional features with e.g. >> broken guest implementation or now missing features. >> >> >> What you propose (if I am not wrong) is a to bind features somehow to a >> QEMU machine. I think that should never be done. You could not catch now >> missing features. > > What exactly do you mean by the last sentence? In general, up/downgrading QEMU/KVM/HW can lead to the removal of features. Another example is the "nested" flag for KVM. toggling that can lead to the host feature looking differently (+/- SIE features). So if you really want to make sure that a VM XML that once ran perfectly fine on a host will still run after any QEMU/KVM/HW changes on that host: a) specify an explicit CPU model, not the host model (e.g. "z13") b) copy the host model to the XML persistently. Linking any of that to the machine types is in my opinion the very wrong approach. > >> >> What would you think about a persistent host-model copy option? So >> instead of copying at every start, only copy and replace it once in the XML? >> >> Easy to specify by the user and no CPU feature changes will happend >> "blindly". >> >> >> -- >> >> Thanks, >> >> David >> > -- > Beste Grüße / Kind regards >Marc Hartmayer > > IBM Deutschland Research & Development GmbH > Vorsitzende des Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 > -- Thanks, David -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On Wed, Oct 25, 2017 at 05:50 PM +0200, David Hildenbrand wrote: > On 25.10.2017 17:09, Boris Fiuczynski wrote: >> On 10/25/2017 12:23 PM, David Hildenbrand wrote: >>> On 25.10.2017 12:18, Christian Borntraeger wrote: Ping, I plan to submit belows patch for 2.11. We can then still look into a libvirt<->qemu interface for limiting host-model depending on machine versions (or not). >>> >>> I think this would be sufficient for now. >>> >>> Having different host models, depending on the the machine type sounds >>> wrong. But maybe we'll need it in the future. >>> >> >> David, I disagree if your proposal is to generally tolerate new cpu >> features in old machine types. This *might* work for gs but how do you >> guaranty that guests do not behave differently/wrong when suddenly new >> cpu features are made available to guest when (re-)starting them. >> That is my feedback for the qemu side of this mater. > > Just re-reading this section, so what you mean is: > > a) guest is started, host model is copied and used. guest works. > b) guest is stopped. > c) QEMU/KVM/HW is updated. > d) guest is started, new host model is copied. guest no longer works. > > d) could be because there are now some additional features with e.g. > broken guest implementation or now missing features. > > > What you propose (if I am not wrong) is a to bind features somehow to a > QEMU machine. I think that should never be done. You could not catch now > missing features. What exactly do you mean by the last sentence? > > What would you think about a persistent host-model copy option? So > instead of copying at every start, only copy and replace it once in the XML? > > Easy to specify by the user and no CPU feature changes will happend > "blindly". > > > -- > > Thanks, > > David > -- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On 25.10.2017 17:09, Boris Fiuczynski wrote: > On 10/25/2017 12:23 PM, David Hildenbrand wrote: >> On 25.10.2017 12:18, Christian Borntraeger wrote: >>> Ping, I plan to submit belows patch for 2.11. We can then still look into >>> a libvirt<->qemu interface for limiting host-model depending on machine >>> versions >>> (or not). >> >> I think this would be sufficient for now. >> >> Having different host models, depending on the the machine type sounds >> wrong. But maybe we'll need it in the future. >> > > David, I disagree if your proposal is to generally tolerate new cpu > features in old machine types. This *might* work for gs but how do you > guaranty that guests do not behave differently/wrong when suddenly new > cpu features are made available to guest when (re-)starting them. > That is my feedback for the qemu side of this mater. Just re-reading this section, so what you mean is: a) guest is started, host model is copied and used. guest works. b) guest is stopped. c) QEMU/KVM/HW is updated. d) guest is started, new host model is copied. guest no longer works. d) could be because there are now some additional features with e.g. broken guest implementation or now missing features. What you propose (if I am not wrong) is a to bind features somehow to a QEMU machine. I think that should never be done. You could not catch now missing features. What would you think about a persistent host-model copy option? So instead of copying at every start, only copy and replace it once in the XML? Easy to specify by the user and no CPU feature changes will happend "blindly". -- Thanks, David -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On 25.10.2017 17:09, Boris Fiuczynski wrote: > On 10/25/2017 12:23 PM, David Hildenbrand wrote: >> On 25.10.2017 12:18, Christian Borntraeger wrote: >>> Ping, I plan to submit belows patch for 2.11. We can then still look into >>> a libvirt<->qemu interface for limiting host-model depending on machine >>> versions >>> (or not). >> >> I think this would be sufficient for now. >> >> Having different host models, depending on the the machine type sounds >> wrong. But maybe we'll need it in the future. >> > > David, I disagree if your proposal is to generally tolerate new cpu > features in old machine types. This *might* work for gs but how do you > guaranty that guests do not behave differently/wrong when suddenly new > cpu features are made available to guest when (re-)starting them. > That is my feedback for the qemu side of this mater. My point would be that it seems to work for all existing architectures (so far as I am aware) and this one problem is easily fixed (and stems from old CPU feature compatibility handling). So my question would be, are there any potential CPU features that make such handling necessary right now or in the near future? > > Regarding the libvirt side of this: > When looking at https://libvirt.org/formatdomain.html#elementsCPU I > found the following sentence: > Since the CPU definition is copied just before starting a domain, > exactly the same XML can be used on different hosts while still > providing the best guest CPU each host supports. > > My interpretation of "the best guest CPU each host supports" is that > besides limiting factors like hardware, kernel and qemu capabilities the > requested machine type for the guest is a limiting factor as well. I understand "what the host supports" as combination of hw+kernel+qemu. But the definition can be interpreted differently. I don't think that the requested machine has to be taken into account at this point. (Again, do you have any real examples where this would be applicable?) > > Nevertheless if my interpretation is found to be incorrect than we > should think about another new cpu mode that includes the machine type > into the "best guest CPU" detection. Which use case? I just want to understand how the current solution could be problematic? (besides the problem we had, which is easily fixed) > My assumption is that we must not require the users to know which cpu > model they manually need to define to match a specific machine type > AND we want to guarantee that guests run without risking any side > effects by tolerating any additional cpu features. That's why I think CPU models should be independent of the used QEMU machine. It just over complicates things as we have seen. Especially suddenly having multiple "host" CPU models depending on the machine type, confusing. If we can, we should keep it simple. -- Thanks, David -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On 10/25/2017 12:23 PM, David Hildenbrand wrote: On 25.10.2017 12:18, Christian Borntraeger wrote: Ping, I plan to submit belows patch for 2.11. We can then still look into a libvirt<->qemu interface for limiting host-model depending on machine versions (or not). I think this would be sufficient for now. Having different host models, depending on the the machine type sounds wrong. But maybe we'll need it in the future. David, I disagree if your proposal is to generally tolerate new cpu features in old machine types. This *might* work for gs but how do you guaranty that guests do not behave differently/wrong when suddenly new cpu features are made available to guest when (re-)starting them. That is my feedback for the qemu side of this mater. Regarding the libvirt side of this: When looking at https://libvirt.org/formatdomain.html#elementsCPU I found the following sentence: Since the CPU definition is copied just before starting a domain, exactly the same XML can be used on different hosts while still providing the best guest CPU each host supports. My interpretation of "the best guest CPU each host supports" is that besides limiting factors like hardware, kernel and qemu capabilities the requested machine type for the guest is a limiting factor as well. Nevertheless if my interpretation is found to be incorrect than we should think about another new cpu mode that includes the machine type into the "best guest CPU" detection. My assumption is that we must not require the users to know which cpu model they manually need to define to match a specific machine type AND we want to guarantee that guests run without risking any side effects by tolerating any additional cpu features. -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
On 25.10.2017 12:18, Christian Borntraeger wrote: > Ping, I plan to submit belows patch for 2.11. We can then still look into > a libvirt<->qemu interface for limiting host-model depending on machine > versions > (or not). I think this would be sufficient for now. Having different host models, depending on the the machine type sounds wrong. But maybe we'll need it in the future. -- Thanks, David -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
Ping, I plan to submit belows patch for 2.11. We can then still look into
a libvirt<->qemu interface for limiting host-model depending on machine versions
(or not).
On 10/20/2017 04:54 PM, Christian Borntraeger wrote:
> Starting a guest with
>
> hvm
>
>
>
> on an IBM z14 results in
>
> "qemu-system-s390x: Some features requested in the CPU model are not
> available in the configuration: gs"
>
> This is because guarded storage is fenced for compat machines that did not
> have
> guarded storage support, but libvirt expands the cpu model according to the
> latest available machine.
>
> While this prevents future migration abort (by not starting the guest at all),
> not being able to start a "host-model" guest is very much unexpected. As it
> turns out, even if we would modify libvirt to not expand the cpu model to
> contain "gs" for compat machines, it cannot guarantee that a migration will
> succeed. For example if the kernel changes its features (or the user has
> nested=1 on one host but not on the other) the migration will fail
> nevertheless. So instead of fencing "gs" for machines <= 2.9 lets allow it
> for
> all machine types that support the CPU model. This will make "host-model"
> runnable all the time, while relying on the CPU model to reject invalid
> migration attempts.
>
> Suggested-by: David Hildenbrand
> Signed-off-by: Christian Borntraeger
> ---
> hw/s390x/s390-virtio-ccw.c | 8
> include/hw/s390x/s390-virtio-ccw.h | 3 ---
> target/s390x/kvm.c | 2 +-
> 3 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index fabe4a6..ae5b01a 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -414,7 +414,6 @@ static void ccw_machine_class_init(ObjectClass *oc, void
> *data)
> s390mc->ri_allowed = true;
> s390mc->cpu_model_allowed = true;
> s390mc->css_migration_enabled = true;
> -s390mc->gs_allowed = true;
> mc->init = ccw_init;
> mc->reset = s390_machine_reset;
> mc->hot_add_cpu = s390_hot_add_cpu;
> @@ -495,12 +494,6 @@ bool cpu_model_allowed(void)
> return get_machine_class()->cpu_model_allowed;
> }
>
> -bool gs_allowed(void)
> -{
> -/* for "none" machine this results in true */
> -return get_machine_class()->gs_allowed;
> -}
> -
> static char *machine_get_loadparm(Object *obj, Error **errp)
> {
> S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
> @@ -740,7 +733,6 @@ static void ccw_machine_2_9_class_options(MachineClass
> *mc)
> {
> S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
>
> -s390mc->gs_allowed = false;
> ccw_machine_2_10_class_options(mc);
> SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_9);
> s390mc->css_migration_enabled = false;
> diff --git a/include/hw/s390x/s390-virtio-ccw.h
> b/include/hw/s390x/s390-virtio-ccw.h
> index a9a90c2..ac896e3 100644
> --- a/include/hw/s390x/s390-virtio-ccw.h
> +++ b/include/hw/s390x/s390-virtio-ccw.h
> @@ -40,15 +40,12 @@ typedef struct S390CcwMachineClass {
> bool ri_allowed;
> bool cpu_model_allowed;
> bool css_migration_enabled;
> -bool gs_allowed;
> } S390CcwMachineClass;
>
> /* runtime-instrumentation allowed by the machine */
> bool ri_allowed(void);
> /* cpu model allowed by the machine */
> bool cpu_model_allowed(void);
> -/* guarded-storage allowed by the machine */
> -bool gs_allowed(void);
>
> /**
> * Returns true if (vmstate based) migration of the channel subsystem
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index 4c85ed8..020a7ea 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -363,7 +363,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> cap_ri = 1;
> }
> }
> -if (gs_allowed()) {
> +if (cpu_model_allowed()) {
> if (kvm_vm_enable_cap(s, KVM_CAP_S390_GS, 0) == 0) {
> cap_gs = 1;
> }
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
FWIW, this patch alone probably makes sense to fix this particular issue.
The question is do we want to have some additional interfaces between
libvirt/qemu
that tell libvirt what CPUs/features are allowed for a specific machine version?
Halil just brough up an example. Imagine to have a QEMU binary that can emulate
an x86 and an s390x depending on the machine type. Should libvirt be able to
detect
that -cpu pentium only makes sense for the q35 machines, but not for the
s390-ccw-virtio
ones?
On 10/20/2017 04:54 PM, Christian Borntraeger wrote:
> Starting a guest with
>
> hvm
>
>
>
> on an IBM z14 results in
>
> "qemu-system-s390x: Some features requested in the CPU model are not
> available in the configuration: gs"
>
> This is because guarded storage is fenced for compat machines that did not
> have
> guarded storage support, but libvirt expands the cpu model according to the
> latest available machine.
>
> While this prevents future migration abort (by not starting the guest at all),
> not being able to start a "host-model" guest is very much unexpected. As it
> turns out, even if we would modify libvirt to not expand the cpu model to
> contain "gs" for compat machines, it cannot guarantee that a migration will
> succeed. For example if the kernel changes its features (or the user has
> nested=1 on one host but not on the other) the migration will fail
> nevertheless. So instead of fencing "gs" for machines <= 2.9 lets allow it
> for
> all machine types that support the CPU model. This will make "host-model"
> runnable all the time, while relying on the CPU model to reject invalid
> migration attempts.
>
> Suggested-by: David Hildenbrand
> Signed-off-by: Christian Borntraeger
> ---
> hw/s390x/s390-virtio-ccw.c | 8
> include/hw/s390x/s390-virtio-ccw.h | 3 ---
> target/s390x/kvm.c | 2 +-
> 3 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index fabe4a6..ae5b01a 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -414,7 +414,6 @@ static void ccw_machine_class_init(ObjectClass *oc, void
> *data)
> s390mc->ri_allowed = true;
> s390mc->cpu_model_allowed = true;
> s390mc->css_migration_enabled = true;
> -s390mc->gs_allowed = true;
> mc->init = ccw_init;
> mc->reset = s390_machine_reset;
> mc->hot_add_cpu = s390_hot_add_cpu;
> @@ -495,12 +494,6 @@ bool cpu_model_allowed(void)
> return get_machine_class()->cpu_model_allowed;
> }
>
> -bool gs_allowed(void)
> -{
> -/* for "none" machine this results in true */
> -return get_machine_class()->gs_allowed;
> -}
> -
> static char *machine_get_loadparm(Object *obj, Error **errp)
> {
> S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
> @@ -740,7 +733,6 @@ static void ccw_machine_2_9_class_options(MachineClass
> *mc)
> {
> S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
>
> -s390mc->gs_allowed = false;
> ccw_machine_2_10_class_options(mc);
> SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_9);
> s390mc->css_migration_enabled = false;
> diff --git a/include/hw/s390x/s390-virtio-ccw.h
> b/include/hw/s390x/s390-virtio-ccw.h
> index a9a90c2..ac896e3 100644
> --- a/include/hw/s390x/s390-virtio-ccw.h
> +++ b/include/hw/s390x/s390-virtio-ccw.h
> @@ -40,15 +40,12 @@ typedef struct S390CcwMachineClass {
> bool ri_allowed;
> bool cpu_model_allowed;
> bool css_migration_enabled;
> -bool gs_allowed;
> } S390CcwMachineClass;
>
> /* runtime-instrumentation allowed by the machine */
> bool ri_allowed(void);
> /* cpu model allowed by the machine */
> bool cpu_model_allowed(void);
> -/* guarded-storage allowed by the machine */
> -bool gs_allowed(void);
>
> /**
> * Returns true if (vmstate based) migration of the channel subsystem
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index 4c85ed8..020a7ea 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -363,7 +363,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> cap_ri = 1;
> }
> }
> -if (gs_allowed()) {
> +if (cpu_model_allowed()) {
> if (kvm_vm_enable_cap(s, KVM_CAP_S390_GS, 0) == 0) {
> cap_gs = 1;
> }
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines
Starting a guest with
hvm
on an IBM z14 results in
"qemu-system-s390x: Some features requested in the CPU model are not
available in the configuration: gs"
This is because guarded storage is fenced for compat machines that did not have
guarded storage support, but libvirt expands the cpu model according to the
latest available machine.
While this prevents future migration abort (by not starting the guest at all),
not being able to start a "host-model" guest is very much unexpected. As it
turns out, even if we would modify libvirt to not expand the cpu model to
contain "gs" for compat machines, it cannot guarantee that a migration will
succeed. For example if the kernel changes its features (or the user has
nested=1 on one host but not on the other) the migration will fail
nevertheless. So instead of fencing "gs" for machines <= 2.9 lets allow it for
all machine types that support the CPU model. This will make "host-model"
runnable all the time, while relying on the CPU model to reject invalid
migration attempts.
Suggested-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-virtio-ccw.c | 8
include/hw/s390x/s390-virtio-ccw.h | 3 ---
target/s390x/kvm.c | 2 +-
3 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index fabe4a6..ae5b01a 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -414,7 +414,6 @@ static void ccw_machine_class_init(ObjectClass *oc, void
*data)
s390mc->ri_allowed = true;
s390mc->cpu_model_allowed = true;
s390mc->css_migration_enabled = true;
-s390mc->gs_allowed = true;
mc->init = ccw_init;
mc->reset = s390_machine_reset;
mc->hot_add_cpu = s390_hot_add_cpu;
@@ -495,12 +494,6 @@ bool cpu_model_allowed(void)
return get_machine_class()->cpu_model_allowed;
}
-bool gs_allowed(void)
-{
-/* for "none" machine this results in true */
-return get_machine_class()->gs_allowed;
-}
-
static char *machine_get_loadparm(Object *obj, Error **errp)
{
S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
@@ -740,7 +733,6 @@ static void ccw_machine_2_9_class_options(MachineClass *mc)
{
S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
-s390mc->gs_allowed = false;
ccw_machine_2_10_class_options(mc);
SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_9);
s390mc->css_migration_enabled = false;
diff --git a/include/hw/s390x/s390-virtio-ccw.h
b/include/hw/s390x/s390-virtio-ccw.h
index a9a90c2..ac896e3 100644
--- a/include/hw/s390x/s390-virtio-ccw.h
+++ b/include/hw/s390x/s390-virtio-ccw.h
@@ -40,15 +40,12 @@ typedef struct S390CcwMachineClass {
bool ri_allowed;
bool cpu_model_allowed;
bool css_migration_enabled;
-bool gs_allowed;
} S390CcwMachineClass;
/* runtime-instrumentation allowed by the machine */
bool ri_allowed(void);
/* cpu model allowed by the machine */
bool cpu_model_allowed(void);
-/* guarded-storage allowed by the machine */
-bool gs_allowed(void);
/**
* Returns true if (vmstate based) migration of the channel subsystem
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 4c85ed8..020a7ea 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -363,7 +363,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
cap_ri = 1;
}
}
-if (gs_allowed()) {
+if (cpu_model_allowed()) {
if (kvm_vm_enable_cap(s, KVM_CAP_S390_GS, 0) == 0) {
cap_gs = 1;
}
--
2.9.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
