From: David Hildenbrand <david@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Marc Hartmayer <mhartmay@linux.vnet.ibm.com>,
libvir-list@redhat.com, qemu-devel@nongnu.org
Cc: Jiri Denemark <jdenemar@redhat.com>,
Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>,
"Jason J. Herne" <jjherne@linux.vnet.ibm.com>,
Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode
Date: Fri, 20 Oct 2017 16:06:51 +0200 [thread overview]
Message-ID: <2812651d-6d15-347c-5f1d-40fb0e35f66a@redhat.com> (raw)
In-Reply-To: <90dcd7c4-0a89-df06-90e3-0d8253871395@de.ibm.com>
On 20.10.2017 16:02, Christian Borntraeger wrote:
>
>
> On 10/20/2017 03:51 PM, David Hildenbrand wrote:
> [...]
>>> The problem goes much further.
>>> A fresh guest with
>>>
>>> <os>
>>> <type arch='s390x' machine='s390-ccw-virtio-2.9'>hvm</type>
>>> </os>
>>> <cpu mode='host-model'/>
>>>
>>> does not start. No migration from an older system is necessary.
>>>
>>
>> Yes, as stated in the documentation "copying host CPU definition from
>> capabilities XML" this can not work. And it works just as documented.
>> Not saying this is a nice thing :)
>>
>> I think we should try to fix gs_allowed (if possible) and avoid
>> something like that in the future. This would avoid other complexity
>> involved when suddenly having X host models.
>
> Maybe this one is really a proper fix. It will allow the guest to start
> and on migration the cpu model will complain if the target cannot provide gs.
> Similar things can happen if - for example - the host kernel lacks some features.
Right, just what I had in mind.
>
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 77169bb..97a08fa 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -430,7 +430,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;
> @@ -509,12 +508,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);
> @@ -757,7 +750,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..1de53b0 100644
> --- a/include/hw/s390x/s390-virtio-ccw.h
> +++ b/include/hw/s390x/s390-virtio-ccw.h
> @@ -40,7 +40,6 @@ typedef struct S390CcwMachineClass {
> bool ri_allowed;
> bool cpu_model_allowed;
> bool css_migration_enabled;
> - bool gs_allowed;
> } S390CcwMachineClass;
>
> /* runtime-instrumentation allowed by the machine */
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index a0d5052..3f13fc2 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -362,7 +362,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;
> }
>
And the last hunk makes sure we keep same handling for machines without
CPU model support and therefore no way to mask support. For all recent
machines, we expect CPU model checks to be in place.
Will have to think about this a bit more. Will you send this as a proper
patch?
--
Thanks,
David
next prev parent reply other threads:[~2017-10-20 14:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87y3oqugm7.fsf@marc-ibm.boeblingen.de.ibm.com>
[not found] ` <20171005121115.GD3946746@orkuz.home>
[not found] ` <87y3ok7n2n.fsf@marc-ibm.boeblingen.de.ibm.com>
[not found] ` <20171012120714.GA314661@orkuz.home>
2017-10-20 11:09 ` [Qemu-devel] [libvirt] Question about the host-model CPU mode Marc Hartmayer
2017-10-20 11:37 ` David Hildenbrand
2017-10-20 12:50 ` Jiri Denemark
2017-10-20 13:04 ` David Hildenbrand
2017-10-23 7:25 ` Jiri Denemark
2017-10-20 12:43 ` Jiri Denemark
2017-10-20 13:16 ` David Hildenbrand
2017-10-20 13:36 ` Christian Borntraeger
2017-10-20 13:43 ` David Hildenbrand
2017-10-20 13:49 ` Christian Borntraeger
2017-10-20 13:51 ` David Hildenbrand
2017-10-20 14:02 ` Christian Borntraeger
2017-10-20 14:06 ` David Hildenbrand [this message]
2017-10-20 14:12 ` Christian Borntraeger
2017-10-20 14:58 ` Halil Pasic
2017-10-20 15:14 ` David Hildenbrand
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=2812651d-6d15-347c-5f1d-40fb0e35f66a@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=fiuczy@linux.vnet.ibm.com \
--cc=jdenemar@redhat.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=libvir-list@redhat.com \
--cc=mhartmay@linux.vnet.ibm.com \
--cc=mihajlov@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/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).