[libvirt] Is seems necessary to pass "migratable=no/yes" to qemu.
zhang bo
oscar.zhangbo at huawei.com
Thu Sep 25 02:31:16 UTC 2014
On 2014/9/24 19:49, Ján Tomko wrote:
> On 09/24/2014 05:28 AM, zhang bo wrote:
>> The patch
>> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=de0aeafe9ce3eb414c8b5d3aa8995d776a2952de
>> removes invtsc flag in the host-model CPU.
>>
>> I'm wondering, will it be better to pass args "migratable=no/yes" to qemu, and let qemu complete the
>> remaining work? As that qemu has checked whether it's necessary to use invtsc or not.
>
> The 'migratable' property is only for -cpu host (<cpu mode='host-passthrough'>
> in libvirt).
>
> For mode='host-model', libvirt detects the model and features of the host CPU
> and passes it as -cpu <model>,+feat,+feat2,...
> so we can't leave that to QEMU.
>
>> ----------
>> "invtsc is available only if using: -cpu host,migratable=no,+invtsc."
>> http://git.qemu.org/?p=qemu.git;a=commit;h=120eee7d1fdb2eba15766cfff7b9bcdc902690b4
>> ----------
>>
>> There's another problem, if we do not pass "migratable=no" to qemu.
>> Consider if we set host mode to pass-through
>> ---------
>> <cpu mode='host-passthrough'>
>> </cpu>
>> ---------
>> then the vm->def->cpu->features contains invtsc. however, qemu will automatically remove this cpu flag
>> as that "migration=no" is not passed to it. thus, the guest will not start up. This problem is in fact
>> caused by the patch:
>> http://libvirt.org/git/?p=libvirt.git;a=commit;h=fba6bc47cbcabbe08d42279691efb0dff3b9c997,
>> it forbids guest domain to start up if the host has INVTSC while the guest(qemu) does not.
>
> Regardless of QEMU support for invtsc, I'm only able to start the domain,
> restore or migration fails.
>
> As far as I know, only 'invtsc' is the problematic feature, because it both
> a) can appear in the host CPU (so libvirt assumes -cpu host will add it)
> b) is checked by qemuProcessVerifyGuestCPU (and libvirt complains when it's
> not there)
>
> For other features, we only add them to qemu command line and let qemu filter
> out the unsupported ones.
>
>> -------------
>> for (i = 0; def->cpu && i < def->cpu->nfeatures; i++) {
>> virCPUFeatureDefPtr feature = &def->cpu->features[i];
>>
>> if (feature->policy != VIR_CPU_FEATURE_REQUIRE)
>> continue;
>>
>> if (STREQ(feature->name, "invtsc") &&
>> !cpuHasFeature(guestcpu, feature->name)) {
>> virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
>> _("host doesn't support invariant TSC"));
>> goto cleanup;
>> }
>> }
>> break;
>> --------------
>>
>>
>> In conclusion:
>> 1 Will it better to pass args "migratable=yes/no" to qemu rather than doing the mask-invtsc job in libvirt?
>> 2 If the guest has "pass-through" cpu mode, then it's unable to start up, because qemu removes invtsc, and
>> vm->def->cpu->features has it. It seems a BUG.
>>
>
> I think the simplest fix for host-passthrough would be to apply the same
> filter host-model has.
>
> But since using invtsc with host-passthrough requires both +invtsc and
> migratable=no, so we'd need to either add a 'migratable' option to
> host-passthrough (this would skip the filter and add migratable=on), or allow
> fine-tuning the features for host-passthrough too.
>
> Jan
>
Additional to the 2 suggestions, will that be OK to remove the codes in qemuProcessVerifyGuestCPU that checks whether the vm->def has
invtsc flag while qemu doesn't?
- if (STREQ(feature->name, "invtsc") &&
- !cpuHasFeature(guestcpu, feature->name)) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
- _("host doesn't support invariant TSC"));
- goto cleanup;
- }
Removing these codes, plus with the solution that "add 'migratable' option to host-passthrough", it seems the problem would
be gone, and invtsc would not be so 'distinctive' in libvirt any more.
More information about the libvir-list
mailing list