similar to: [PATCH] qemu-traditional - ACPI vCPU hotplug fixes for Xen 4.3 (v2).

Hey Ian and Stefano, Please see this thread: http://lists.xen.org/archives/html/xen-devel/2013-05/msg01053.html for the debug patches and some of the discussion. These three patches fix an race that has been in QEMU traditional for a long time. The guts of the bug is that if you have a guest with these options: vcpus=1 maxvcpus=32 and do ''xl vcpu-set <guest> 32'' the

When hotplug hvm vcpu by ''xm vcpu-set'' command, if it add/remove many vcpus by 1 ''xm vcpu-set'' command, it has a bug that it cannot add/remove all vcpus that want to be added/removed. This patch is to fix the bug. It delays trigger sci until all xenstore cpu node status are watched. Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Aiming at a release some time in August, I''d like to cut RC1-s by Thursday next week (as I''ll be on a two week vacation starting Friday). Please indicate any bug fixes that so far may have been missed in the backports already done. A few fixes are currently stuck in master''s staging branch (or pending to make it there) - these don''t need to be named explicitly,

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very

Attached please see the hvm guest os acpi patch part 2 of 4:piix4acpi_timer ACPI timer is required during guest windows installation and boot. Signed-off-by: Tang Liang <tangliang@lenovo.com> Signed-off-by: Winston Wang <winston.l.wang@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch series makes suspend support in qemu alot more useful. Right now the guest can put itself into s3, but qemu will wakeup the guest instantly. With this patch series applied the guest will stay suspended instead and there are a few events which can kick the guest out of suspend state: A monitor command, ps/2 input, serial input, rtc. Not much yet, but it''s a start with the

Has there been any work done on getting an ACPI fixed event or perhaps a general purpose event delivered to an HVM guest. Whereby, the HVM guests OSPM could consume the event and act accordingly. Or Perhaps better stated how would one go about passing an ACPI fixed event or general purpose event that was raised and consumed by dom0 and subsequently pass the event on to each of the HVM

resend. didn''t see it show up on the list. Sorry if duplicate. > >>Has there been any work done on getting an ACPI fixed event or >>perhaps a general >>purpose event delivered to an HVM guest. Whereby, the HVM >>guests OSPM could consume the event and act accordingly. > > Now Xen support live migration with VT- d assigned device, which > is

Source: xen Version: 4.1.4-4 Severity: serious Tags: jessie sid User: debian-qa at lists.debian.org Usertags: qa-ftbfs-20130509 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: > gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value

When I submitted the qcow2 patch for blktap, suggestions came up that the qemu block drivers should be used also for blktap to eliminate the current code duplication in ioemu and blktap. The attached patch adds support for a tap:ioemu pseudo driver. Devices using this driver won''t use tapdisk (containing the code duplication) any more, but will connect to the qemu-dm of the domain. In

The following series of 10 patches is a merge of the xenfb and xenconsoled functionality into the qemu-dm code. The general approach taken is to have qemu-dm provide two machine types - one for xen paravirt, the other for fullyvirt. For compatability the later is the default. The goals overall are to kill LibVNCServer, remove alot of code duplication and/or parallel impls of the same concepts, and

I just built 4.3.0 in order to get > 2GB of RAM in domU with GPU passthrough without crashes. Unfortunately, the same crashes still happen. Massive frame buffer corruption on domU before it locks up solid. It seems the PCI memory stomp is still happening. I am using qemu-dm, as I did on Xen 4.2.x. So whatever fix for this went into 4.3.0 didn''t fix it for me. Passing less than 2GB