On 07/24/2018 12:59 PM, Daniel P. Berrangé wrote:
On Tue, Jul 24, 2018 at 06:53:54PM +0200, Cornelia Huck wrote:
> On Tue, 24 Jul 2018 18:08:21 +0200
> Jiri Denemark <jdenemar(a)redhat.com> wrote:
>
>> On Mon, Jul 23, 2018 at 17:45:33 -0400, Collin Walling wrote:
>>> Use model name "qemu" instead of "max" when calling
>>> query-cpu-model-expansion for s390 on tcg.
>>>
>>> Signed-off-by: Collin Walling <walling(a)linux.ibm.com>
>>> ---
>>> src/qemu/qemu_capabilities.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>>> index 23b4833..e9b44cc 100644
>>> --- a/src/qemu/qemu_capabilities.c
>>> +++ b/src/qemu/qemu_capabilities.c
>>> @@ -2356,7 +2356,10 @@ virQEMUCapsProbeQMPHostCPU(virQEMUCapsPtr qemuCaps,
>>>
>>> if (tcg || !virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM)) {
>>> virtType = VIR_DOMAIN_VIRT_QEMU;
>>> - model = "max";
>>> + if (ARCH_IS_S390(qemuCaps->arch))
>>> + model = "qemu";
>>> + else
>>> + model = "max";
>>
>> I think we should also check if "max" is a supported model
>> (qemuCaps->tcgCPUModels is already populated at this point) and only use
>> "qemu" on s390 if "max" is not supported. And please, report
the issue
>> to QEMU developers since one of the reasons behind "max" is its
>> universal availability on everywhere CPU model expansion is supported.
>
> Hm, can you point me to that discussion? A quick search through the
> QEMU log gives me the addition of the "max" model on i386 as a
> replacement to the "host" model for !kvm, but nothing about it being
> universal...
I don't recall the link but "max" is supposed to be the standard shorthand
for "enable all the features supported by the virt type". IOW, 'max'
should
work both KVM and TCG ("host" was only well defined for KVM), and across
all architectures.
So having to use a different name on s390 is a bug in QEMU imho.
Regards,
Daniel
Thanks for expanding on what the "max" model name is suppose to be. I wonder if
a
s/"qemu"/"max" in QEMU would suffice (I'm taking a shot in the
dark here.)
@Connie, @David, you both are far more knowledgeable in this area than I am. What
do either of you suggest for moving forward with this? Should we forward this
discussion on qemu-devel?
--
Respectfully,
- Collin Walling