similar to: [PATCH V2 1/2] cpufreq, xenpm: fix cpufreq and xenpm mismatch

Currently, enable/disable turbo mode on AMD is broken: $ xenpm enable-turbo-mode 0 <-- works and proper CPU MSR bit is set $ xenpm enable-turbo-mode 1 <-- silently broken, MSR bit not set Since ->turbo is per policy, when user requests to enable/disable turbo mode, we need to set the bit in all of the ->cpus that this policy affects. --- xen/arch/x86/acpi/cpufreq/powernow.c | 2

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1345135101 -7200 # Node ID 85190245a94d9945b7656c971ba36f7d1eff5c19 # Parent 6d56e31fe1e1dc793379d662a36ff1731760eb0c AMD, powernow: Update P-state directly when _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL When _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type is

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321356497 0 # Node ID 3cfb8f2c4ce898414279d7162206be812584bd5b # Parent 955a6c07dc5e9c55316d1678b2b7cc4313f4fd57 xen: avoid crash enabling turbo mode On a system which has not had P-state information pushed down into the hypervisor running "xenpm enable-turbo-mode" will reliably crash the host. (XEN) PM

Does anyone know what is the latest version of dom0-kernel, that supports fully xenpm hypercalls? I tried from 3.0 to 3.3 with xen-4.1.3, but none of them has xenpm working. On the other hand native kernel cpufreq is OK with all of them. My CPU is Xeon family 6 on PowerEdge 1950 III box. Regards, Dimitar Kazakov

Does anyone know what is the latest version of dom0-kernel, that supports fully xenpm hypercalls? I tried from 3.0 to 3.3 with xen-4.1.3, but none of them has xenpm working. On the other hand native kernel cpufreq is OK with all of them. My CPU is Xeon family 6 on PowerEdge 1950 III box. Regards, Dimitar Kazakov

Hi, All, I have some problem of using dvfs in Xen 3.4.1 and 2.6.18 kernel. I enabled Speed option in BIOS and add "cpufreq=xen" in the grub file. But when I entered my dom0 and type "xenpm get-cpufreq-XXX" (any xenpm argument), it returns "[CPU0] failed to get CPU P state". I am wondering if I should enable some feature of 2.6.18 during the kernel configuration.

Hi, All, I have some problem of using dvfs in Xen 3.4.1 and 2.6.18 kernel. I enabled Speed option in BIOS and add "cpufreq=xen" in the grub file. But when I entered my dom0 and type "xenpm get-cpufreq-XXX" (any xenpm argument), it returns "[CPU0] failed to get CPU P state". I am wondering if I should enable some feature of 2.6.18 during the kernel configuration.

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1338309680 -7200 # Node ID 3d52d9fe62559ed6f90cb33a4b95f536ab5bc683 # Parent 53e0571f94e4bcc45270dcbd444c7c91166cef6d xenpm: Fix reporting of C0 residence times Idle state residence times as provided by pmstat_get_cx_stat() are not reported precisely since remote core may be in idle state and therefore has not

Some versions of GCC are too stupid to figure out that cpufreq_dom is only used if !!domexist and always set in that case, and complain that it may be used uninitialised. (In general it is IMO better to avoid these kind of flag variables; I would prefer structures like for (...) { cpufreq_dom = dom; if (...) goto cpufreq_dom_found; } cpufreq_dom = 0; cpufreq_dom_found: but on

Specifically, what values are or aren''t accepted as CPU identifier, and how the values get interpreted should be consistent across sub-commands (intended behavior now: non-negative values are okay, and along with omitting the argument, specifying "all" will also be accepted). For error handling, error messages should get consistently issued to stderr, and the tool should now

- use consistent error values (stop mixing of [positive] errno values with literal -E... ones) - properly format output - don''t use leading zeros in decimal output - move printing of average frequency into P-state conditional (rather than a C-state one) - don''t print some C-state related info when CPU idle management is disabled in the hypervisor - use calloc() for array

Attached and below are a patch that unifies the shutdown code paths in Xen, including those from EARLY_FAIL. This will facilitate the use of Intel(R) TXT for measured launch by ensuring that all shutdowns will call the necessary hook to tear down the measured environment. It also centralizes any future shutdown-related changes. The patch also postpones clearing the online status APs in

Modify the cpufreq ondemand governor so that it can get idle and total ticks from the Xen hypervisor. Linux and Xen have different ideas of what an idle tick is, so the Xen values for both have to be returned in the same platform hypercall. Otherwise, use basically the same scheme as native Linux. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> iff -r 9bf1ddd0f6bf

We need to write the irq number to GICC_DIR on the physical cpu that previously received the interrupt, but currently we are doing it on the pcpu that received the maintenance interrupt. As a consequence if a vcpu is migrated to a different pcpu, the irq is going to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this

From: Julien Grall <julien.grall@citrix.com> Move smp_call_function and on_selected_cpus to common code. Signed-off-by: Julien Grall <julien.grall@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> --- Changes in V2: - Add copyright header in xen/common/smp.c xen/arch/arm/gic.c | 3 ++ xen/arch/arm/smp.c

This fixes an actual bug (failure to exit from a function after an allocation failure), an inconsistency (not removing the cpufreq_dom list member upon failure), and a latent bug (not clearing the current governor upon governor initialization failure when there was no old one; latent because the only current code path leading to this situation frees the policy upon failure and hence the governor

Another bundle of issues from Coverity triage. The first one is in x86/mm, and looks scarier than it is. The others are all in xen/drivers and AFAICT are pretty minor. Cheers, Tim.

1: x86/mwait_idle: remove assumption of one C-state per MWAIT flag 2: x86/mwait_idle: export both C1 and C1E 3: x86/mwait_idle: initial C8, C9, C10 support Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com>

From: Zhang Xiantao <xiantao.zhang@intel.com> With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 guest''s memory virtualization. In this way, L2 guest''s performance can be improved sharply. According to our testing, some benchmarks can show > 5x performance gain. Signed-off-by: Zhang Xiantao <xiantao.zhang@intel.com> Zhang Xiantao (11):

Modify the cpufreq ondemand governor so that it can get idle and total nsecs from the Xen hypervisor.  Xen uses nsecs to measure idle time, while Linux uses ticks. Other than accounting for that difference, use the same algorithm to calculate idle time as Linux does. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r 26962454b508 drivers/cpufreq/cpufreq_ondemand.c ---