[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Is seems necessary to pass "migratable=no/yes" to qemu.

The patch
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.
"invtsc is available only if using: -cpu host,migratable=no,+invtsc."

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'>
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:
it forbids guest domain to start up if the host has INVTSC while the guest(qemu) does not.
        for (i = 0; def->cpu && i < def->cpu->nfeatures; i++) {
            virCPUFeatureDefPtr feature = &def->cpu->features[i];

            if (feature->policy != VIR_CPU_FEATURE_REQUIRE)

            if (STREQ(feature->name, "invtsc") &&
                !cpuHasFeature(guestcpu, feature->name)) {
                virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
                               _("host doesn't support invariant TSC"));
                goto cleanup;

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]