similar to: passthroughed msix device

Hi All, When tried to pass through 2 mpt2sas HBA to hvm guest, hvmloader paused with below: MPT BIOS Fault 09h encountered at adapter PCI(00h,04h,00h) Press any key to continue... Checked related codes and mostly like it caused by rombios did not loaded MPT BIOS properly, and lead MPT BIOS failed to bootup. config-file of the guest as below: ---------------------------------- # cat vm.cfg

Hi- I am trying to pass an LSI SAS2008-based HBA (IBM M1015) through to an HVM Solaris VM, using Xen 4.2 unstable and the qemu-traditional device model. On boot I see the following error: MPT BIOS Fault 09h encountered at adapter PCI(00h,05h,00h) A list search yielded (http://comments.gmane.org/gmane.comp.emulators.xen.devel/128172), however there was no solution for an HVM VM. I''ve

ioemu-remote: Enable pci pass-through by default. -- Jean Guyader _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Several of these messages we coded using line continuation within a string literal. This is generally not recommended and also lead to odd sequences of many blanks in the middle of the messages. The message indicating a discarded write due to MSI-X already being enabled doesn''t need to be issued when a write doesn''t actually modify the current value. Adjust the surrounding logic

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

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

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. Also need consider the rare case when xen_do_chunk fail(populate). For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff is: [ 0.000000] Freeing

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. Also need consider the rare case when xen_do_chunk fail(populate). For a dom0 booted with dom_mem=3368952K(0xcd9ff000-4k) dmesg diff is: [ 0.000000] Freeing

`memset(&mc_ext, 0, ...)'' leads to a buffer overflow and a subsequent null pointer dereference. Replace `&mc_ext'' with `mc_ext''. Signed-off-by: Xi Wang <xi@mit.edu> --- xen/arch/x86/cpu/mcheck/mce_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c index

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

Hi All, Here is the test report for Xen-4.0.0-rc6(Xen C/S 21022). Our testing covers following features, like VT-x/VT-x2, VT-d, SR-IOV, Power Management, RAS, and TXT. There are 2 new RAS bugs exposed in this testing compared with RC5 testing. 2 bugs are fixed. VT-d/SR-IOV and TXT can work without major bug. Most bugs are in RAS side. Dom0 S3 cannot work on Gulftown-HEDT platform. We use latest

Hi, we still have our solid rock dovecot 1.0.7 Redhat el 5.x up and running. We don't need much magic or special setups. However we'd like to think what might be the next step in upgrading our setup. Each user one mbox mailbox. About 500 imap/pop3 accounts, 400GB data. First of all: to what version is a good step from 1.0? Can we get a rpm from e.g. atrpms repository? Dose anyone has

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.

Hi all, This is our bi-weekly test report for Xen-unstable tree. There are 6 new bug found in this two weeks. And there are 3 bugs had fixed in past two weeks. We use Pv_ops(xen/stable-2.6.32.x) as Dom0 in our testing. Status Summary ==================================================================== Feature Result

[This email is either empty or too large to be displayed at this time]

This is a first go at adding support for the modern (based on the 1.0 virtio spec) virtio-pci implementation. kvmtool makes it simple to add additional transports such as this because of it's layering, so we are able to add it as a 3rd (after legacy virtio-pci and virtio-mmio) transport layer, and still allow users to choose to use either the legacy or the modern implementations (but setting

This is a first go at adding support for the modern (based on the 1.0 virtio spec) virtio-pci implementation. kvmtool makes it simple to add additional transports such as this because of it's layering, so we are able to add it as a 3rd (after legacy virtio-pci and virtio-mmio) transport layer, and still allow users to choose to use either the legacy or the modern implementations (but setting

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use