similar to: expose MWAIT to dom0

Could anyone summarize what the support status of cpu frequency changes is at present. I don''t seem to recall generic changes to the hpyervisor in that respect, but the linux tree has fairly extensive changes to the powernow-k8 driver (which would make sense to me only if all other cpufreq drivers are fully supported now, too). Thanks, Jan

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330642361 -3600 # Node ID 99df5c6b2964ceaa73651d7bc02fb1ae820f7691 # Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9 x86: Use deep C states for off-lined CPUs Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT is used). This patch allows a core to go to deeper C states

Hi Keir, so far the convention seems to be to assume that guest attempts to execute instructions not supported by the underlying CPU would never make it into the emulator. Is that really correct (in particular in the context of real mode emulation, where it''s not just single instructions that get emulated)? >From earlier work on the emulation code I seem to recall that it''s

CPUID level 0x00000007:0 (ebx) is word 9, instead of word 7. ... make it consistent with native Linux. Signed-off-by: Li Xin <xin.li@intel.com> diff -r d7c755c25bb9 xen/include/asm-x86/cpufeature.h --- a/xen/include/asm-x86/cpufeature.h Sat May 28 08:58:08 2011 +0100 +++ b/xen/include/asm-x86/cpufeature.h Tue May 31 07:34:34 2011 +0800 @@ -142,7 +142,7 @@ #define X86_FEATURE_TOPOEXT

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

Enable Px/Cx related CPUID/MSR bits for dom0 to get correct Px/Cx info. Signed-off-by: Wei Gang <gang.wei@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different

Hi Jan, I was wondering if we should not let the code fall through and clear all registers to zero but rather clear just the one bit we care about? My concern is that a future Intel revision may expand this function and return other information besides that XSAVEOPT, which would then be wiped out by the fall-through code. I''m thinking something like this. Let me know if I have

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>

Is it intentional that - under SVM, 32-bit guests can freely set EFER.LME - under VMX, 32-bit guests can''t access EFER at all? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

Using Xen 4.2 unstable rev. 25483. I get errors like this: pt_pci_read_config: [00:10:0] Error: Failed to read register with offset exceeding FFh. [Offset:ffh][Length:1] in my qemu log for a domU with some devices passed through to it. I investigated and found that at hw/pass-through.c line 1717

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

The first and third patches are cleaned up versions of an earlier v3 submission by Yang. 1: Nested VMX: check VMX capability before read VMX related MSRs 2: VMX: clean up capability checks 3: Nested VMX: fix IA32_VMX_CR4_FIXED1 msr emulation 4: x86: make hvm_cpuid() tolerate NULL pointers Signed-off-by: Jan Beulich <jbeulich@suse.com>

- use __clear_bit() rather than clear_bit() - use switch statements instead of long series of if-s - eliminate pointless casts (Applies cleanly only on top of the previously sent SVM/EFER patch.) Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/hvm/hvm.c =================================================================== ---

Hi, Is there any documentation on enabling hypervisor support for both C and P-state control? On xen-unstable and linux-2.6.18-xen.hg, if I enable cpuidle=1 on the xen command line and then run xenpm, I will get output for C-states (shown below) but it complains that "Xen cpufreq is not enabled!" cpu id : 0 total C-states : 2 idle time(ms) : 73264 C0

This patchset enable support for C1 mwait entry. [PATCH 1/3] dom0-C1-FFH.patch. It gets C1 information from ACPI table and pass it to Xen. [PATCH 2/3] add-idx-field.patch. This patch adds an idx field in the ''struct acpi_processor_cx''. It can simplify some coding lines. [PATCH 3/3] xen-C1-FFH.patch. It adds support for C1 FFH (mwait) entry. Meanwhile add timing for C1. The

On Thu, Jun 11, 2020 at 03:10:45PM +0200, Joerg Roedel wrote: > On Tue, May 19, 2020 at 11:38:45PM -0700, Sean Christopherson wrote: > > On Tue, Apr 28, 2020 at 05:17:09PM +0200, Joerg Roedel wrote: > > > +static enum es_result vc_handle_monitor(struct ghcb *ghcb, > > > + struct es_em_ctxt *ctxt) > > > +{ > > > + phys_addr_t monitor_pa; > >