Displaying 20 results from an estimated 200 matches similar to: "[PATCH] vpmu intel: pass through cpuid bits when BTS is enabled"
2012 Feb 29
0
[PATCH] vpmu: cleanup structures
Hi,
a small cleanup of vpmu structures:
- struct msr_load_store_entry is unused
- struct pmumsr is only used in the vmx part
Dietmar.
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
# HG changeset patch
# Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9
diff -r a7bacdc5449a xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Mon Feb 27 17:05:18 2012
2013 Dec 13
0
[PATCH v2] pvh: disable MTRR feature on cpuid for Dom0
MTRR is not available for PVH Dom0, so prevent cpuid from
reporting it as an available feature.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
This should go in after Mukesh Dom0 series, or merged
2012 Feb 28
3
[Patch] X86: expose HLE/RTM features to dom0
X86: expose HLE/RTM features to dom0
Intel recently release 2 new features, HLE and TRM.
Refer to http://software.intel.com/file/41417.
This patch expose them to dom0.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
diff -r 92e03310878f xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c Wed Feb 08 21:05:52 2012 +0800
+++ b/xen/arch/x86/traps.c Mon Feb 27 02:23:42 2012 +0800
@@ -857,9
2011 Nov 24
0
[PATCH 6/6] X86: implement PCID/INVPCID for hvm
X86: implement PCID/INVPCID for hvm
This patch handle PCID/INVPCID for hvm:
For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, and we just set INVPCID non-root behavior as running natively;
For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPCID at vmm by setting INVPCID non-root behavior as vmexit.
Signed-off-by: Liu, Jinsong
2013 Dec 02
0
[PATCH v4 3/7] X86: MPX IA32_BNDCFGS msr handle
From 291adaf4ad6174c5641a7239c1801373e92e9975 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 28 Nov 2013 05:26:06 +0800
Subject: [PATCH v4 3/7] X86: MPX IA32_BNDCFGS msr handle
When MPX supported, a new guest-state field for IA32_BNDCFGS
is added to the VMCS. In addition, two new controls are added:
- a VM-exit control called "clear BNDCFGS"
- a
2012 Mar 01
3
[PATCH v2] x86: Use deep C states for off-lined CPUs
# 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
2013 Aug 23
2
[PATCH] Nested VMX: Allow to set CR4.OSXSAVE if guest has xsave feature
From: Yang Zhang <yang.z.zhang@Intel.com>
We exposed the xsave feature to guest, but we didn''t allow guest
to set CR4.OSXSAVE when guest running in nested mode. This will
cause win 7 guest fail to use XP mode. In this patch, we allow guest
to set CR4.OSXSAVE in nested mode when it has the xsave feature.
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
---
2013 Jan 03
2
[PATCH V4] mem_event: Add support for MEM_EVENT_REASON_MSR
Add the new MEM_EVENT_REASON_MSR event type. Works similarly
to the other register events, except event.gla always contains
the MSR address (in addition to event.gfn, which holds the value).
MEM_EVENT_REASON_MSR does not honour the HVMPME_onchangeonly bit,
as doing so would complicate the hvm_msr_write_intercept()
switch-based handling of writes for different MSR addresses,
with little added
2012 Sep 11
0
[PATCH 1/3] x86/hvm: don't use indirect calls without need
Direct calls perform better, so we should prefer them and use indirect
ones only when there indeed is a need for indirection.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg
void pmu_apic_interrupt(struct cpu_user_regs *regs)
{
ack_APIC_irq();
-
2013 Sep 23
11
[PATCH v4 0/4] x86/HVM: miscellaneous improvements
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>
2013 Apr 09
39
[PATCH 0/4] Add posted interrupt supporting
From: Yang Zhang <yang.z.zhang@Intel.com>
The follwoing patches are adding the Posted Interrupt supporting to Xen:
Posted Interrupt allows vAPIC interrupts to inject into guest directly
without any vmexit.
- When delivering a interrupt to guest, if target vcpu is running,
update Posted-interrupt requests bitmap and send a notification event
to the vcpu. Then the vcpu will handle this
2012 Dec 20
4
[PATCH V2] mem_event: Add support for MEM_EVENT_REASON_MSR
Add the new MEM_EVENT_REASON_MSR event type. Works similarly
to the other register events, except event.gla always contains
the MSR type (in addition to event.gfn, which holds the value).
Signed-off-by: Razvan Cojocaru <rzvncj@gmail.com>
Acked-by: Tim Deegan <tim@xen.org>
diff -r b04de677de31 -r e33d3d37dfbf xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Tue Dec 18 18:16:52 2012
2006 Aug 10
0
[BTS] Dr Nic''s Magic Models - Class creation
For anyone interesting in some meta-programming ideas, I''ve written up a
short explanation about the Class Creation feature of Dr Nic''s Magic
Models.
I know most forum posts start with "How do I..." but thought it might be
interesting reading for the ppl who answer the forum posts that start
with "How do I..." :)
2013 Jul 10
2
[LLVMdev] [BUG] Support unqualified btr, bts
Hi,
I happened to notice that linux.git uses plenty of btr and bts
instructions (not btrl, btrw, btsl, btsw). For examples, see
arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity,
while GNU as is fine with them. Surely, there must be architectures
where the w/l variant is unavailable? LLVM must support those
architectures, no?
Thanks.
2013 Jul 10
0
[LLVMdev] [BUG] Support unqualified btr, bts
On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> Hi,
>
> I happened to notice that linux.git uses plenty of btr and bts
> instructions (not btrl, btrw, btsl, btsw). For examples, see
> arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity,
> while GNU as is fine with them. Surely, there must be architectures
> where
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> Also, please elaborate on why this is a good change. Because gas accepts it
> isn’t sufficient reason in and of itself.
That they're valid instructions isn't sufficient reason? Should I
additionally say that linux.git uses them?
I wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> Jim Grosbach wrote:
>> Also, please elaborate on why this is a good change. Because gas accepts it
>> isn’t sufficient reason in and of itself.
>
> That they're valid instructions isn't sufficient reason? Should I
> additionally say that linux.git uses them?
>
Is the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.
>
> The best reference I know of for the AT&T syntax is: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
I'm not sure
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> Jim Grosbach wrote:
> > No. The above rule is absolutely the wrong thing to do, as has been
> > previously noted.
>
> I don't give a shit about whether you think it is "absolutely wrong"
> or not; I did what hpa and the Intel manual outlined. If you have
> some _reason_ not to do