similar to: Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs.

Whether the processor is in 32 or 64-bit mode, if NX is used, then EFER_NX needs to be set. If NX isn''t used, then it''s a "Don''t care". I think bad things happens if you set the NX bit in the page table and don''t have EFER_NX set... -- Mats > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com >

I have always needed the rm_nx_xd patch to boot Xen / Dom0 on the ES7000 x86_64 but the system boots without any issues on plain vanilla Linux 2.6. > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel- > bounces@lists.xensource.com] On Behalf Of Keir Fraser > Sent: Thursday, August 18, 2005 4:49 AM > To: Nakajima, Jun > Cc: Jerone Young;

On Tuesday 02 August 2005 10:42, Xen patchbot -unstable wrote: > # HG changeset patch > # User smh22@firebug.cl.cam.ac.uk > # Node ID 59e76450e286240decceda23eca343ec4604124f > # Parent 48dea637aac96bcbabe788d036b52570520cc82e > Fixes. Sorry, but could we not make checkin comments like "Fixes."? It would just take a few more seconds to describe it in a complete

On Fri, 2005-10-21 at 18:54 +0000, Xen patchbot -unstable wrote: > # HG changeset patch > # User kaf24@firebug.cl.cam.ac.uk > # Node ID 8eaaa622db81393ef0eae497090c34c04adf4212 > # Parent 3eee5653f08b01a310e0a9172a6c0149f16217df > Tweak to pygrub build config detection. > Signed-off-by: Jeremy Katz <katzj@redhat.com> Applying both patches for this is overkill.... ;)

On Tue, 2005-10-11 at 14:32 +0000, Xen patchbot -unstable wrote: > +def path(): > + machine = os.uname()[4] > + if machine.find(''64'') != -1 and os.path.exists(LIB_BIN_64): > + return LIB_BIN_64 > + else: > + return LIB_BIN_32 This will break on ia64. Itanium doesn''t use lib64 paths. So you really want to check against explicit

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list

This change has the effect of adding some complexity to the callback routines. The original callback passed an opaque argument which was a private item for the use of the controlling mechanism and its callback function. This change removes this and specifies only an fd. While it''s possible for the controlling mechanism to use the fd as an index to find internal data structures, this is

Looks like the subarch tree has been checked in. Does this mean 3.0.1 has been pushed out to include more? Or do we release 3.0.1 once the new tree is fully tested? Jun --- Intel Open Source Technology Center ---- From: xen-changelog-bounces@lists.xensource.com [mailto:xen-changelog-bounces@lists.xensource.com] On Behalf Of Xen patchbot -unstable Sent: Monday, January 30, 2006 4:08 PM To:

On Fri, 2006-07-28 at 16:20 +0000, Xen patchbot-unstable wrote: > diff -r dc26ac2f7718 -r dab0a5650e6d tools/libxc/Makefile > --- a/tools/libxc/Makefile Mon Jul 10 14:14:11 2006 -0600 > +++ b/tools/libxc/Makefile Tue Jul 11 11:29:25 2006 -0600 > @@ -30,9 +30,11 @@ GUEST_SRCS-y += xc_load_bin.c > GUEST_SRCS-y += xc_load_bin.c > GUEST_SRCS-y += xc_load_elf.c >

On Wed, Jan 25, 2006 at 03:12:08PM +0000, Xen patchbot -unstable wrote: > # HG changeset patch > # User kaf24@firebug.cl.cam.ac.uk > # Node ID 709bce2f08d6024c2efb2938e564915da1ca51f2 > # Parent aad2b2da3c8beda24bc62ca6e92b28c28def0849 > Export Xen driver util function symbols so that Xen drivers > can build as modules. > > Signed-off-by: Keir Fraser

I assume this commit message was supposed to be "Enable VGA acceleration for VTI" right? We''re not actually accelerating CGA right? Regards, Anthony Liguori Xen patchbot-unstable wrote: > # HG changeset patch > # User kaf24@firebug.cl.cam.ac.uk > # Node ID e67432187b88ee60433779ad0f004b532ed378c8 > # Parent 639ad22eb7c80ac21c3958747b879892680bdaba >

Xen patchbot -unstable wrote: > # HG changeset patch > # User emellor@leeni.uk.xensource.com > # Node ID da24df1ea484cf72dc9d367d52e828777e0e20cd > # Parent c1bb4eb565296bdb00aed84fcc877befbcebd8e9 > Improve error handling, in particular fixing the ProtocolError that is thrown > when a domain is specified by the user that does not exist. Added a few > error codes -- many

FYI, I see the following build error with this patch... MRJ ---- new warnings/errors for xen ---- keyhandler.c: In function `__dump_execstate'': keyhandler.c:96: warning: asm operand 1 probably doesn''t match constraints gmake[5]: *** [keyhandler.o] Error 1 gmake[4]: *** [/tank/ws/xvm-3.4.3/xen.hg/xen/common/built_in.o] Error 2 gmake[3]: *** [/tank/ws/xvm-3.4.3/xen.hg/xen/xen]

Hi, Looks like this patch broke automated builds due to a lack of a matching line in the defconfigs. Below is a patch that makes this a module for xen and xen0, unconfigured for xenU. That might not be the best thing here however. Thanks kurt Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com> ===================================================== diff -r cd744c5ec950

On Fri, Dec 07, 2007 at 04:30:09PM -0800, Xen patchbot-unstable wrote: > tools: Rationalise library soname versions. > > * Arrange for the sonames of libxenstore, libxc, libfsimage and > libblktap to be set from a single place in Config.mk. Grumble... I don''t like this at all. You just bumped libfsimage for no reason. Can we please fix libfsimage back to the correct

Hi, I'm not sure this is a bug in the code, the comment or my thinking. So first try goes to r-devel... I find the following comment in X11_Open () (src/unix/X11/devX11.c): /* if we have to bail out with "error", then must free(dd) and free(xd) */ A couple lines down, there is: if (!strncmp(dsp, "png::", 5)) { FILE *fp; #ifndef HAVE_PNG error("No png support

Remove visibility of the FFXSR CPUID bit to an HVM guest. This patch allows HVM Windows x64 to install/boot on AMD-V platforms. This patches applies cleanly to xen-unstable 13743. Please apply to xen-unstable/3.0.5. If possible, pls apply to xen-3.0.4-testing. --Tom thomas.woller@amd.com AMD Corporation 5204 E. Ben White Blvd. UBC1 Austin, Texas 78741 +1-512-602-0059

From: Joerg Roedel <jroedel at suse.de> The #VC exception will trigger very early in head_64.S, when the first CPUID instruction is executed. When secondary CPUs boot, they already load the real system IDT, which has the #VC handler configured to be using an IST stack. IST stacks require a TSS to be loaded, to set up the TSS early for bringing up the secondary CPUs. Use the RW version of

Now that the feature is officially documented (see http://support.amd.com/us/Processor_TechDocs/24593.pdf), I think it makes sense to also allow HVM guests to make use of it. Signed-off-by: Jan Beulich <jbeulich@novell.com> Cc: Andre Przywara <andre.przywara@amd.com> --- 2010-05-04.orig/xen/arch/x86/hvm/hvm.c 2010-04-22 14:43:25.000000000 +0200 +++ 2010-05-04/xen/arch/x86/hvm/hvm.c

(Applies cleanly only on top of the previously sent SVM/LBR patch.) Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/hvm/svm/svm.c =================================================================== --- 2007-08-08.orig/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:40:11.000000000 +0200 +++ 2007-08-08/xen/arch/x86/hvm/svm/svm.c 2007-08-08 11:43:53.000000000 +0200