Displaying 20 results from an estimated 10000 matches similar to: "x86 emulator and new isa additions"
2011 Aug 15
36
expose MWAIT to dom0
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
2011 May 30
6
[PATCH] CPUID level 0x00000007:0 (ebx) is word 9, instead of word 7
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
2011 Dec 15
10
fsincos emulation on AMD CPUs
All,
in the light of erratum #573 I''m wondering if we need to tweak or
conditionally suppress fsincos emulation. The question is whether there
is any possibility for getting the emulator to hit this instruction on AMD
(as no real mode emulation ought to be taking place there), i.e.
whether there are places where emulation gets continued eagerly
in anticipation of the need for emulation
2006 Nov 29
25
EFER in HVM guests
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
2013 Jun 04
12
[PATCH 0/4] XSA-52..54 follow-up
The first patch really isn''t as much of a follow-up than what triggered
the security issues to be noticed in the first place.
1: x86: preserve FPU selectors for 32-bit guest code
2: x86: fix XCR0 handling
3: x86/xsave: adjust state management
4: x86/fxsave: bring in line with recent xsave adjustments
The first two I would see as candidates for 4.3 (as well as
subsequent backporting,
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>
2007 Oct 17
8
cpufreq support status
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
2013 Aug 28
3
[PATCH] x86: AVX instruction emulation fixes
- we used the C4/C5 (first prefix) byte instead of the apparent ModR/M
one as the second prefix byte
- early decoding normalized vex.reg, thus corrupting it for the main
consumer (copy_REX_VEX()), resulting in #UD on the two-operand
instructions we emulate
Also add respective test cases to the testing utility plus
- fix get_fpu() (the fall-through order was inverted)
- add cpu_has_avx2,
2013 Jun 11
21
[PATCH] xen: fix initialization of wallclock time for PVHVM on migration
The initial values of the wallclock time in the shared info page are
set for PVHVM guests when the hypercall page is initialized, since the
hypercall page is not reinitialized on resume, the hypervisor
wallclock time is not properly set on resume.
Fix it by forcing an update of the wallclock values when the shared
info page is mapped.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
2013 Jan 23
10
[PATCH 0/6] x86/HVM: miscellaneous RTC emulation adjustments
Finally I got around to breaking up the similarly named monolithic
patch that caused a regression shortly before the 4.2 release and
got therefore reverted. This series consists of the broken up
pieces that - according to my testing - don''t expose the reported
lockup; the 7th will need debugging to understand what''s wrong
there.
1: use RTC_* names instead of literal numbers
2:
2013 Nov 11
2
[PATCH] x86/Intel: don't probe CPUID faulting on family 0xf CPUs
These are known to not support the feature, so we can save ourselves
from emitting the resulting #GP fault recovery related message (which
might worry people looking at the logs).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -204,7 +204,7 @@ static void __devinit init_intel(struct
detect_ht(c);
}
- if
2013 Aug 29
7
[PATCH 0/3] x86: mwait_idle improvements ported from Linux
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>
2012 Oct 02
3
[PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
During debugging of another problem I found that in x2APIC mode, the
destination field of the low address value wasn''t passed back
correctly. While this is benign in most cases (as the value isn''t being
used anywhere), it can be confusing (and misguiding) when printing the
value read or when comparing it to the one previously passed into the
inverse function.
Signed-off-by: Jan
2012 Mar 01
7
Xen support for native EFI boot
Can someone provide instructions and the necessary environment/toolchain support needed to get Xen to build and boot on a native EFI system (i.e. with no CSM/legacy support)?
Joe
2008 Nov 20
10
issues with movnti emulation
We''ve got reports of that change causing HVM data corruption issues. While
I can''t see what''s wrong with the patch, I''d suggest at least reverting it from
the 3.3 tree (which is what our code is based upon) for the time being.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
2013 Aug 28
7
[PATCH] x86/apic: remove DMI checks in bigsmp driver for obsolete systems
The DMI checks that force the use of the bigsmp APIC driver are for
systems that are no longer supported by Xen (32-bit x86).
Signed-off-by: Matt Wilson <msw@amazon.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
---
xen/arch/x86/genapic/bigsmp.c | 30 +-----------------------------
1 files changed, 1
2008 Sep 19
8
[PATCH] x86: add hypercall to query current underlying pCPU''s frequency
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Index: 2008-09-19/xen/arch/x86/platform_hypercall.c
===================================================================
--- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200
+++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200
@@ -21,7 +21,7 @@
#include <xen/acpi.h>
2012 Jun 28
4
[xen-unstable test] 13383: regressions - FAIL
flight 13383 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 16 guest-start fail REGR. vs. 13379
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12
2012 Jun 27
1
[PATCH] x86/hvm: increase struct hvm_vcpu_io's mmio_large_read
Since the emulator now supports a few 256-bit memory operations, this
array needs to follow (and the comments should, too).
To limit growth, re-order the mmio_large_write_* fields so that the
two mmio_large_*_bytes fields end up adjacent to each other.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -59,13 +59,13
2009 Jan 26
24
page ref/type count overflows
With pretty trivial user mode programs being able to crash the kernel due to
the ref counter widths in Xen being more narrow than in Linux, I started an
attempt to put together a kernel side fix. While addressing the plain
hypercalls is pretty strait forward, dealing with multicalls (both when using
them for lazy mmu mode batching and when explicitly using them in e.g.
netback - the backends are