search for: x86_feature_constant_tsc

>From /xen-unstable.hg/xen/arch/x86/cpu/intel.c if ((c->x86 == 0xf && c->x86_model >= 0x03) || (c->x86 == 0x6 && c->x86_model >= 0x0e)) set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); if (cpuid_edx(0x80000007) & (1u<<8)) { set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability); set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability); } I am trying to determine the difference betwe...

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

...duled for a + * long time. To skip these checks at runtime we set these capability bits, + * so that the kernel could just trust the hypervisor with providing a + * reliable virtual TSC that is suitable for timekeeping. + */ +static void __init vmware_set_capabilities(void) +{ + setup_force_cpu_cap(X86_FEATURE_CONSTANT_TSC); + setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); +} + static void __init vmware_platform_setup(void) { uint32_t eax, ebx, ecx, edx; @@ -152,6 +170,8 @@ static void __init vmware_platform_setup(void) #ifdef CONFIG_X86_IO_APIC no_timer_check = 1; #endif + + vmware_set_capabilities(); }...

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Reduce special casing of xen_cpuid() by using cpu capabilities instead of faked cpuid nodes. This cleanup enables us remove the hypervisor specific set_cpu_features callback as the same effect can be reached via setup_[clear|force]_cpu_cap(). Removing the rest faked nodes from xen_cpuid() requires some more work as the remaining cases (mwait leafs and extended topology info) have to be handled

Hello, I encountered the following bug when migrating a Linux-2.6.32.54 PV domain on Xen-3.4.3 between different hosts, whose uptime differs by several minutes (3 hosts, each ~5 minutes apart): When migrating from a host with lower uptime to a host with higher uptime, the VM looses it''s network connection for some time and then continues after some minutes (roughly equivalent to the

...initialize(struct lguest *lg) { + u32 tsc_speed; + if (lg->regs->eax != LHCALL_LGUEST_INIT) { kill_guest(lg, "hypercall %li before LGUEST_INIT", lg->regs->eax); return; } + + /* We only tell the guest to use the TSC if it's reliable. */ + if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && !check_tsc_unstable()) + tsc_speed = tsc_khz; + else + tsc_speed = 0; lg->lguest_data = (struct lguest_data __user *)lg->regs->edx; /* We check here so we can simply copy_to_user/from_user */ @@ -148,6 +156,7 @@ static void initialize(struct lguest *lg || get_user...

...initialize(struct lguest *lg) { + u32 tsc_speed; + if (lg->regs->eax != LHCALL_LGUEST_INIT) { kill_guest(lg, "hypercall %li before LGUEST_INIT", lg->regs->eax); return; } + + /* We only tell the guest to use the TSC if it's reliable. */ + if (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) && !check_tsc_unstable()) + tsc_speed = tsc_khz; + else + tsc_speed = 0; lg->lguest_data = (struct lguest_data __user *)lg->regs->edx; /* We check here so we can simply copy_to_user/from_user */ @@ -148,6 +156,7 @@ static void initialize(struct lguest *lg || get_user...

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

Hi, This series corresponds do older patches in the paravirt series that was neither already applied, nor I will touch again. In general, they do not touch code that can be unified (at least, without being the unification a big problem on its own). They passed through this list a lot of times, so I feel them ready for inclusion, unless someone opposes. As with the other patches, they apply to

Various versions of Linux under various circumstances select TSC as the primary clocksource for the kernel. This is especially true for uniprocessor kernels, but also in some cases for multiprocessor kernels. In most cases, this is because a processor bit (tsc_invariant? constant_tsc?) is passed through directly from the hardware via Xen and tested by the hvm guest and the result implies that

...er(struct notifier_block *nb, unsigned long val, + void *data) +{ + struct cpufreq_freqs *freq = data; + struct vcpu_time_info *info = &vcpu_info(freq->cpu)->time; + struct xen_platform_op op; + cpumask_t oldmask; + unsigned int cpu; + + if (cpu_has(&cpu_data[freq->cpu], X86_FEATURE_CONSTANT_TSC)) + return 0; + + if (val == CPUFREQ_PRECHANGE) + return 0; + + /* change the frequency inside the hypervisor */ + oldmask = current->cpus_allowed; + set_cpus_allowed(current, cpumask_of_cpu(freq->cpu)); + schedule(); + op.cmd = XENPF_change_freq; + op.u.change_freq.info = info; + op.u.chan...

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi all, I've been working on lguest64 and in order to do this, I had to move a lot of the i386 specific out of the way. Well, the lguest64 port is still not ready to display, but before Rusty makes too many changes I would like this in upstream so I don't have to keep repeating my changes :-) So this patch series moves lguest32 out of the way for other archs. -- Steve

Hi all, I've been working on lguest64 and in order to do this, I had to move a lot of the i386 specific out of the way. Well, the lguest64 port is still not ready to display, but before Rusty makes too many changes I would like this in upstream so I don't have to keep repeating my changes :-) So this patch series moves lguest32 out of the way for other archs. -- Steve

[ Changes since last version. - Move lg.h to include/asm instead (suggested by Rusty Russel) - All steps of the series compiles (suggested by Stephen Rothwell) - Better ifdef header naming (suggested by Stephen Rothwell) - Added Andi Kleen to CC (forgot to on V1) ] Hi all, I've been working on lguest64 and in order to do this, I had to move a lot of the i386 specific out of the

[ Changes since last version. - Move lg.h to include/asm instead (suggested by Rusty Russel) - All steps of the series compiles (suggested by Stephen Rothwell) - Better ifdef header naming (suggested by Stephen Rothwell) - Added Andi Kleen to CC (forgot to on V1) ] Hi all, I've been working on lguest64 and in order to do this, I had to move a lot of the i386 specific out of the

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c