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

2014-09-29 Thread Ján Tomko 
On 09/25/2014 02:59 PM, Ján Tomko wrote:
 On 09/25/2014 04:31 AM, zhang bo wrote:
 On 2014/9/24 19:49, Ján Tomko wrote:
 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;
 - }
 
 Without this check, the feature would be quietly discarded by QEMU if the host
 kernel or host CPU does not support this feature.
 
 I think it's better to leave invtsc out when we're generating the cpu
 definition for host-passthrough, as we do for host-model.
 
 Jan
 

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.


I've sent a patch that filters out the flag and also ignores the check for
host-passthrough (to allow guests already saved with the flag to be restored)

https://www.redhat.com/archives/libvir-list/2014-September/msg01680.html

Can you please take a look at it?

Thanks,

Jan



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

2014-09-25 Thread Ján Tomko 
On 09/25/2014 04:31 AM, zhang bo wrote:
 On 2014/9/24 19:49, Ján Tomko wrote:
 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;
 - }

Without this check, the feature would be quietly discarded by QEMU if the host
kernel or host CPU does not support this feature.

I think it's better to leave invtsc out when we're generating the cpu
definition for host-passthrough, as we do for host-model.

Jan

 
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.
 
 --
 libvir-list mailing list
 libvir-list@redhat.com
 https://www.redhat.com/mailman/listinfo/libvir-list
 




signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

2014-09-24 Thread Ján Tomko 
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



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

2014-09-24 Thread zhang bo 
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.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

2014-09-23 Thread zhang bo 
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.
--
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.
   -
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.











--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list