similar to: [PATCH] x86: add hypercall to query current underlying pCPU''s frequency

Recent Linux tries to make use of this, and has no way of getting at these bits without Xen assisting it. There doesn''t appear to be a way to obtain the same information from UEFI. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/boot/trampoline.S +++ b/xen/arch/x86/boot/trampoline.S @@ -184,11 +184,16 @@ trampoline_boot_cpu_entry: * 1. Get memory map.

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. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r b4278beaf354 xen/arch/x86/platform_hypercall.c --- a/xen/arch/x86/platform_hypercall.c

Good day - This is my first post to this list , and I''m new to Xen - any help on this issue would be much appreciated . I downloaded, built and installed xen-4.2.1 (hypervisor and tools) on an x86_64 ArchLinux box updated to latest software as of today. I am trying to bring up a Linux guest from a remote iSCSI disk. The iSCSI-initiator (open-iscsi) logs in to the remote target OK and

Hi all, this patch series makes the necessary changes to make sure that the current ARM hypercall ABI can be used as-is on 64 bit ARM platforms: - it defines xen_ulong_t as uint64_t on ARM; - it introduces a new macro to handle guest pointers, called XEN_GUEST_HANDLE_PARAM (that has size 4 bytes on aarch and is going to have size 8 bytes on aarch64); - it replaces all the occurrences of

Hi all, this patch series makes the necessary changes to make sure that the current ARM hypercall ABI can be used as-is on 64 bit ARM platforms: - it defines xen_ulong_t as uint64_t on ARM; - it introduces a new macro to handle guest pointers, called XEN_GUEST_HANDLE_PARAM (that has size 4 bytes on aarch and is going to have size 8 bytes on aarch64); - it replaces all the occurrences of

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

While compiling XEN with XSM_ENABLE=y and FLASK_ENABLE=y, I received the following error. gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe

This changeset reverts two previous corrections, for reasons that escape me. First, the domain map is again being confined to NR_CPUS, which I had submitted a patch to fix recently (yes, I realize the code has a TODO in there, but those really get forgotten about far too often). Second, the platform hypercall was reverted back to require all information to be passed to Xen in one chunk, whereas

Hello When i try to make world (any) from xen-3.0.2 to xen-unstable-src I gat following error : gcc -O2 -fomit-frame-pointer -DNDEBUG -m64 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/test1/xen-unstable/xen/include

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

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

From ba9abf6ee7e5fe0515e2d51b14743c8d5416285c Mon Sep 17 00:00:00 2001 From: Liu, Jinsong <jinsong.liu@intel.com> Date: Fri, 24 Feb 2012 02:18:02 +0800 Subject: [PATCH 2/2] Xen pad logic This patch implement Xen pad logic, and when getting pad device notification, it hypercalls to Xen hypervisor for core parking. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com> ---

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only

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

Hello, For our research we are trying to come up with a Virtual - passthrough model of device drivers in  PV guests. We are looking for 2 separate implementations : 1 for transmitting and the other for receiving the packets in the guest OS. We are relying on IOMMU to ensure isolation. We need to add  these new hypercalls for communication between the guest device driver and the hypervisor. The

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

it seems getting lost, and thus resend. Thanks, Kevin -----Original Message----- From: Tian, Kevin Sent: 2008年7月24日 8:39 To: ''Jan Beulich'' Cc: Liu, Jinsong; Keir Fraser; xen-devel@lists.xensource.com; mark.langsdorf@amd.com Subject: RE: [Xen-devel] cpufreq info propagation >From: Jan Beulich >Sent: 2008年7月23日 18:13 >> >>startup info is viable. But how

struct cpufreq_policy, including a cpumask_t member, gets copied in cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the amount of data needing copying (particularly with large NR_CPUS). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2011-10-12

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

Hi, Jeremy Since now the pv_ops domain0 is approaching, we are considering to port the dom0 power management related code, or more specifically, the Cx/Px ACPI info parsing code, to pv_ops domain0 tree, so that people can utilize Xen power management capability (Cx/PX) under pv_ops domain0. This RFC is a draft version for comments. === Overview === Requirement: Xen hypervisor need Cx/Px ACPI