Am 18.01.2017 um 18:34 schrieb Eduardo Habkost:
> On Wed, Jan 18, 2017 at 12:09:28PM -0500, Jason J. Herne wrote:
>> On 01/18/2017 12:00 PM, Eduardo Habkost wrote:
>>> On Tue, Jan 17, 2017 at 10:22:10AM -0500, Jason J. Herne wrote:
>>>> On 01/16/2017 08:01 PM, Eduardo Habkost wrote:
>>>>> This is a follow-up to the series that implements
>>>>> query-cpu-model-expansion. Before including the test script, the
>>>>> series has some fixes to allow the results of
>>>>> query-cpu-model-expansion to be used in the QEMU command-line.
>>>>>
>>>>> The script probably will work on s390x too, but I couldn't test
>>>>> it yet.
>>>>>
>>>>
>>>> Eduardo,
>>>>
>>>> This test seems to mostly work on s390. The only issue I ran into is
>>>> querying host model using tcg only. s390 requires kvm to query the host
>>>> model. Perhaps we could just skip the tcg host test case on s390?
>>>
>>> We could still try to test "host", but add it to a greylist where
>>> errors returned by query-cpu-model-expansion can be non-fatal.
>>> query-cpu-model-expansion model="host" can also fail with KVM if
>>> the host doesn't support CPU models.
>>>
>>
>> David had the idea to just support -cpu host for tcg. We could do that.
>> In the meantime, I'm ok with your greylist idea too. This would allow the
>> script to work properly on s390 right from the start, and we can remove the
>> greylist when s390 supports specifying -cpu host for tcg.
>
> I believe we will still need to ignore query-cpu-model-expansion
> errors on some cases, otherwise the test script will fail on
> hosts where KVM doesn't support CPU models in KVM.
That is indeed true. For "host" + KVM there would have to be an extra
check. non-fatal error sound right for this case (e.g. a warning)
>
> But we probably don't need a hardcoded greylist, anyway: we could
> just make the error non-fatal in case the CPU model is not
> reported as migration-safe in query-cpu-definitions.
>
> But I was wondering:
>
> 1) Isn't "-cpu host" the default CPU model on s390x on KVM,
> even if the host doesn't support CPU models?
Yes, it has an inbuilt compatibility mode when specified. If KVM support
for cpu models is missing, using "-cpu host" will work (as it worked on
QEMU versions without cpu model support), doing something like "-cpu
host,vx=on" will not work, as modifying features is not possible (as the
interface for query/config is missing).
Using "host" for all query-cpu-model is forbiden, as we can't tell what
this model looks like.
>
> 2) Is it really correct to return an error on
> "query-cpu-model-expansion model=host type=full" if the host
> doesn't support CPU models?
>
Yes it is, because there is no way to tell which features there are.
Returning { name: "host", props: {} } would be misleading, as it
would mean that there are no features. Which is wrong. We just can't
tell. It is up to the caller to handle this. E.g. ignoring and
continuing, doing compatibility stuff or simply reporting an error.
Also think about "query-cpu-model-expansion model=host type=static",
which will primarily be used by libvirt on s390x. There is no way to
expand this into a static cpu model. Faking anything will just hide errors.
If "host" can't be expanded, QEMU has to be treated like there is no CPU
model support (as for older QEMU versions).
> What if it just returned { name: "host", props: {} }
> on those cases, meaning that the CPU model is valid and
> usable, but QEMU is unable to provide extra information about
> it.
>
--
David
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
