similar to: [Xen-devel] [ANNOUNCE] Xen 4.2 released!

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

----- Forwarded message from Keir Fraser <keir.xen at gmail.com> ----- From: Keir Fraser <keir.xen at gmail.com> To: "xen-devel at lists.xensource.com" <xen-devel at lists.xensource.com>, xen-users at lists.xensource.com Cc: Date: Fri, 25 Mar 2011 15:11:53 +0000 Subject: [Xen-devel] [ANNOUNCE] Xen 4.1 released! The Xen team is pleased to announce the release of Xen

I encountered same error when use Xen3.0.2(source file) on CentOS4.2, after I downgraded to Xen2.0.7(source file), this error disappeared. now, I am using Xen2.0.7 instead of 3.0.2, it works well. --taylor -----邮件原件----- 发件人: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] 代表 xen-users-request@lists.xensource.com 发送时间: 2006年6月15日 5:24 收件人:

flight 13798 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13798/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 13739 test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 13739 Regressions which are regarded as

flight 6714 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/6714/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-oldkern 4 xen-build fail REGR. vs. 6658 build-amd64 4 xen-build fail REGR. vs. 6658 build-i386-oldkern 4 xen-build fail REGR. vs. 6658

F.Y.I >>> "Tian, Kevin" <kevin.tian@intel.com> 08.11.27. 11:50 >>>Sorry for a typo. I did mean domU instead of dom0. :-) The point here is that time_resume will sync to new system time and wall clock at restore, and thus pv guest should be able to continue... Xen system time is not wallclock time which just counts up from power up. As Keir points out, only its

It is rc2-pre. Stubdom fails again.   Boris --- On Fri, 4/10/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] First release candidate for Xen 3.4.0 To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir Fraser" <keir.fraser@eu.citrix.com> Date: Friday, April

flight 12043 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12043/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12031 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12031 test-amd64-i386-xl-winxpsp3-vcpus1 7

This patch adds a check to see if v_end in setup_guest() wraps around to 0 and lets the builder exit gracefully when it does. Signed-off-by: Aravindh Puthiyaparambil <aravindh.puthiyaparambil@unisys.com> > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Thursday, June 01, 2006 6:14 AM > To: Puthiyaparambil, Aravindh > Cc:

Any thoughts on setting breakpoints around hypercalls? ---------- Forwarded message ---------- From: Kip Macy <kip.macy@gmail.com> Date: Dec 26, 2005 12:14 AM Subject: setting breakpoints around hypercalls in a domU causes dom0 to lockup To: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser < Keir.Fraser@cl.cam.ac.uk> Stepping through hypercalls (at the source level, not

Hi maintainer, I found below patch reverted part of erst header size check. This lead to mismatch with kernel upstream code and erst disabled on some machine like X4170 M3/X3-2. According to the ACPI spec 4.0 and 5.0, the Serialization Header Length should be the length of Serialization Header. After revert below patch, xen succeed with erst table init. So could this patch be reverted now to match

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2006年5月22日 17:51 >To: Keir Fraser > >>> We just need to reverse the whole change for ia64, since both >domU >>> and domVTI are insert a hole by this auto-balloon patch. Due to >>> missing balloon support on xen/ia64 as you said, both domU and >domVTI >>> failed due to this change.

Setting CONFIG_CMDLINE_BOOL=y in .config allows to assign desired value via make menuconfig: Symbol: CMDLINE [=root=/dev/sda14 ro console=tty0]                                                       Prompt: Built-in kernel command string                                                                       Defined at

flight 8270 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8270/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 8256 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken test-amd64-amd64-win 3 host-install(3) broken test-amd64-i386-pv

If the domain''s NUMA node-affinity is being specified by the user/toolstack (instead of being automatically computed by Xen), we really should stick to that. This means domain_update_node_affinity() is wrong when it filters out some stuff from there even in "!auto" mode. This commit fixes that. Of course, this does not mean node-affinity is always honoured (e.g., a vcpu

flight 5665 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/5665/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-oldkern 4 xen-build fail REGR. vs. 5640 build-amd64 4 xen-build fail REGR. vs. 5640 build-i386-oldkern 4 xen-build fail REGR. vs. 5640

>From: Keir Fraser >Sent: 2006年9月11日 9:19 >Would it be cleaner to allow dom0 to have really direct access to some >I/O >ports by allowing it to set a real I/O bitmap? I implemented I/O bitmaps >via >emulation mainly because it makes context switching faster and it is less >of >a pain to keep admin and guest bitmasks in sync if they are checked >synchronously. But a

flight 13925 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/13925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 9 guest-start.2 fail REGR. vs. 13922 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail

flight 12413 xen-4.0-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12413/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 4 xen-build fail REGR. vs. 12202 build-amd64-pvops 4 kernel-build fail REGR. vs. 12202 build-amd64-oldkern 4

There's a couple of patches in 4.1 which might plausibly be the fix for this. changeset: 23246:8f927378135a user: Jan Beulich <jbeulich at suse.com> date: Wed Mar 07 08:35:58 2012 +0000 files: xen/arch/ia64/xen/domain.c xen/arch/x86/domain.c xen/arch/x86/domctl.c description: passthrough: release assigned PCI devices