Displaying 20 results from an estimated 10000 matches similar to: "page ref/type count overflows"
2013 Nov 14
4
[PATCH] xen/arm: Allow balooning working with 1:1 memory mapping
With the lake of iommu, dom0 must have a 1:1 memory mapping for all
these guest physical address. When the ballon decides to give back a
page to the kernel, this page must have the same address as previously.
Otherwise, we will loose the 1:1 mapping and will break DMA-capable
device.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich
2013 Dec 04
5
[PATCH] coverity: Store the modelling file in the source tree.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
misc/coverity_model.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
2006 Aug 31
5
x86-64''s paging_init()
While adding code to create the compatibility p2m table mappings it seemed
to me that the creation of the native ones is restricted to memory below
the 512G boundary - otherwise, additional L2 tables would need to be
allocated (currently other memory following the one L2 page getting
allocated would be blindly overwritten). While I realize that machines this
big aren''t likely to be
2012 Oct 11
14
alloc_heap_pages is low efficient with more CPUs
I am confused with a problem:
I have a blade with 64 physical CPUs and 64G physical RAM, and defined only one VM with 1 CPU and 40G RAM.
For the first time I started the VM, it just took 3s, But for the second starting it took 30s.
After studied it by printing log, I have located a place in the hypervisor where cost too much time,
occupied 98% of the whole starting time.
xen/common/page_alloc.c
2011 Jan 17
8
[PATCH 0 of 3] Miscellaneous populate-on-demand bugs
This patch series includes a series of bugs related to p2m, ept, and
PoD code which were found as part of our XenServer product testing.
Each of these fixes actual bugs, and the 3.4-based version of the patch
has been tested thoroughly. (There may be bugs in porting the patches,
but most of them are simple enough as to make it unlikely.)
Each patch is conceptually independent, so they can each
2013 Jun 11
8
[PATCH v2] xen: fix initialization of wallclock time for PVHVM on migration
Call update_domain_wallclock_time on hvm_latch_shinfo_size even if
the bitness of the guest has already been set, this fixes the problem
with the wallclock not being set for PVHVM guests on resume from
migration.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: George Dunlap
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
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
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
2013 Oct 17
5
[PATCH] common/initcall: Extern linker symbols with correct types.
Coverity IDs 1054956, 1054957
Coverity pointed out that we applying array operations based on an expression
which yielded singleton pointers. The problem is actually that the externs
were typed incorrectly.
Correct the extern declaration to prevent straying into undefined behaviour,
and relying on the lenience of GCC to work.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC:
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
2012 Feb 06
1
[PATCH] ia64: fix build (next instance)
A number of build problems crept in once again. Fix them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -683,7 +683,7 @@ long do_memory_op(unsigned long cmd, XEN
mfn = get_gfn_untyped(d, xrfp.gpfn);
if ( mfn_valid(mfn) )
- guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+
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>
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 Aug 09
14
[Patch 0/4] Xen stack trace printing improvements
This series consists of improvements to Xen''s ability to print traces of its
own stack, and specifically for the stack overflow case to be able to use
frame pointers in a debug build.
I have dev tested the series in debug and non-debug cases, with and without
memory guards, and I believe that all the stack traces look correct. However,
I would greatly appreciate a second opinion on the
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 Jul 10
2
[PATCH] x86/HVM: key handler registration functions can be __init
This applies to both SVM and VMX.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -310,7 +310,7 @@ static struct keyhandler vmcb_dump_keyha
.desc = "dump AMD-V VMCBs"
};
-void setup_vmcb_dump(void)
+void __init setup_vmcb_dump(void)
{
register_keyhandler(''v'',
2013 Aug 29
3
[PATCH 0/2] Fix SMBios table regressions in HVM guests
The series "HVM firmware passthrough" series in Jan 2013 from Ross Philipson
cause two regressions for HVM guests which sadly found their way into the Xen
4.3 release.
The first regression causes an incorrect count of tables to be placed in the
main header, and can be seen by running dmidecode in any applicable HVM domain.
The second regression found its way into the public ABI, making
2007 May 30
3
linux'' X86_MSR config option
.. is out of sync on i386 and x86-64 - should it be allowed on i386, or should
it be suppressed on x86-64? Since Xen fails ill accesses, I would assume
enabling it on i386 is fine.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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