similar to: [PATCH] xen: populate correct number of pages when across mem boundary

When populate pages across a mem boundary at bootup, the page count populated isn't correct. This is due to mem populated to non-mem region and ignored. Pfn range is also wrongly aligned when mem boundary isn't page aligned. -v2: If xen_do_chunk fail(populate), abort this chunk and any others. Suggested by David, thanks. For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff

When populate pages across a mem boundary at bootup, the page count populated isn't correct. This is due to mem populated to non-mem region and ignored. Pfn range is also wrongly aligned when mem boundary isn't page aligned. -v2: If xen_do_chunk fail(populate), abort this chunk and any others. Suggested by David, thanks. For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff

Accelerated msix entry is initialized to zero when msixtbl_pt_register is called. This doesn''t match the value from qemu side, although pirq may already be mapped and binded in qemu side. Kernel will get wrong value when reading msix info. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Tested-by: Yuval Shaia <yuval.shaia@oracle.com> --- tools/libxc/xc_domain.c

Driver init call graph under baremetal: driver_init-> msix_capability_init-> msix_program_entries-> msix_mask_irq-> entry->masked = 1 request_irq-> __setup_irq-> irq_startup-> unmask_msi_irq-> msix_mask_irq-> entry->masked = 0 So

Hi maintainer, Reprodue an bug on xen-unstable, it''s an irq affinity issue for passthroughed msix device to uek1 pvhvm(2.6.32 stable). I passthrough two mptsas devices(0000:0d:0.0, 0000:1f:0.0) to a pvhvm, irq affinity can''t be changed. Step to reproduce is as below: 1. xl -f pci-assignable-add 0000:0d:0.0; xl -f pci-assignable-add 0000:1f:0.0 2.xm cr -c vm.cfg

On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote: > add polling interface to xen-netfront device to support netconsole > Ian, any thoughts on the spinlock changes? > Signed-off-by: Tina.Yang <tina.yang@oracle.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Cc: Jeremy Fitzhardinge <jeremy@goop.org> > Signed-off-by: Zhenzhong.Duan

Hi, we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel crash. The hypervisor does not matter, I tried 4.1.3-rc2 as well as various unstable versions including 25467, also 32-bit versions of 4.1. The Dom0 kernels were always PVOPS versions, the problems starts with 3.2-rc1~194 and is still in 3.5.0-rc3.

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 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.