similar to: [PATCH v2] pvh: disable MTRR feature on cpuid for Dom0

Hi, this patch passes the orginal cpuid bits for X86_FEATURE_DTES64 (64-bit DS Area) and X86_FEATURE_DSCPL (CPL Qualified Debug Store) to the guest when the BTS feature is switched on. I forgot this when I did this BTS emulation. Thanks. Dietmar. Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> diff -r a6b81234b189 xen/arch/x86/hvm/vmx/vpmu_core2.c ---

- 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 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

See http://lkml.org/lkml/2008/10/1/246 for more context. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-10-27/xen/arch/x86/domain.c =================================================================== --- 2008-10-27.orig/xen/arch/x86/domain.c 2008-11-11 16:24:48.000000000 +0100 +++ 2008-10-27/xen/arch/x86/domain.c 2008-11-19 10:22:34.000000000 +0100 @@ -1888,6 +1888,8 @@ void

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

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

From: Borislav Petkov <bp at suse.de> Using static_cpu_has() is pointless on those paths, convert them to the boot_cpu_has() variant. No functional changes. Reported-by: Nadav Amit <nadav.amit at gmail.com> Signed-off-by: Borislav Petkov <bp at suse.de> Cc: Aubrey Li <aubrey.li at intel.com> Cc: Dave Hansen <dave.hansen at intel.com> Cc: Dominik Brodowski <linux

From: Mukesh Rathor <mukesh.rathor@oracle.com> Use .ascii and .asciz to define xen feature string. Note, the PVH string must be in a single line (not multiple lines with \) to keep the assembler from putting null char after each string before \. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> ---

In this patch, we change read_segment_register to take vcpu and regs parameters for PVH (in upcoming patches). No functionality change. also, make emulate_privileged_op() public for later. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> diff -r 93d95f6dd693 -r 0339f85f6068 xen/arch/x86/domain.c --- a/xen/arch/x86/domain.c Fri Jan 11 16:22:57 2013 -0800 +++ b/xen/arch/x86/domain.c

This is the latest version of a patch that adds hugepage support to the Xen hypervisor in a PV environment. It is against the latest xen-unstable tree on xenbits.xensource.com. I believe this version addresses the comments made about the previous version of the patch. Hugepage support must be enabled via the hypervisor command line option "allowhugepage". It assumes the guest

Hi, while testing some APERF/MPERF semantics I discovered that this feature is enabled in Xen Dom0, but is not reliable. The Linux kernel''s scheduler uses this feature if it sees the CPUID bit, leading to costly RDMSR traps (a few 100,000s during a kernel compile) and bogus values due to VCPU migration during the measurement. The attached patch explicitly disables this CPU capability

After fixing the respective problems in the hypervisor it became apparent that there also was a problem in the guest. Attached patch fixes - an obvious cut-and-paste error - return value range issues Clearly this patch should, in an appropriately modified form if necessary, also be applied to trees other than the merge one. Jan _______________________________________________ Xen-merge mailing

Hi, Quite a while ago there were a few patches for adding MTRR support to the Xen kernel, and yes, I know they''ve been NAK from the mainline kernel. I''m wondering if they still exist on some branches of some repo that I could possibly get them from? I found a couple of patch series posted onto the mailing list before but it''s not cleared what version or what tree

Hello. I'm running Centos 4.3 with KDE from CentOS. There're some "unsupported" packages, like kernel 2.6.9-34.108.plus.c4smp, Picasa and Google Earth. Picasa and Google Earth had never showed critical problems (before), although they're beta versions. Today, I started Picasa and Google Earth at the same time, and the X became a black screen, like it was killed and was just

I need your help and DEL's tech support doesn't provide any help on this one. We have a lot of different type of DELL desktops from old-type hyper-thread cpu, to dual-core and quad-core cpus (most are Xeons). We run all versions of CentOS, but most are latest 5.5 (also up-to-date) and are very happy about that. The primary software on those Linux systems is IDL, which uses OpenGL

Getting things in sync with i386. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch adds the MTRR MSRs save/restore support. Signed-off-by: Disheng Su <disheng.su@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

On Thu, 17 Jan 2013 22:22:47 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Jan had some comments about that patch: > > https://patchwork.kernel.org/patch/1745041/ > > Please fix it up so I can put it in the Linux tree. Please see below. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Thanks, Mukesh diff --git a/arch/x86/xen/xen-head.S

On Mon, Dec 02, 2013 at 05:11:49PM +0100, Roger Pau Monn? wrote: > Hello, > > I''ve yet updated the PVH work one more time, regarding some comments > from emaste in order to try to make this work easier to merge with the > UEFI changes. In this regard, the parse_memmap hook now fetches and > parses the memmap, so UEFI can define it''s own hook and do the fetching