search for: xenpf_set_processor_pminfo

...-09-19/xen/include/public/platform.h =================================================================== --- 2008-09-19.orig/xen/include/public/platform.h 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/include/public/platform.h 2008-09-19 13:59:35.000000000 +0200 @@ -312,6 +312,16 @@ struct xenpf_set_processor_pminfo { typedef struct xenpf_set_processor_pminfo xenpf_set_processor_pminfo_t; DEFINE_XEN_GUEST_HANDLE(xenpf_set_processor_pminfo_t); +#define XENPF_get_cpu_freq 55 +struct xenpf_get_cpu_freq { + /* IN variables */ + uint32_t vcpu; + /* OUT variables */ + uint32_t freq; /* in kHz...

...NFIG_ACPI_PROCESSOR_AGGREGATOR + acpi_pad_ops.init = xen_acpi_pad_init; +#endif +} diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index c168468..56ec72a 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -297,6 +297,19 @@ struct xenpf_set_processor_pminfo { }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_set_processor_pminfo); +#define XENPF_core_parking 60 + +#define XEN_CORE_PARKING_SET 1 +#define XEN_CORE_PARKING_GET 2 +struct xenpf_core_parking { + /* IN variables */ + uint32_t type; + /* IN variables: set cpu nums expected to be idled */ +...

Now that I finally got around to update our sources, I had a closer look at those changes, and apart from stylistic issues on the Linux side (part of which I may have asked for, but the result was somewhat overdone so the code is hardly legible now - I''ve got a patch queued to streamline this a little) I find it rather odd (fragile) that the who-is-in-charge information gets propagated

...d by default. User needs pass xen cmdline and also enable >>dom0 CPU_FREQ. Once that''s done, everything should work. > >At least as enabling in Xen is concerned, I can''t see this is >the case: the >respective initializer functions are being called out of the >XENPF_set_processor_pminfo handler unconditonally. I.e. I''m missing >where this logic would be suppressed (kind of a > > ret = -ENOSYS; > if ( cpufreq_controller != FREQCTL_xen ) > break; > >missing at the top of the XEN_PM_PX sub-case). You''re right. This is a...

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that

There''re basically two methods to enter a given C-state: legacy (hlt + I/O read), and native(using mwait). MWAIT is always preferred when both underlying CPU and OS support, which is a more efficient way to conduct C-state transition. Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one step to notify BIOS about a set of capabilities supported by OSPM. One capability

Hi, I''ve still have problems with ACPI(?) on Xen. After some system startup or resume CPU temperature goes high although all domUs (and dom0) are idle. On "good" system startup it is about 50-55C, on "bad" - above 67C (most time above 70C). I''ve noticed difference in C-states repored by Xen (attached files). On "bad" startups in addition suspend