similar to: Xen 4.3 development update

This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 Our timeline had us start the code freeze last Friday. However, we have not released an RC0 because we have been waiting for PVH dom0 support. Adding bug fixes during RCs makes sense, but RC0 should contain all of the functionality we expect to be in the final release. PVH dom0 support

This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 We''re nearly to the completion of the code freeze, scheduled for tomorrow. After the code freeze, only bug fixes and features marked as "blockers" will be considered. At the moment, the only feature considered a blocker is experimental PVH dom0 support. In early RCs,

Another bundle of issues from Coverity triage. The first one is in x86/mm, and looks scarier than it is. The others are all in xen/drivers and AFAICT are pretty minor. Cheers, Tim.

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> This patch add an additional logic to check for the often case when the special->handle is not initialized due to firmware bugs. but the special->usedid is correct. If users overide this using the command line option ivrs_ioapic, then it should use the value instead. --- This patch is supposed to follow the patches:

My system reboots when I trying to start any HVM domU. This problem was described earlier: http://lists.xen.org/archives/html/xen-devel/2013-08/msg01395.html My system is openSUSE 13.1 RC2 with Xen 4.3.0 My hardware is ASRock FM2A75 Pro4 AMD A8-6600K APU Gigabyte Radeon 7850 8 Gb DDR3 1600Mhz I have setup serial console and could provide logs your requested. Attached logs from xl dmesg,

Did something had chaqnged with spice code or settings. I just compiled latest git of 4.4 unstable and I get is a black screen all I see is the green boot image from server 2012 but I dont get blue windows logo and window does not resize it stays black. I reverted back to older git revision of 4.4 and everything is working fine with. _______________________________________________ Xen-users

Hi,all I have tried to passthrough GPU card(Nvidia quadro 4000) on the latest Xen unstable version (QEMU is using Qemu-upsteam-unstable, not traditional Qemu). This issue as below: Windows7 64-bit guest will blue screen when GPU passthrough configure 4g memory,blue screen code is 50, and SUSE 11 64-bit guest will always stay at the grub screen. I noticed that it will relocate RAM that

This is a patch to forward-port a Xend behaviour. Xend writes IO ABI used for all frontends. Blkfront before 2.6.26 relies on this behaviour otherwise guest cannot boot when running in 32-on-64 mode. Blkfront after 2.6.26 writes that node itself, in which case it''s just an overwrite to an existing node which should be OK. In fact Xend writes the ABI for all frontends including console

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

This small series reintroduces OVMF support in Xen You can fetch working OVMF tree on: git://xenbits.xen.org/people/liuw/ovmf.git master Working changeset that can be sticked in Config.mk is: 8833370303d3bf3153760ee42760ef1b9b5c562 Note that VNC doesn''t work properly when using OVMF, but that''s not OVMF''s problem. This issue should be addressed in Xen and I''m

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'',

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> This patch handle additional cases for IVRS bugs where special->handle is not correctly initialized for IOAPIC and HPETS due to firmware bugs. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Provide logic in "is_ioapic_overidden()" Signed-off-by: Jan Beulich <JBeulich@suse.com> ---

Hi all, this is the tenth version of the patch series to introduce upstream qemu and seabios in the xen-unstable build system. Changes to v9: - rename QEMU_UPSTREAM_TAG to QEMU_UPSTREAM_REVISION: we are going to use it with a branch name by default; - set QEMU_UPSTREAM_REVISION to "master" by default; - set SEABIOS_UPSTREAM_URL to git://xenbits.xen.org/seabios.git by default; - add

We created a 64bit SLES11 SP1 guest, and then used a script to change memory (using mem-set command) periodically (in 1 second): set 1G, set 2G, set 1G, set 2G, and so on. After a few minutes, we encountered QEMU exit due to SIGBUS error. Below is the call trace captured by gdb: The call trace: Program received signal SIGBUS, Bus error. 0x00007f94f74773d7 in memcpy () from /lib64/libc.so.6 (gdb)

The hypervisor side changes for XSA-46 require the tool stack to now always map the guest pIRQ before granting access permission to the underlying host IRQ (GSI). This in particular requires that pciif.py no longer can skip this step (assuming qemu would do it) for HVM guests. This in turn exposes, however, an inconsistency between xend and qemu: The former wants to always establish 1:1 mappings

$ git checkout RELEASE-4.2.2 $ git clean -ffdx [do a build, install, reboot] $ xl create a0 $ xl cd-eject a0 hdc [However, the guest OS still sees the CD inserted] $ xl block-list a0 Segmentation fault $ xl cd-insert a0 hdc file:/images/xs-tools-6.0.0.iso Segmentation fault The problem seems to be that xl cd-eject is writing corrupt values to xenstore. Note that vbd/1/5632 is still there

Hello everyone! With the completion of our first few release candidates for 4.2, it''s time to look forward and start planning for the 4.3 release. I''ve volunteered to step up and help coordinate the release for this cycle. The 4.2 release cycle this time has been nearly a year and a half. One of the problems with having such a long release is that people who get in features

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

From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001 From: Liu Jinsong <jinsong.liu@intel.com> Date: Tue, 26 Nov 2013 04:53:17 +0800 Subject: [PATCH] VMX: wbinvd when vmentry under UC This patch flush cache when vmentry back to UC guest, to prevent cache polluted by hypervisor access guest memory during UC mode. However, wbinvd is a _very_ time consuming operation, so 1.

I installed CentOS6 with the xen4centos set of packages; then I tried to install KVM (for performance comparison), I got the following error in YUM: --> Processing Dependency: /usr/share/gpxe/e1000-0x100e.rom for package: 2:qemu-kvm-0.12.1.2-2.415.el6_5.4.x86_64 Package gpxe-roms-qemu is obsoleted by ipxe-roms-qemu, but obsoleting package does not provide for requirements I manually