similar to: [PATCH][QEMU] Add IA64-specific code for new qemu.

Akio, Thank you for pointing out this issue. Maybe I sent out the older one incorrectly.:( Thanks again. -Xiantao OTC,Intel Corporation > -----Original Message----- > From: Akio Takebe [mailto:takebe_akio@jp.fujitsu.com] > Sent: 2006年7月26日 19:24 > To: Zhang, Xiantao; xen-devel@lists.xensource.com > Cc: xen-ia64-devel@lists.xensource.com > Subject: Re: [Xen-ia64-devel]

This patch adds lost logic for vga initialization. It was lost after changing to new Qemu. Signed-off-by : Kevin Tian <kevin.tian@intel.com> Signed-off-by : Zhang Xiantao <xiantao.zhang@intel.com> Thanks & Best Regards -Xiantao OTC,Intel Corporation _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

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

From: Zhang Xiantao <xiantao.zhang@intel.com> With virtual EPT support, L1 hyerpvisor can use EPT hardware for L2 guest''s memory virtualization. In this way, L2 guest''s performance can be improved sharply. According to our testing, some benchmarks can show > 5x performance gain. Signed-off-by: Zhang Xiantao <xiantao.zhang@intel.com> Zhang Xiantao (11):

Zhang, Xiantao wrote: > Hi Folks, > We are working on enabling KVM support on IA64 platform, and now > Linux, Windows guests get stable run and achieve reasonable performance > on KVM with Open GFW. But you know, the current KVM only considers x86 > platform, and is short of cross-architecture framework. Currently, we > have a proposal for KVM source layout to accommodate new

Zhang, Xiantao wrote: > Hi Folks, > We are working on enabling KVM support on IA64 platform, and now > Linux, Windows guests get stable run and achieve reasonable performance > on KVM with Open GFW. But you know, the current KVM only considers x86 > platform, and is short of cross-architecture framework. Currently, we > have a proposal for KVM source layout to accommodate new

Zhang, Xiantao wrote: >>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:49:57 +0800 > Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for > kvm/ia64. > > kvm_ia64.c is created to handle kvm ia64-specific core logic. > Signed-off-by: Xiantao Zhang

Zhang, Xiantao wrote: >>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Fri, 28 Mar 2008 09:49:57 +0800 > Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for > kvm/ia64. > > kvm_ia64.c is created to handle kvm ia64-specific core logic. > Signed-off-by: Xiantao Zhang

Due to IA64 balloon driver not ready and it depends on max memory value to allocate its memory. So this fix is necessary now. Thanks & Best Regards -Xiantao OTC,Intel Corporation _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

... instead of open coding it. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct return; } - memset(&msg, 0, sizeof(msg)); - msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff; - msg.data |= 1 << 14; -

This series of patches fix the mistake for debug exception(#DB), overflow exception(#OF) and INT3(#BP), INTn instruction emulation. Introduce new function vmx_inject_sw_exception() which deliver the software excetion, software interrupt and privileged software exception. Split hardware exception as a seperate function(old function vmx_inject_hw_exception()). Also Passed down intruction length

I am adding interrupt support for LWP, whose spec is available at http://support.amd.com/us/Processor_TechDocs/43724.pdf. Basically OS can specify an interrupt vector in LWP_CFG MSR; the interrupt will be triggered when event buffer overflows. For HVM guests, I want to re-inject this interrupt back into the guest VM. Here is one idea similar to virtualized PMU: It first registers a special

Hi Xiantao, I general I think the code in this patch is fine. I have a couple of nit-picking comments: > + if (target_mask&0x1) { The formatting here isn't quite what most of the kernel does. It would be better if you added spaces so it's a little easier to read, ie: if (target_mask & 0x1) { > + p = &__per_cpu_idtrs[cpu][0][0]; > + for (i = IA64_TR_ALLOC_BASE;

Hi Xiantao, I general I think the code in this patch is fine. I have a couple of nit-picking comments: > + if (target_mask&0x1) { The formatting here isn't quite what most of the kernel does. It would be better if you added spaces so it's a little easier to read, ie: if (target_mask & 0x1) { > + p = &__per_cpu_idtrs[cpu][0][0]; > + for (i = IA64_TR_ALLOC_BASE;

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,

Hi, I found latest pv_ops dom0, commit 3dd81018a392941fcc722ee521de344527481eb8, fails to boot with call trace. And commit 34ffcd2bde0018cf78d5b4f1f5427c38a3e9b502 has no such issue. Could anyone help on this issue? Call trace messages: ####### Mounting proc filesystem Mounting sysfs filesystem Creating /dev [ 0.860962] init[1]: segfault at ffffffff8104f1e8 ip ffffffff8104f1e8 sp

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

Currently it is assumed PCI device BAR access < 4G memory. If there is such a device whose BAR size is larger than 4G, it must access > 4G memory address. This patch enable the 64bits big BAR support on hvmloader. v3 changes from v2: - Remain original print information v2 changes from v1 as comments by Jan. 1) Set Dynamic MMIO high memory address instead of a fixed number 640G 2) Mask

vtd: Fix for irq bind failure after PCI attaching 32 times Originally when detaching a PCI device, pirq_to_emuirq and pirq_to_irq are freed via hypercall do_physdev_op. Now in function pt_irq_destroy_bind_vtd, duplicated logic is added to free pirq_to_emuirq, but not pirq_to_irq. This causes do_physdev_op fail to free both emuirq and irq. After attaching a PCI device for 32 times, irq resources

patch revision history ---------------------- v1: Initial patch to handle this issue involving changing the hypercall interface v2:Totally handled inside hypervisor. v3:Change some logics of handling msi-x pending unmask operations. v4:Some changes related to coding style according to Andrew Cooper''s comments From 51c5b7f1f9c8f319da8adf021b39e18fbd3bf314 Mon Sep 17 00:00:00 2001 From: