search for: xen_platform_op

...ic/platform.h> -#include <acpi/cpufreq/processor_perf.h> +#include <acpi/cpufreq/cpufreq.h> #include <asm/edd.h> #include <asm/mtrr.h> #include "cpu/mtrr/mtrr.h" @@ -55,6 +55,7 @@ static long cpu_frequency_change_helper( ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op) { ret_t ret = 0; + struct vcpu *v; struct xen_platform_op curop, *op = &curop; if ( !IS_PRIV(current->domain) ) @@ -312,7 +313,6 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe { uint32_t cpu; uint64_t idletime, now = NOW(); - str...

...void dbs_check_cpu(struct cpu_dbs idle_ticks = tmp_idle_ticks; } load = (100 * (total_ticks - idle_ticks)) / total_ticks; + return load; +} +#else + +#include <xen/interface/platform.h> +static int dbs_calc_load(struct cpu_dbs_info_s *this_dbs_info) +{ + int load = 0; + struct xen_platform_op op; + uint64_t idletime[NR_CPUS]; + uint64_t totaltime[NR_CPUS]; + struct cpufreq_policy *policy; + unsigned int j; + + op.cmd = XENPF_getidletime; + op.u.getidletime.max_cpus = num_online_cpus(); + set_xen_guest_handle(op.u.getidletime.idletime, idletime); + set_...

...*/ + struct vcpu_time_info *info; /* vcpu time info for changing vcpu */ + uint32_t old; /* original frequency */ + uint32_t new; /* new frequency */ + uint32_t cpu_num; +}; +typedef struct xenpf_change_freq xenpf_change_freq_t; +DEFINE_XEN_GUEST_HANDLE(xenpf_change_freq_t); + struct xen_platform_op { uint32_t cmd; uint32_t interface_version; /* XENPF_INTERFACE_VERSION */ @@ -176,6 +187,7 @@ struct xen_platform_op { struct xenpf_platform_quirk platform_quirk; struct xenpf_firmware_info firmware_info; struct xenpf_enter_acpi_sleep enter_acpi_sleep; +...

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.

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

...+ */ + +#include <linux/kernel.h> +#include <linux/types.h> +#include <acpi/acpi_bus.h> +#include <acpi/acpi_drivers.h> + +#include <asm/xen/hypercall.h> + +static DEFINE_MUTEX(xen_cpu_lock); + +static int xen_acpi_pad_idle_cpus(int *num_cpus) +{ + int ret; + + struct xen_platform_op op = { + .cmd = XENPF_core_parking, + .interface_version = XENPF_INTERFACE_VERSION, + }; + + /* set cpu nums expected to be idled */ + op.u.core_parking.type = XEN_CORE_PARKING_SET; + op.u.core_parking.idle_nums = (uint32_t)*num_cpus; + ret = HYPERVISOR_dom0_op(&op); + if (ret) + return ret;...

...static void dbs_check_cpu(struct cpu_dbs idle_ticks = tmp_idle_ticks; } load = (100 * (total_ticks - idle_ticks)) / total_ticks; + return load; +} +#else + +#include <xen/interface/platform.h> +static int dbs_calc_load(struct cpu_dbs_info_s *this_dbs_info) +{ + int load = 0; + struct xen_platform_op op; + uint64_t idletime[NR_CPUS]; + struct cpufreq_policy *policy; + unsigned int j; + cpumask_t cpumap; + + op.cmd = XENPF_getidletime; + set_xen_guest_handle(op.u.getidletime.cpumap_bitmap, (uint8_t *) cpus_addr(cpumap)); + op.u.getidletime.cpumap_nr_cpus = NR_CPUS;// num_online_cpu...

...n, and adds hooks to the acpi sub-system, including the acpi_processor_driver, and the related library functions. 2. acpi_parser_xen_driver.patch This patch implements the Xen version of the external control operation interface. 3. acpi_parser_platform_hypercall.patch This patches implements the xen_platform_op hypercall, to pass the parsed ACPI info to hypervisor. == Misc == To make this patch works correctly, there is a corner case need to consider: processor in domain0 is virtual CPU, while BIOS ACPI table provides the physical CPU info, since the vCPU and pCPU is not 1:1 mapped, this may caused unex...

...xen_hypercall(xch, &hypercall)) < 0 ) Value returned is $4 = -1 (gdb) p errno $5 = 1 Any ideas how to get this working, or on where I could get better diagnostics ? I''m guessing this is caused by this code in arch/x86/platform_hypercall.c : ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op) { ret_t ret = 0; struct xen_platform_op curop, *op = &curop; if ( !IS_PRIV(current->domain) ) return -EPERM; So how do I make the IS_PRIV macro return non-zero for my domain_0 , ie. set d->is_privileged / make my domain0 into a "privileged" d...

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

...; } +#endif + +#if CONFIG_CPU_FREQ +/* + * cpufreq scaling handling + */ +static int time_cpufreq_notifier(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, cpu...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. First 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

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

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