RE: [Xen-ia64-devel] [PATCH] [IA64] Fix serial console freeze issue
Kuwamura,
Maybe the fix is not enough and it may break VT-d side after you changing it
back. In addition, mach_apic.h is also needed to create. I attached the whole
patch, please check! :-)
Xiantao
# HG changeset patch
# User r...@localhost.localdomain
# Date 1251737187 14400
# Node ID dd71c509f3ff13326ddbb8fa39f638022aa814ff
# Parent e8004f6c254a5778b50babd527e74208981640b9
[IA64] Fix serial console freeze issue
20110:6e83b0ec2d70 is incomplete. irq_to_vector() is still required,
otherwise the serial console freezes without sync_console.
Signed-off-by: KUWAMURA Shin'ya k...@jp.fujitsu.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r e8004f6c254a -r dd71c509f3ff xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Thu Aug 27 11:25:34 2009 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c Mon Aug 31 12:46:27 2009 -0400
@@ -892,7 +892,11 @@ static int iommu_set_interrupt(struct io
irq_desc[irq].handler = dma_msi_type;
irq_to_iommu[irq] = iommu;
+#ifdef CONFIG_X86
ret = request_irq(irq, iommu_page_fault, 0, dmar, iommu);
+#else
+ret = request_irq_vector(irq, iommu_page_fault, 0, dmar, iommu);
+#endif
if ( ret )
{
irq_desc[irq].handler = no_irq_type;
diff -r e8004f6c254a -r dd71c509f3ff xen/include/asm-ia64/mach_apic.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/asm-ia64/mach_apic.h Mon Aug 31 12:46:27 2009 -0400
@@ -0,0 +1,1 @@
+/* Leave it as blank for compilation. */
diff -r e8004f6c254a -r dd71c509f3ff xen/include/xen/irq.h
--- a/xen/include/xen/irq.h Thu Aug 27 11:25:34 2009 +0100
+++ b/xen/include/xen/irq.h Mon Aug 31 12:46:27 2009 -0400
@@ -82,14 +82,17 @@ extern irq_desc_t irq_desc[NR_VECTORS];
extern irq_desc_t irq_desc[NR_VECTORS];
#define setup_irq(irq, action) \
-setup_irq_vector(irq, action)
+setup_irq_vector(irq_to_vector(irq), action)
#define release_irq(irq) \
-release_irq_vector(irq)
+release_irq_vector(irq_to_vector(irq))
#define request_irq(irq, handler, irqflags, devname, devid) \
-request_irq_vector(irq, handler, irqflags, devname, devid)
+request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+static inline unsigned int irq_to_vector(int);
+extern int setup_irq_vector(unsigned int, struct irqaction *);
+extern void release_irq_vector(unsigned int);
extern int request_irq_vector(unsigned int vector,
void (*handler)(int, void *, struct cpu_user_regs *),
unsigned long irqflags, const char * devname, void *dev_id);
KUWAMURA Shin'ya wrote:
Hi,
20110:6e83b0ec2d70 is incomplete. irq_to_vector() is still required,
otherwise the serial console freezes without sync_console.
I confirmed that dom0 booted up without sync_console.
Signed-off-by: KUWAMURA Shin'ya k...@jp.fujitsu.com
fix_ia64.patch
Description: fix_ia64.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-devel] RE: [Xen-ia64-devel] [PATCH] [IA64] Fix serial console freeze issue
Kuwamura,
I think it is necessary to apply the delta patch, what's your opinion ?
Xiantoa
-Original Message-
From: Keir Fraser [mailto:keir.fra...@eu.citrix.com]
Sent: Monday, August 31, 2009 6:01 PM
To: Zhang, Xiantao; KUWAMURA Shin'ya; xen-ia64-devel@lists.xensource.com;
xen-de...@lists.xensource.com
Subject: Re: [Xen-devel] RE: [Xen-ia64-devel] [PATCH] [IA64] Fix serial console
freeze issue
I already applied Kuwamura's original patch as xen-unstable:20139. Let me
know if you both agree that a delta is needed on top of that.
Thanks,
Keir
On 31/08/2009 09:53, Zhang, Xiantao xiantao.zh...@intel.com wrote:
Kuwamura,
Maybe the fix is not enough and it may break VT-d side after you changing
it back. In addition, mach_apic.h is also needed to create. I attached the
whole patch, please check! :-)
Xiantao
# HG changeset patch
# User r...@localhost.localdomain
# Date 1251737187 14400
# Node ID dd71c509f3ff13326ddbb8fa39f638022aa814ff
# Parent e8004f6c254a5778b50babd527e74208981640b9
[IA64] Fix serial console freeze issue
20110:6e83b0ec2d70 is incomplete. irq_to_vector() is still required,
otherwise the serial console freezes without sync_console.
Signed-off-by: KUWAMURA Shin'ya k...@jp.fujitsu.com
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r e8004f6c254a -r dd71c509f3ff xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Thu Aug 27 11:25:34 2009 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c Mon Aug 31 12:46:27 2009 -0400
@@ -892,7 +892,11 @@ static int iommu_set_interrupt(struct io
irq_desc[irq].handler = dma_msi_type;
irq_to_iommu[irq] = iommu;
+#ifdef CONFIG_X86
ret = request_irq(irq, iommu_page_fault, 0, dmar, iommu);
+#else
+ret = request_irq_vector(irq, iommu_page_fault, 0, dmar, iommu);
+#endif
if ( ret )
{
irq_desc[irq].handler = no_irq_type;
diff -r e8004f6c254a -r dd71c509f3ff xen/include/asm-ia64/mach_apic.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/asm-ia64/mach_apic.h Mon Aug 31 12:46:27 2009 -0400
@@ -0,0 +1,1 @@
+/* Leave it as blank for compilation. */
diff -r e8004f6c254a -r dd71c509f3ff xen/include/xen/irq.h
--- a/xen/include/xen/irq.h Thu Aug 27 11:25:34 2009 +0100
+++ b/xen/include/xen/irq.h Mon Aug 31 12:46:27 2009 -0400
@@ -82,14 +82,17 @@ extern irq_desc_t irq_desc[NR_VECTORS];
extern irq_desc_t irq_desc[NR_VECTORS];
#define setup_irq(irq, action) \
-setup_irq_vector(irq, action)
+setup_irq_vector(irq_to_vector(irq), action)
#define release_irq(irq) \
-release_irq_vector(irq)
+release_irq_vector(irq_to_vector(irq))
#define request_irq(irq, handler, irqflags, devname, devid) \
-request_irq_vector(irq, handler, irqflags, devname, devid)
+request_irq_vector(irq_to_vector(irq), handler, irqflags, devname, devid)
+static inline unsigned int irq_to_vector(int);
+extern int setup_irq_vector(unsigned int, struct irqaction *);
+extern void release_irq_vector(unsigned int);
extern int request_irq_vector(unsigned int vector,
void (*handler)(int, void *, struct cpu_user_regs *),
unsigned long irqflags, const char * devname, void *dev_id);
KUWAMURA Shin'ya wrote:
Hi,
20110:6e83b0ec2d70 is incomplete. irq_to_vector() is still required,
otherwise the serial console freezes without sync_console.
I confirmed that dom0 booted up without sync_console.
Signed-off-by: KUWAMURA Shin'ya k...@jp.fujitsu.com
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Fix DMA emualtion for ia64.
Hi, Ian and Keir
In Xen3.4-RC3, we found a regression for creating hvm domains and this
issue is discussed in the thread
http://www.nabble.com/A-strange-issue-when-VTI-guest-vcpus-number-is-near-pcpus-td23400397.html.
This patch is a key fix for Xen-3.4. Without this patch, all hvm guests maybe
crash during booting stage. Could you help to apply it for next release?
Thanks!
Xiantao
From 335c8c5bc315aa2d50b01eeabb7427f4f62c Mon Sep 17 00:00:00 2001
From: Xiantao Zhang xiantao.zh...@intel.com
Date: Fri, 8 May 2009 17:06:24 +0800
Subject: [PATCH] Fix DMA emualtion for ia64.
For DMA in native system, operating system depends on platform
flushes icache of memory touched by DMA operations.
But as to virtual DMA of virtual machine, dma emulation code has to
use explicit instructions to flush icahce,otherwise,
guest may use old icache and leads to guest's crash.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
Signed-off-by: Yang Zhang yang.zh...@intel.com
---
cache-utils.h | 12
cutils.c |7 +++
dma-helpers.c | 14 ++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/cache-utils.h b/cache-utils.h
index b45fde4..561d251 100644
--- a/cache-utils.h
+++ b/cache-utils.h
@@ -34,8 +34,20 @@ static inline void flush_icache_range(unsigned long start,
unsigned long stop)
asm volatile (isync : : : memory);
}
+#elif defined (__ia64__)
+static inline void flush_icache_range(unsigned long start, unsigned long stop)
+{
+while (start stop) {
+ asm volatile (fc %0 :: r(start));
+ start += 32;
+}
+asm volatile (;;sync.i;;srlz.i;;);
+}
+
+#define qemu_cache_utils_init(envp) do { (void) (envp); } while (0)
#else
#define qemu_cache_utils_init(envp) do { (void) (envp); } while (0)
#endif
+
#endif /* QEMU_CACHE_UTILS_H */
diff --git a/cutils.c b/cutils.c
index 4541214..5137fe1 100644
--- a/cutils.c
+++ b/cutils.c
@@ -23,6 +23,7 @@
*/
#include qemu-common.h
#include host-utils.h
+#include cache-utils.h
void pstrcpy(char *buf, size_t buf_size, const char *str)
{
@@ -157,6 +158,12 @@ void qemu_iovec_from_buffer(QEMUIOVector *qiov, const void
*buf, size_t count)
if (copy qiov-iov[i].iov_len)
copy = qiov-iov[i].iov_len;
memcpy(qiov-iov[i].iov_base, p, copy);
+
+#ifdef __ia64__
+flush_icache_range((unsigned long)qiov-iov[i].iov_base,
+ (unsigned long)(qiov-iov[i].iov_base + copy));
+#endif
+
p += copy;
count -= copy;
}
diff --git a/dma-helpers.c b/dma-helpers.c
index b2ade19..0523dc8 100644
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -9,6 +9,7 @@
#include dma.h
#include block_int.h
+#include cache-utils.h
void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint)
{
@@ -135,6 +136,19 @@ static BlockDriverAIOCB *dma_bdrv_io(
dbs-bh = NULL;
qemu_iovec_init(dbs-iov, sg-nsg);
dma_bdrv_cb(dbs, 0);
+
+#ifdef __ia64__
+if (!is_write) {
+ int i;
+ QEMUIOVector *qiov;
+qiov = dbs-iov;
+for (i = 0; i qiov-niov; ++i) {
+ flush_icache_range((unsigned long)qiov-iov[i].iov_base,
+ (unsigned long)(qiov-iov[i].iov_base +
qiov-iov[i].iov_len));
+ }
+}
+#endif
+
return dbs-acb;
}
--
1.5.2.4
0001-Fix-DMA-emualtion-for-ia64.patch
Description: 0001-Fix-DMA-emualtion-for-ia64.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix DMA emualtion for ia64.
Ian Jackson wrote: Zhang, Xiantao writes ([Xen-devel] [PATCH] Fix DMA emualtion for ia64.): In Xen3.4-RC3, we found a regression for creating hvm domains and this issue is discussed in the thread http://www.nabble.com/A-strange-issue-when-VTI-guest-vcpus-number-is-near-pcpus-td23400397.html. This patch is a key fix for Xen-3.4. Without this patch, all hvm guests maybe crash during booting stage. Could you help to apply it for next release? Thanks! Thanks for the report and the patch, which I'm applying. But I did have some questions. These changes are largely to code which we've inherited unchanged from upstream qemu. Are they specific to Xen ? I suspect not. I don't really know about the icache coherency rules in ia64 but it seems to me that if this patch is appropriate for qemu-dm on ia64, it's probably also appropriate for kvm-userpace on ia64 (if indeed there is such a thing) and perhaps also for ordinary translating cpu-emulating qemu. Yes, it is comment issue for qemu-dm, kvm-userspace and qemu upstream. And we will push the patch to qemu upstream, and also needs to find a clean solution for that. As I know, only ia64 platform has such requirement for icache coherence. In which case perhaps it would be good for us to discuss with qemu upstream how to address this question. I don't think the #ifdef __ia64__ can be right outside the Xen context; for one thing, we should use a symbol related to specifically to either the host or the target architecture (which may be different in qemu of course). I assume that the problem exists related to ia64 hosts, rather than ia64 guests ? Since TARGET_IA64 doesn't work in the context, so I just use __ia64__ instead. As you said, it maybe not proper for all cases of host and guests, but you know qemu doesn't work for ia64 regardless of hosts and guests. That is to say, Xen or kvm only uses qemu's device model for virtual device emualtion, and other parts doesn't work for them. Certainly, we should find a clean solution to fix it when we will enable guest and host support in future. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] A strange issue when VTI guest vcpus number is near pcpus
It maybe related to recent DMA emulation changes in qemu, and lead to guest uses incorrect icache for instruction streams. Xiantao -Original Message- From: xen-ia64-devel-boun...@lists.xensource.com [mailto:xen-ia64-devel-boun...@lists.xensource.com] On Behalf Of You, Yongkang Sent: Thursday, May 07, 2009 12:57 PM To: Isaku Yamahata Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] A strange issue when VTI guest vcpus number is near pcpus On Thursday, May 07, 2009 10:22 AM Isaku Yamahata wrote: On Wed, May 06, 2009 at 01:54:15PM +0800, You, Yongkang wrote: On xen-ia64-devel-boun...@lists.xensource.com wrote: Hi, When I try recently Xen (Xen 3.4 rc3) on IA64 machine (Tiger4), I found some strange issue. My two systems have 4 and 8 pcpus separately If VTI guest's vcpus is near pcpus, guest booting will meet some issues: 1. Guest boot might be hang at switch to new root and run init; unmounting old /dev ...; unmounting old /sys for a long time. Does this mean that it's unreasonably slow? Em. It will stop there for a very long time (multi minutes). And it reached login prompt eventually? I tried many times, but didn't wait for login interface everytime. So couldn't say it would always reach login. Thanks, Yongkang ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Fix a missing return value check.
Fixed the missing return value check. Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com diff -r b432c632ebe8 xen/arch/ia64/linux-xen/irq_ia64.c --- a/xen/arch/ia64/linux-xen/irq_ia64.cFri Feb 13 19:11:38 2009 +0900 +++ b/xen/arch/ia64/linux-xen/irq_ia64.cThu Mar 26 14:04:41 2009 +0800 @@ -295,7 +295,7 @@ int request_irq_vector(unsigned int vect action-handler = handler; action-name = devname; action-dev_id = dev_id; - setup_vector(vector, action); + retval = setup_vector(vector, action); if (retval) xfree(action); check_ret_value_for_setup_vector.patch Description: check_ret_value_for_setup_vector.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Fix a missing return value check.
We had better push it into Xen's next release. Xiantao Isaku Yamahata wrote: Hi, thank you for the patch. This is for xen-unstable.hg? not for xen-ia64-unstable.hg. xen-ia64-unstable.hg already has the change set of 19207:c4c4ba857d8b which includes your patch. Is this for the next release? Then, I'll request Keir to pull the ia64 repo. thanks, On Thu, Mar 26, 2009 at 02:12:02PM +0800, Zhang, Xiantao wrote: Fixed the missing return value check. Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com diff -r b432c632ebe8 xen/arch/ia64/linux-xen/irq_ia64.c --- a/xen/arch/ia64/linux-xen/irq_ia64.c Fri Feb 13 19:11:38 2009 +0900 +++ b/xen/arch/ia64/linux-xen/irq_ia64.c Thu Mar 26 14:04:41 2009 +0800 @@ -295,7 +295,7 @@ int request_irq_vector(unsigned int vectaction-handler = handler; action-name = devname; action-dev_id = dev_id; -setup_vector(vector, action); +retval = setup_vector(vector, action); if (retval) xfree(action); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote: On Thu, Mar 05, 2009 at 11:55:10AM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: On Wed, Mar 04, 2009 at 05:26:41PM +0800, Zhang, Xiantao wrote: So far, we just found the msi-x case. Maybe we will add msi-x support later, so this fix is also required. Okay, makes sense. And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware of io_ranges[]? For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges. You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to intialize p2m entries for low mmio range. Hmm, there are two cases to call xc_domain_mempry_mapping(DPCI_REMOVE_MAPPING). - Just to remove the entry. zap_domain_page_one() is wanted. Why remove the entries ? For hvm domain, I think the entires should always exists during the lift of the guests. You may refer to the call vmx_build_io_physmap_table, and these entries are created at the initialization time of the domain. the one in pt_iomem_map() and remove_msix_mapping() excpet called by pt_iomem_map() - mmio on the area should be rounted to qemu-dm GPFN_LOW_MMIO and ASSIGN_io are wanted. remove_msix_mapping() which is called by pt_iomem_map(). Is there a way to distinguish them. We don't need to distinguish them, and instead of we should keep these entires in two cases consistent with the values which is initilized by vmx_build_io_physmap_table. The current x86 implementation mmio which isn't handled by xen VMM are passed to qemu-dm. On the other hand, the current xen/ia64 check _PAGE_IO and if _PAGE_IO it is passed to qemu-dm, otherwise panic_domain() So the behaviour should be changed such that if load/store on the unpresent p2m entry is passed to qemu-dm like x86. That may change much logic. I think only vmx_hpw_miss() (and possibly few related functions) needs modification. For hvm/ia64, we have the assumption that all p2m entries for mmio range should exist, and use the _PAGE_IO to identify its type. But the msi-x emulation code in qemu-dm doesn't assume it. So you created the patch, didn't you? If you want to keep the assumption, the code to change would be the msi-x emulation in qemu-dm, not vmm. I don't think we need to touch the code in qemu-dm, could you give some hint ? In addition, maybe we need do flush_tlb_all after removing some mapping for mmio range ? Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote:
On Tue, Mar 03, 2009 at 05:32:42PM +0800, Zhang, Xiantao wrote:
Isaku Yamahata wrote:
Could you elaborate on the concrete issue which you're seeing?
I guess the issue occurs when passed through pci device
is unplugged. But in that case, the region was occupied by
the device so that qemu haven't seen io on the area anyway.
For assigning a device to a hvm domain, all mmio regions of the pci
device should be mapped in p2m table, but a corner case is that
accessing some pages(for example, vector table in msi-x's bar) in
one region maybe need route to qemu and emulate the corresponding
logic in qemu. In that case, we have to remove the mapping for the
specified pages in p2m, and let accessing these pages intercepted by
hyperviosr and forward the io requests to qemu. But
zap_domain_page_one can't intilziate the mmio p2m entries for hvm
domain. Clear ? :-)
You mean pt_iomem_map() which calls remove_msix_mapping() in
pass-through.c of qemu-dm? Is there any case other than msi-x?
I couldn't find any other usefull case because the current xen/ia64
doesn't support msi/msi-x.
So far, we just found the msi-x case. Maybe we will add msi-x support later, so
this fix is also required.
And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
of io_ranges[]?
For the low mmio ranges (3G-3.5G), we can use the fixed mfn
GPFN_LOW_MMIO combined with ASSIGN_io to indicate whether the p2m
entries are mmio ranges. You may refer to io_ranges and it also
use the fixed GPFN_LOW_MMIO to intialize p2m entries for low mmio
range.
Hmm, there are two cases to call
xc_domain_mempry_mapping(DPCI_REMOVE_MAPPING). - Just to remove the
entry. zap_domain_page_one() is wanted.
Why remove the entries ? For hvm domain, I think the entires should always
exists during the lift of the guests.
You may refer to the call vmx_build_io_physmap_table, and these entries are
created at the initialization time of the domain.
the one in pt_iomem_map() and remove_msix_mapping() excpet called
by pt_iomem_map()
- mmio on the area should be rounted to qemu-dm
GPFN_LOW_MMIO and ASSIGN_io are wanted.
remove_msix_mapping() which is called by pt_iomem_map().
Is there a way to distinguish them.
We don't need to distinguish them, and instead of we should keep these entires
in two cases consistent with the values which is initilized by
vmx_build_io_physmap_table.
thanks,
Xiantao
On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote:
PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
When de-assign the mmio range, it should resume its original value
for p2m value, otherwise, it may fail to determin mmio range's
type.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800
+++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800
@@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
return -EINVAL; }
-for (; addr end; addr += PAGE_SIZE )
-zap_domain_page_one(d, addr, 0, INVALID_MFN);
+for (; addr end; addr += PAGE_SIZE ) {
+ if (is_hvm_domain(d))
+__assign_domain_page(d, addr, GPFN_LOW_MMIO
PAGE_SHIFT, +
ASSIGN_writable |
ASSIGN_io); + else +zap_domain_page_one(d, addr, 0,
INVALID_MFN); +} + return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote: On Wed, Mar 04, 2009 at 05:26:41PM +0800, Zhang, Xiantao wrote: So far, we just found the msi-x case. Maybe we will add msi-x support later, so this fix is also required. Okay, makes sense. And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware of io_ranges[]? For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges. You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to intialize p2m entries for low mmio range. Hmm, there are two cases to call xc_domain_mempry_mapping(DPCI_REMOVE_MAPPING). - Just to remove the entry. zap_domain_page_one() is wanted. Why remove the entries ? For hvm domain, I think the entires should always exists during the lift of the guests. You may refer to the call vmx_build_io_physmap_table, and these entries are created at the initialization time of the domain. the one in pt_iomem_map() and remove_msix_mapping() excpet called by pt_iomem_map() - mmio on the area should be rounted to qemu-dm GPFN_LOW_MMIO and ASSIGN_io are wanted. remove_msix_mapping() which is called by pt_iomem_map(). Is there a way to distinguish them. We don't need to distinguish them, and instead of we should keep these entires in two cases consistent with the values which is initilized by vmx_build_io_physmap_table. The current x86 implementation mmio which isn't handled by xen VMM are passed to qemu-dm. On the other hand, the current xen/ia64 check _PAGE_IO and if _PAGE_IO it is passed to qemu-dm, otherwise panic_domain() So the behaviour should be changed such that if load/store on the unpresent p2m entry is passed to qemu-dm like x86. That may change much logic. For hvm/ia64, we have the assumption that all p2m entries for mmio range should exist, and use the _PAGE_IO to identify its type. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
Isaku Yamahata wrote:
Could you elaborate on the concrete issue which you're seeing?
I guess the issue occurs when passed through pci device
is unplugged. But in that case, the region was occupied by
the device so that qemu haven't seen io on the area anyway.
For assigning a device to a hvm domain, all mmio regions of the pci device
should be mapped in p2m table, but a corner case is that accessing some
pages(for example, vector table in msi-x's bar) in one region maybe need route
to qemu and emulate the corresponding logic in qemu. In that case, we have to
remove the mapping for the specified pages in p2m, and let accessing these
pages intercepted by hyperviosr and forward the io requests to qemu. But
zap_domain_page_one can't intilziate the mmio p2m entries for hvm domain.
Clear ? :-)
And why GPFN_LOW_MMIO independently of addr? Shouldn't it be aware
of io_ranges[]?
For the low mmio ranges (3G-3.5G), we can use the fixed mfn GPFN_LOW_MMIO
combined with ASSIGN_io to indicate whether the p2m entries are mmio ranges.
You may refer to io_ranges and it also use the fixed GPFN_LOW_MMIO to intialize
p2m entries for low mmio range.
Xiantao
On Tue, Mar 03, 2009 at 03:14:02PM +0800, Zhang, Xiantao wrote:
PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
When de-assign the mmio range, it should resume its original value
for p2m value, otherwise, it may fail to determin mmio range's type.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Tue Feb 10 13:47:02 2009 +0800
+++ b/xen/arch/ia64/xen/mm.c Tue Mar 03 15:04:54 2009 +0800
@@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
return -EINVAL; }
-for (; addr end; addr += PAGE_SIZE )
-zap_domain_page_one(d, addr, 0, INVALID_MFN);
+for (; addr end; addr += PAGE_SIZE ) {
+if (is_hvm_domain(d))
+__assign_domain_page(d, addr, GPFN_LOW_MMIO
PAGE_SHIFT, +
ASSIGN_writable |
ASSIGN_io); +else +zap_domain_page_one(d, addr, 0,
INVALID_MFN); +} +
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: Fix one issue when assigning device with 64-bit bars.
We only found it when assigning the device with vt-d. Since qemu doesn't have the device with 64-bit bars, so maybe no issue. Xiantao Tristan Gingold wrote: On Tue, Mar 03, 2009 at 01:47:49PM +0800, Zhang, Xiantao wrote: Hi, Tristan Attached patch targets for fixing the issue when assigning the devices with 64-bit bars. Current logic may deem one 64-bit bar as two 32-bit bars, and make the system crash finally. Merged, thanks! Do you meet the issue with qemu or with VTD devices ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Fix one issue when assigning device with 64-bit bars.
Hi, Tristan Attached patch targets for fixing the issue when assigning the devices with 64-bit bars. Current logic may deem one 64-bit bar as two 32-bit bars, and make the system crash finally. Thanks Xiantao fix-64-bit-bars-in-pci-scan.patch Description: fix-64-bit-bars-in-pci-scan.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]Fix the logic when deassign the mmio ranges for vti-domain.
PATCH: Fix the logic when deassign the mmio ranges for vti-domain.
When de-assign the mmio range, it should resume its original value
for p2m value, otherwise, it may fail to determin mmio range's type.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 67f2e14613ef xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Feb 10 13:47:02 2009 +0800
+++ b/xen/arch/ia64/xen/mm.cTue Mar 03 15:04:54 2009 +0800
@@ -1508,8 +1508,14 @@ deassign_domain_mmio_page(struct domain
return -EINVAL;
}
-for (; addr end; addr += PAGE_SIZE )
-zap_domain_page_one(d, addr, 0, INVALID_MFN);
+for (; addr end; addr += PAGE_SIZE ) {
+ if (is_hvm_domain(d))
+__assign_domain_page(d, addr, GPFN_LOW_MMIO PAGE_SHIFT,
+ ASSIGN_writable | ASSIGN_io);
+ else
+zap_domain_page_one(d, addr, 0, INVALID_MFN);
+}
+
return 0;
}
fix_deassign_mmio.patch
Description: fix_deassign_mmio.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH]ia64: Enhance vt-d support for ia64.
Keir Fraser wrote: On 17/02/2009 03:47, Zhang, Xiantao xiantao.zh...@intel.com wrote: This patch targets for enhancing vt-d support for ia64. 1. reserve enough memory for building dom0 vt-d page table. 2. build 1:1 vt-d page table according to system's mem map. 3. enable vt-d interrupt support for ia64. Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com Acked-by: Isaku Yamahata yamah...@valinux.co.jp Applied, but it's actually broken the ia64 build due to missing asm-ia64/msi.h. Someone needs to fix that. I have sent the patch to Isaku, and he will fix it in xen-ia64-unstable.hg to later. Thanks! Xiantao missing_msi.patch Description: missing_msi.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Fix the missing msi.h by accident
Hi, Isaku
msi.h is missing by accident, please apply the patch to fix it.
Thanks!
Xiantao
# HG changeset patch
# User xiantao.zh...@intel.com
# Date 1234925881 -28800
# Node ID 162a4dab79e4ba119faea63c41ec94978caccc6b
# Parent 66b5e1edeec64b30f53ed8529d5ad7197e6a8a73
ia64: Fix the missing msi.h by accident, and enhance the check
for one BUG_ON.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 66b5e1edeec6 -r 162a4dab79e4 xen/drivers/passthrough/vtd/ia64/vtd.c
--- a/xen/drivers/passthrough/vtd/ia64/vtd.cWed Feb 18 10:44:46 2009 +0800
+++ b/xen/drivers/passthrough/vtd/ia64/vtd.cWed Feb 18 10:58:01 2009 +0800
@@ -141,6 +141,7 @@ static int do_dom0_iommu_mapping(unsigne
void iommu_set_dom0_mapping(struct domain *d)
{
- BUG_ON(d != dom0);
+ if (dom0)
+ BUG_ON(d != dom0);
efi_memmap_walk(do_dom0_iommu_mapping, d);
}
diff -r 09a6fa059b37 -r 66b5e1edeec6 xen/include/asm-ia64/msi.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/asm-ia64/msi.hWed Feb 18 10:44:46 2009 +0800
@@ -0,0 +1,20 @@
+#ifndef __ASM_MSI_H
+#define __ASM_MSI_H
+
+/*
+ * MSI Defined Data Structures
+ */
+#define MSI_ADDRESS_HEADER 0xfee
+#define MSI_ADDRESS_HEADER_SHIFT 12
+#define MSI_ADDRESS_HEADER_MASK0xfff000
+#define MSI_ADDRESS_DEST_ID_MASK 0xffff
+#define MSI_TARGET_CPU_MASK0xff
+#define MSI_TARGET_CPU_SHIFT 4
+#define MSI_DELIVERY_MODE 0
+#define MSI_LEVEL_MODE 1 /* Edge always assert */
+#define MSI_TRIGGER_MODE 0 /* MSI is edge sensitive */
+#define MSI_PHYSICAL_MODE 0
+#define MSI_LOGICAL_MODE 1
+#define MSI_REDIRECTION_HINT_MODE 0
+
+#endif /* __ASM_MSI_H */
missing_msi.patch
Description: missing_msi.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [IA64] Enhance vt-d support for ia64
Hi, Isaku
This patch targets for enhancing vt-d support for ia64, could you help
to review?
Xiantao
# HG changeset patch
# User xian...@vti-build.sh.intel.com
# Date 1234244822 -28800
# Node ID 67f2e14613efc0a18924fd60f2561999b9f59a43
# Parent 4fd4dcf2f8916ab4656911a76e52fc6b1ad42c2f
[IA64] Enhance vt-d support for ia64
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cWed Jan 28 12:22:58 2009 +0900
+++ b/xen/arch/ia64/xen/domain.cTue Feb 10 13:47:02 2009 +0800
@@ -1999,6 +1999,7 @@ static void __init calc_dom0_size(void)
unsigned long p2m_pages;
unsigned long spare_hv_pages;
unsigned long max_dom0_size;
+ unsigned long iommu_pg_table_pages = 0;
/* Estimate maximum memory we can safely allocate for dom0
* by subtracting the p2m table allocation and a chunk of memory
@@ -2009,8 +2010,13 @@ static void __init calc_dom0_size(void)
domheap_pages = avail_domheap_pages();
p2m_pages = domheap_pages / PTRS_PER_PTE;
spare_hv_pages = 8192 + (domheap_pages / 4096);
- max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages))
-* PAGE_SIZE;
+
+ if (iommu_enabled)
+ iommu_pg_table_pages = domheap_pages * 4 / 512;
+ /* There are 512 ptes in one 4K vtd page. */
+
+ max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages) -
+ iommu_pg_table_pages) * PAGE_SIZE;
printk(Maximum permitted dom0 size: %luMB\n,
max_dom0_size / (1024*1024));
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/drivers/passthrough/vtd/ia64/vtd.c
--- a/xen/drivers/passthrough/vtd/ia64/vtd.cWed Jan 28 12:22:58 2009 +0900
+++ b/xen/drivers/passthrough/vtd/ia64/vtd.cTue Feb 10 13:47:02 2009 +0800
@@ -111,3 +111,34 @@ void hvm_dpci_isairq_eoi(struct domain *
{
/* dummy */
}
+
+static int dom0_set_iommu_mapping(unsigned long start, unsigned long end,
+ void *arg)
+{
+unsigned long tmp, pfn, j, page_addr = start;
+struct domain *d = (struct domain *)arg;
+
+/*
+ * Set up 1:1 page table for dom0 except the critical segments
+ * like Xen and tboot.
+ */
+
+while (page_addr end)
+{
+ if (xen_in_range(page_addr, page_addr + PAGE_SIZE))
+continue;
+
+pfn = page_addr PAGE_SHIFT;
+tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
+for ( j = 0; j tmp; j++ )
+iommu_map_page(d, (pfn*tmp+j), (pfn*tmp+j));
+
+ page_addr += PAGE_SIZE;
+}
+}
+
+void iommu_dom0_do_mapping(struct domain *d)
+{
+ BUG_ON(d != dom0);
+ efi_memmap_walk(dom0_set_iommu_mapping, d);
+}
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Wed Jan 28 12:22:58 2009 +0900
+++ b/xen/drivers/passthrough/vtd/iommu.c Tue Feb 10 13:47:02 2009 +0800
@@ -829,7 +829,6 @@ static void dma_msi_data_init(struct iom
spin_unlock_irqrestore(iommu-register_lock, flags);
}
-#ifdef SUPPORT_MSI_REMAPPING
static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu)
{
u64 msi_address;
@@ -846,12 +845,6 @@ static void dma_msi_addr_init(struct iom
dmar_writel(iommu-reg, DMAR_FEUADDR_REG, (u32)(msi_address 32));
spin_unlock_irqrestore(iommu-register_lock, flags);
}
-#else
-static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu)
-{
-/* ia64: TODO */
-}
-#endif
static void dma_msi_set_affinity(unsigned int vector, cpumask_t dest)
{
@@ -993,24 +986,7 @@ static int intel_iommu_domain_init(struc
if ( d-domain_id == 0 )
{
-extern int xen_in_range(paddr_t start, paddr_t end);
-extern int tboot_in_range(paddr_t start, paddr_t end);
-
-/*
- * Set up 1:1 page table for dom0 except the critical segments
- * like Xen and tboot.
- */
-for ( i = 0; i max_page; i++ )
-{
-if ( xen_in_range(i PAGE_SHIFT, (i + 1) PAGE_SHIFT) ||
- tboot_in_range(i PAGE_SHIFT, (i + 1) PAGE_SHIFT) )
-continue;
-
-tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
-for ( j = 0; j tmp; j++ )
-iommu_map_page(d, (i*tmp+j), (i*tmp+j));
-}
-
+ iommu_dom0_do_mapping(d);
setup_dom0_devices(d);
setup_dom0_rmrr(d);
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/drivers/passthrough/vtd/x86/vtd.c
--- a/xen/drivers/passthrough/vtd/x86/vtd.c Wed Jan 28 12:22:58 2009 +0900
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c Tue Feb 10 13:47:02 2009 +0800
@@ -142,3 +142,25 @@ void hvm_dpci_isairq_eoi(struct domain *
}
spin_unlock(d-event_lock);
}
+
+void iommu_dom0_do_mapping(struct domain *d)
+{
+extern int xen_in_range(paddr_t start, paddr_t end);
+extern int tboot_in_range(paddr_t start, paddr_t end);
[Xen-ia64-devel] RE: [IA64] Enhance vt-d support for ia64
Isaku Yamahata wrote:
On Mon, Feb 16, 2009 at 06:33:45PM +0800, Zhang, Xiantao wrote:
Hi, Isaku
This patch targets for enhancing vt-d support for ia64, could you
help to review?
It looks mostly good.
How about moving arch independent MSI related definitions
into a common header file instead of duplicating with
xen/include/asm-ia64/msi.h?
Good suggestion! But ia64 has different value for one macro with x86 side, so
maybe not proper to move them into common header file. You know, in linux
kernel, ia64 and X86 also duplicate them to solve the differences. :)
Xiantao
Xiantao
# HG changeset patch
# User xian...@vti-build.sh.intel.com
# Date 1234244822 -28800
# Node ID 67f2e14613efc0a18924fd60f2561999b9f59a43
# Parent 4fd4dcf2f8916ab4656911a76e52fc6b1ad42c2f
[IA64] Enhance vt-d support for ia64
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Jan 28 12:22:58 2009 +0900
+++ b/xen/arch/ia64/xen/domain.c Tue Feb 10 13:47:02 2009 +0800
@@ -1999,6 +1999,7 @@ static void __init calc_dom0_size(void)
unsigned long p2m_pages; unsigned long spare_hv_pages;
unsigned long max_dom0_size;
+unsigned long iommu_pg_table_pages = 0;
/* Estimate maximum memory we can safely allocate for dom0
* by subtracting the p2m table allocation and a chunk of memory
@@ -2009,8 +2010,13 @@ static void __init calc_dom0_size(void)
domheap_pages = avail_domheap_pages();
p2m_pages = domheap_pages / PTRS_PER_PTE;
spare_hv_pages = 8192 + (domheap_pages / 4096);
-max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages))
- * PAGE_SIZE;
+
+if (iommu_enabled)
+iommu_pg_table_pages = domheap_pages * 4 / 512;
+/* There are 512 ptes in one 4K vtd page. */
+
+max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages) -
+iommu_pg_table_pages) * PAGE_SIZE;
printk(Maximum permitted dom0 size: %luMB\n,
max_dom0_size / (1024*1024));
diff -r 4fd4dcf2f891 -r 67f2e14613ef
xen/drivers/passthrough/vtd/ia64/vtd.c ---
a/xen/drivers/passthrough/vtd/ia64/vtd.c Wed Jan 28 12:22:58 2009
+0900 +++ b/xen/drivers/passthrough/vtd/ia64/vtd.c Tue Feb 10
13:47:02 2009 +0800 @@ -111,3 +111,34 @@ void
hvm_dpci_isairq_eoi(struct domain * { /* dummy */ }
+
+static int dom0_set_iommu_mapping(unsigned long start, unsigned
long end, + void *arg) +{
+unsigned long tmp, pfn, j, page_addr = start;
+struct domain *d = (struct domain *)arg;
+
+/*
+ * Set up 1:1 page table for dom0 except the critical segments
+ * like Xen and tboot. + */
+
+while (page_addr end)
+{
+if (xen_in_range(page_addr, page_addr + PAGE_SIZE)) +
continue; +
+pfn = page_addr PAGE_SHIFT;
+tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
+for ( j = 0; j tmp; j++ )
+iommu_map_page(d, (pfn*tmp+j), (pfn*tmp+j)); +
+page_addr += PAGE_SIZE;
+}
+}
+
+void iommu_dom0_do_mapping(struct domain *d)
+{
+BUG_ON(d != dom0);
+efi_memmap_walk(dom0_set_iommu_mapping, d);
+}
diff -r 4fd4dcf2f891 -r 67f2e14613ef
xen/drivers/passthrough/vtd/iommu.c ---
a/xen/drivers/passthrough/vtd/iommu.cWed Jan 28 12:22:58 2009 +0900
+++ b/xen/drivers/passthrough/vtd/iommu.cTue Feb 10 13:47:02 2009
+0800 @@ -829,7 +829,6 @@ static void dma_msi_data_init(struct
iom spin_unlock_irqrestore(iommu-register_lock, flags); }
-#ifdef SUPPORT_MSI_REMAPPING
static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu) {
u64 msi_address;
@@ -846,12 +845,6 @@ static void dma_msi_addr_init(struct iom
dmar_writel(iommu-reg, DMAR_FEUADDR_REG, (u32)(msi_address
32)); spin_unlock_irqrestore(iommu-register_lock, flags); }
-#else
-static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu) -{
-/* ia64: TODO */
-}
-#endif
static void dma_msi_set_affinity(unsigned int vector, cpumask_t
dest) { @@ -993,24 +986,7 @@ static int
intel_iommu_domain_init(struc
if ( d-domain_id == 0 )
{
-extern int xen_in_range(paddr_t start, paddr_t end);
-extern int tboot_in_range(paddr_t start, paddr_t end); -
-/*
- * Set up 1:1 page table for dom0 except the critical
segments
- * like Xen and tboot.
- */
-for ( i = 0; i max_page; i++ )
-{
-if ( xen_in_range(i PAGE_SHIFT, (i + 1)
PAGE_SHIFT) ||
- tboot_in_range(i PAGE_SHIFT, (i + 1)
PAGE_SHIFT) )
-continue;
-
-tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
-for ( j = 0; j tmp; j++ )
-iommu_map_page(d, (i*tmp+j), (i*tmp+j));
-}
-
+iommu_dom0_do_mapping(d);
setup_dom0_devices(d
[Xen-ia64-devel] RE: [IA64] Enhance vt-d support for ia64
Okay, thanks!
Xiantao
-Original Message-
From: Isaku Yamahata [mailto:yamah...@valinux.co.jp]
Sent: Tuesday, February 17, 2009 10:12 AM
To: Zhang, Xiantao
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [IA64] Enhance vt-d support for ia64
The patch touches the common/x86 part.
So please sent it to xen-devel, then I'll pull it.
Acked-by: Isaku Yamahata yamah...@valinux.co.jp
On Tue, Feb 17, 2009 at 10:57:21AM +0900, Isaku Yamahata wrote:
On Tue, Feb 17, 2009 at 09:42:05AM +0800, Zhang, Xiantao wrote:
Isaku Yamahata wrote:
On Mon, Feb 16, 2009 at 06:33:45PM +0800, Zhang, Xiantao wrote:
Hi, Isaku
This patch targets for enhancing vt-d support for ia64, could you
help to review?
It looks mostly good.
How about moving arch independent MSI related definitions
into a common header file instead of duplicating with
xen/include/asm-ia64/msi.h?
Good suggestion! But ia64 has different value for one macro with x86 side,
so maybe not proper to move them into common header file. You know, in
linux kernel, ia64 and X86 also duplicate them to solve the differences. :)
Oh I see. Sounds reasonable.
Xiantao
Xiantao
# HG changeset patch
# User xian...@vti-build.sh.intel.com
# Date 1234244822 -28800
# Node ID 67f2e14613efc0a18924fd60f2561999b9f59a43
# Parent 4fd4dcf2f8916ab4656911a76e52fc6b1ad42c2f
[IA64] Enhance vt-d support for ia64
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
diff -r 4fd4dcf2f891 -r 67f2e14613ef xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Jan 28 12:22:58 2009 +0900
+++ b/xen/arch/ia64/xen/domain.c Tue Feb 10 13:47:02 2009 +0800
@@ -1999,6 +1999,7 @@ static void __init calc_dom0_size(void)
unsigned long p2m_pages; unsigned long spare_hv_pages;
unsigned long max_dom0_size;
+unsigned long iommu_pg_table_pages = 0;
/* Estimate maximum memory we can safely allocate for dom0
* by subtracting the p2m table allocation and a chunk of memory
@@ -2009,8 +2010,13 @@ static void __init calc_dom0_size(void)
domheap_pages = avail_domheap_pages();
p2m_pages = domheap_pages / PTRS_PER_PTE;
spare_hv_pages = 8192 + (domheap_pages / 4096);
-max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages))
- * PAGE_SIZE;
+
+if (iommu_enabled)
+iommu_pg_table_pages = domheap_pages * 4 / 512;
+/* There are 512 ptes in one 4K vtd page. */
+
+max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages) -
+iommu_pg_table_pages) * PAGE_SIZE;
printk(Maximum permitted dom0 size: %luMB\n,
max_dom0_size / (1024*1024));
diff -r 4fd4dcf2f891 -r 67f2e14613ef
xen/drivers/passthrough/vtd/ia64/vtd.c ---
a/xen/drivers/passthrough/vtd/ia64/vtd.c Wed Jan 28 12:22:58 2009
+0900 +++ b/xen/drivers/passthrough/vtd/ia64/vtd.c Tue Feb 10
13:47:02 2009 +0800 @@ -111,3 +111,34 @@ void
hvm_dpci_isairq_eoi(struct domain * { /* dummy */ }
+
+static int dom0_set_iommu_mapping(unsigned long start, unsigned
long end, + void *arg) +{
+unsigned long tmp, pfn, j, page_addr = start;
+struct domain *d = (struct domain *)arg;
+
+/*
+ * Set up 1:1 page table for dom0 except the critical segments
+ * like Xen and tboot. + */
+
+while (page_addr end)
+{
+if (xen_in_range(page_addr, page_addr + PAGE_SIZE)) +
continue; +
+pfn = page_addr PAGE_SHIFT;
+tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
+for ( j = 0; j tmp; j++ )
+iommu_map_page(d, (pfn*tmp+j), (pfn*tmp+j)); +
+page_addr += PAGE_SIZE;
+}
+}
+
+void iommu_dom0_do_mapping(struct domain *d)
+{
+BUG_ON(d != dom0);
+efi_memmap_walk(dom0_set_iommu_mapping, d);
+}
diff -r 4fd4dcf2f891 -r 67f2e14613ef
xen/drivers/passthrough/vtd/iommu.c ---
a/xen/drivers/passthrough/vtd/iommu.cWed Jan 28 12:22:58 2009 +0900
+++ b/xen/drivers/passthrough/vtd/iommu.cTue Feb 10 13:47:02 2009
+0800 @@ -829,7 +829,6 @@ static void dma_msi_data_init(struct
iom spin_unlock_irqrestore(iommu-register_lock, flags); }
-#ifdef SUPPORT_MSI_REMAPPING
static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu) {
u64 msi_address;
@@ -846,12 +845,6 @@ static void dma_msi_addr_init(struct iom
dmar_writel(iommu-reg, DMAR_FEUADDR_REG, (u32)(msi_address
32)); spin_unlock_irqrestore(iommu-register_lock, flags); }
-#else
-static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu) -{
-/* ia64: TODO */
-}
-#endif
static void dma_msi_set_affinity(unsigned int vector, cpumask_t
[Xen-ia64-devel] [PATCH]ia64: Enhance vt-d support for ia64.
This patch targets for enhancing vt-d support for ia64.
1. reserve enough memory for building dom0 vt-d page table.
2. build 1:1 vt-d page table according to system's mem map.
3. enable vt-d interrupt support for ia64.
Signed-off-by: Xiantao Zhang xiantao.zh...@intel.com
Acked-by: Isaku Yamahata yamah...@valinux.co.jp
diff -r 09a6fa059b37 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri Feb 13 09:48:56 2009 +
+++ b/xen/arch/ia64/xen/domain.cTue Feb 17 11:28:57 2009 +0800
@@ -2029,6 +2029,7 @@ static void __init calc_dom0_size(void)
unsigned long p2m_pages;
unsigned long spare_hv_pages;
unsigned long max_dom0_size;
+ unsigned long iommu_pg_table_pages = 0;
/* Estimate maximum memory we can safely allocate for dom0
* by subtracting the p2m table allocation and a chunk of memory
@@ -2039,8 +2040,13 @@ static void __init calc_dom0_size(void)
domheap_pages = avail_domheap_pages();
p2m_pages = domheap_pages / PTRS_PER_PTE;
spare_hv_pages = 8192 + (domheap_pages / 4096);
- max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages))
-* PAGE_SIZE;
+
+ if (iommu_enabled)
+ iommu_pg_table_pages = domheap_pages * 4 / 512;
+ /* There are 512 ptes in one 4K vtd page. */
+
+ max_dom0_size = (domheap_pages - (p2m_pages + spare_hv_pages) -
+ iommu_pg_table_pages) * PAGE_SIZE;
printk(Maximum permitted dom0 size: %luMB\n,
max_dom0_size / (1024*1024));
diff -r 09a6fa059b37 xen/drivers/passthrough/vtd/ia64/vtd.c
--- a/xen/drivers/passthrough/vtd/ia64/vtd.cFri Feb 13 09:48:56 2009 +
+++ b/xen/drivers/passthrough/vtd/ia64/vtd.cTue Feb 17 11:28:57 2009 +0800
@@ -114,3 +114,33 @@ void hvm_dpci_isairq_eoi(struct domain *
{
/* dummy */
}
+
+static int do_dom0_iommu_mapping(unsigned long start, unsigned long end,
+ void *arg)
+{
+unsigned long tmp, pfn, j, page_addr = start;
+struct domain *d = (struct domain *)arg;
+
+extern int xen_in_range(paddr_t start, paddr_t end);
+/* Set up 1:1 page table for dom0 for all Ram except Xen bits.*/
+
+while (page_addr end)
+{
+ if (xen_in_range(page_addr, page_addr + PAGE_SIZE))
+continue;
+
+pfn = page_addr PAGE_SHIFT;
+tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
+for ( j = 0; j tmp; j++ )
+iommu_map_page(d, (pfn*tmp+j), (pfn*tmp+j));
+
+ page_addr += PAGE_SIZE;
+}
+return 0;
+}
+
+void iommu_set_dom0_mapping(struct domain *d)
+{
+ BUG_ON(d != dom0);
+ efi_memmap_walk(do_dom0_iommu_mapping, d);
+}
diff -r 09a6fa059b37 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Fri Feb 13 09:48:56 2009 +
+++ b/xen/drivers/passthrough/vtd/iommu.c Tue Feb 17 11:28:57 2009 +0800
@@ -30,6 +30,7 @@
#include xen/pci.h
#include xen/pci_regs.h
#include xen/keyhandler.h
+#include asm/msi.h
#include iommu.h
#include dmar.h
#include extern.h
@@ -829,7 +830,6 @@ static void dma_msi_data_init(struct iom
spin_unlock_irqrestore(iommu-register_lock, flags);
}
-#ifdef SUPPORT_MSI_REMAPPING
static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu)
{
u64 msi_address;
@@ -846,12 +846,6 @@ static void dma_msi_addr_init(struct iom
dmar_writel(iommu-reg, DMAR_FEUADDR_REG, (u32)(msi_address 32));
spin_unlock_irqrestore(iommu-register_lock, flags);
}
-#else
-static void dma_msi_addr_init(struct iommu *iommu, int phy_cpu)
-{
-/* ia64: TODO */
-}
-#endif
static void dma_msi_set_affinity(unsigned int vector, cpumask_t dest)
{
@@ -988,7 +982,6 @@ static int intel_iommu_domain_init(struc
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
struct iommu *iommu = NULL;
-u64 i, j, tmp;
struct acpi_drhd_unit *drhd;
drhd = list_entry(acpi_drhd_units.next, typeof(*drhd), list);
@@ -1000,17 +993,8 @@ static int intel_iommu_domain_init(struc
{
extern int xen_in_range(paddr_t start, paddr_t end);
-/* Set up 1:1 page table for dom0 for all RAM except Xen bits. */
-for ( i = 0; i max_page; i++ )
-{
-if ( !page_is_conventional_ram(i) ||
- xen_in_range(i PAGE_SHIFT, (i + 1) PAGE_SHIFT) )
-continue;
-
-tmp = 1 (PAGE_SHIFT - PAGE_SHIFT_4K);
-for ( j = 0; j tmp; j++ )
-iommu_map_page(d, (i*tmp+j), (i*tmp+j));
-}
+/* Set up 1:1 page table for dom0 */
+iommu_set_dom0_mapping(d);
setup_dom0_devices(d);
setup_dom0_rmrr(d);
diff -r 09a6fa059b37 xen/drivers/passthrough/vtd/x86/vtd.c
--- a/xen/drivers/passthrough/vtd/x86/vtd.c Fri Feb 13 09:48:56 2009 +
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c Tue Feb 17 11:28:57 2009 +0800
@@ -143,3 +143,23 @@ void hvm_dpci_isairq_eoi(struct domain *
}
RE: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status --- Dom0 Crash
Hi, Isaku All The attached patch should fix the weird issue. In upstream, we also find some other weird issues, for example, we can't boot dom0 on some platforms, and dom0 may have different behavior with different initrds. After debug, I found it should be caused by incorrect setting for pirq_needs_eoi page. There are two main issues found during the debug: 1. the related two hypercalls are not enabled in the correct way, so dom0 and hypervisor doesn't have the agreement on which pirq needs EOI. 2. the page is not really linked to bss section even if this is the must, so kernel deems it as memory cache and uses it for many ways, and finally leads to varid issues. Thanks Xiantao You, Yongkang wrote: I tried 2048M (and other value), but I wasn't reproduce it. Hmm, does it reproduce with dom0_mem=2048M on all boxes which you tested? Isaku/All, This issue is really very hard to locate. Now I am a little suspecting it is related with building process, as if changing building method, this issue is gone too. 1, It doesn't happen to all machines. But it can be stably reproduce in our nightly test machine with same binary. 2, When system crashing, dom0_mem is set to 2048M. And if using other memory size, this issue disappeared too. 3, It seems happened between dom0 changeset 743~753, as it workds if we use old built Dom0 kernel + new Xen. And the old nightly testing doesn't have issue. 4, When I try to do regression testing between 743~753, I found different build method might cause crashing and non-crashing. In our default building process, as stubdomain is not supported in IA64, so we removed install-stubdom and dist-stubdom from install: and dist: lines in main Makefile. It has been changed more than 2 months. The real compiling command is make -j3 xyz_file. And the crashing issue is related with building process. When I do regression testing, sometimes I didn't change Makefile, but still use make -j3. Then the crashing is gone. I am not sure if my suspection is possible, as it still need more trying. Compiling Dom0 is not easy like Xen. It is costing. I would try to do more, but maybe not so quick, as many another things need to do at the same time. If the default compilation is okay, do you think it is worthy to do more investigating? Any suggestion will be much appreciated. Best Regards, Yongkang You On Tuesday, December 16, 2008 10:22 AM, Isaku Yamahata wrote: On Tue, Dec 09, 2008 at 05:56:25PM +0800, You, Yongkang wrote: On Monday, December 08, 2008 2:10 PM, Isaku Yamahata wrote: On Mon, Dec 08, 2008 at 01:52:38PM +0800, Zhang, Jingke wrote: Isaku Yamahata wrote: On Mon, Dec 08, 2008 at 11:31:15AM +0800, Zhang, Jingke wrote: Hi Isaku, We re-get the detail information from serial port, please see below. Two comments add: Thank you. 1. We can be sure the Cset#18832 works well on the same tiger4 machine. But we did not do regression test between 18832 and this 18860. 2. It is strange that on another Tiger4 box, dom0 will NOT crash. Do you have any idea from the serial log? Thanks! I haven't hit this crash. And Kuwamura-san's test seems that he haven't hit it either. Kuwamura-san, is it correct? Hmm... it seems to depend on hw configuration? I'm inclined to suspect masking/unmasking interruption race. event channel issues? But that's just only my very vague guess. The difference between 18832 and 18860 means the merging xen-unstable into xen-ia64-unstable. Looking the log, I suspect linux-2.6.18-xen instead of xen. Could you provide the linux c/s which corresponds to 18832 and 18860? Hi Isaku, Yes, some of our machines do not crash. I am afraid there may be some potential issue. By testing 18832, we use linux#742. While 18860 uses linux#753. Thanks! Thank you. Taking rough look at them those change sets doesn't seem culprit. I agree with you that this may indicate some potential bugs... Hi All, This bug is stably reproduced, if providing dom0_mem=2048M in append option. And if setting dom0_mem to 1024M or 4096M, the crashing doesn't happen. We tried #18869 Xen + #742 Dom0, system is okay. So the problem might be in Linux tree between #742~#753 I tried 2048M (and other value), but I wasn't reproduce it. Hmm, does it reproduce with dom0_mem=2048M on all boxes which you tested? thanks, ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel fix_pirq_eoi_page.patch Description: fix_pirq_eoi_page.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status --- Dom0 Crash
Isaku Yamahata wrote: Hi. Good catch. Some comments. I attached two patches to fix, could you try them? - bss.page_aligned. Where is the section used? grep didn't tell me. Surely x86 uses .bss.page_aligned in linux/arch/[i386, x86_64]/kernel/head[-xen].S, but no files unuder linux/arch/ia64/ don't use it. You may need to check drivers/xen/core/evtchn.c, the code as following :-) Xiantao static int pirq_eoi_does_unmask; static DECLARE_BITMAP(pirq_needs_eoi, ALIGN(NR_PIRQS, PAGE_SIZE * 8)) __attribute__ ((__section__(.bss.page_aligned), __aligned__(PAGE_SIZE))); - ia64_fast_eoi. I suppose ia64_fast_eoi is used for optimization instead of PHYSDEVOP_eoi. I'm not sure how much improvement it provides, though. Anyway ia64_fast_eoi hypercall implementation should also be updated which I overlooked when I added PHYSDEVOP_pirq_eoi_gmfn support. thanks, On Sun, Jan 04, 2009 at 06:05:07PM +0800, Zhang, Xiantao wrote: Hi, Isaku All The attached patch should fix the weird issue. In upstream, we also find some other weird issues, for example, we can't boot dom0 on some platforms, and dom0 may have different behavior with different initrds. After debug, I found it should be caused by incorrect setting for pirq_needs_eoi page. There are two main issues found during the debug: 1. the related two hypercalls are not enabled in the correct way, so dom0 and hypervisor doesn't have the agreement on which pirq needs EOI. 2. the page is not really linked to bss section even if this is the must, so kernel deems it as memory cache and uses it for many ways, and finally leads to varid issues. Thanks Xiantao You, Yongkang wrote: I tried 2048M (and other value), but I wasn't reproduce it. Hmm, does it reproduce with dom0_mem=2048M on all boxes which you tested? Isaku/All, This issue is really very hard to locate. Now I am a little suspecting it is related with building process, as if changing building method, this issue is gone too. 1, It doesn't happen to all machines. But it can be stably reproduce in our nightly test machine with same binary. 2, When system crashing, dom0_mem is set to 2048M. And if using other memory size, this issue disappeared too. 3, It seems happened between dom0 changeset 743~753, as it workds if we use old built Dom0 kernel + new Xen. And the old nightly testing doesn't have issue. 4, When I try to do regression testing between 743~753, I found different build method might cause crashing and non-crashing. In our default building process, as stubdomain is not supported in IA64, so we removed install-stubdom and dist-stubdom from install: and dist: lines in main Makefile. It has been changed more than 2 months. The real compiling command is make -j3 xyz_file. And the crashing issue is related with building process. When I do regression testing, sometimes I didn't change Makefile, but still use make -j3. Then the crashing is gone. I am not sure if my suspection is possible, as it still need more trying. Compiling Dom0 is not easy like Xen. It is costing. I would try to do more, but maybe not so quick, as many another things need to do at the same time. If the default compilation is okay, do you think it is worthy to do more investigating? Any suggestion will be much appreciated. Best Regards, Yongkang You On Tuesday, December 16, 2008 10:22 AM, Isaku Yamahata wrote: On Tue, Dec 09, 2008 at 05:56:25PM +0800, You, Yongkang wrote: On Monday, December 08, 2008 2:10 PM, Isaku Yamahata wrote: On Mon, Dec 08, 2008 at 01:52:38PM +0800, Zhang, Jingke wrote: Isaku Yamahata wrote: On Mon, Dec 08, 2008 at 11:31:15AM +0800, Zhang, Jingke wrote: Hi Isaku, We re-get the detail information from serial port, please see below. Two comments add: Thank you. 1. We can be sure the Cset#18832 works well on the same tiger4 machine. But we did not do regression test between 18832 and this 18860. 2. It is strange that on another Tiger4 box, dom0 will NOT crash. Do you have any idea from the serial log? Thanks! I haven't hit this crash. And Kuwamura-san's test seems that he haven't hit it either. Kuwamura-san, is it correct? Hmm... it seems to depend on hw configuration? I'm inclined to suspect masking/unmasking interruption race. event channel issues? But that's just only my very vague guess. The difference between 18832 and 18860 means the merging xen-unstable into xen-ia64-unstable. Looking the log, I suspect linux-2.6.18-xen instead of xen. Could you provide the linux c/s which corresponds to 18832 and 18860? Hi Isaku, Yes, some of our machines do not crash. I am afraid there may be some potential issue. By testing 18832, we use linux#742. While 18860 uses linux#753. Thanks! Thank you. Taking rough look at them those change sets doesn't seem culprit. I agree with you that this may indicate some potential bugs... Hi All
RE: [Xen-ia64-devel] [Test Report] Xen/IPF Unstable CS#18860 Status --- Dom0 Crash
Isaku Yamahata wrote: On Mon, Jan 05, 2009 at 12:29:55PM +0800, Zhang, Xiantao wrote: Isaku Yamahata wrote: Hi. Good catch. Some comments. I attached two patches to fix, could you try them? - bss.page_aligned. Where is the section used? grep didn't tell me. Surely x86 uses .bss.page_aligned in linux/arch/[i386, x86_64]/kernel/head[-xen].S, but no files unuder linux/arch/ia64/ don't use it. You may need to check drivers/xen/core/evtchn.c, the code as following :-) Xiantao static int pirq_eoi_does_unmask; static DECLARE_BITMAP(pirq_needs_eoi, ALIGN(NR_PIRQS, PAGE_SIZE * 8)) __attribute__ ((__section__(.bss.page_aligned), __aligned__(PAGE_SIZE))); Ah, that line was deleted by the chageset of 760:0d10be086a78 Oh, I haven't notice the check-in due to my old codebase. It introduces many odd issues to us. Okay, it is also good to remove it. :) For adopting fast eoi path, it should be okay to me. Please check-in them. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] A patch to fix mis-setting ed bit for itlb entry.
Hi, Isaku
When debugging a windows BSOD issue, we found it is caused by mis-setting
pte's ED bit for itlb entry. For hash vTLB, it uses unified tlb and doesn't
differentiate itc and dtc in its implementation, so itlb_miss handler may
reference dtlb entry in hash vTLB. But it may result in issues, because dtlb's
ED bit may be different with itlb's setting. Since the case is very rare, so
just purge the corresponding entry in hash vTLB and let guest OS to determin
how to set ED bit for itlb mapping once found it.
Xiantao
Signed-off-by : Xiantao Zhang xiantao.zh...@intel.com
diff -r e97216802360 xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Fri Dec 12 10:43:39 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Sun Jan 04 10:43:19 2009 +0800
@@ -678,11 +678,20 @@ thash_data_t *vtlb_lookup(VCPU *v, u64 v
cch = vtlb_thash(hcb-pta, va, vrr.rrval, tag);
do {
if (cch-etag == tag cch-ps == ps)
-return cch;
+goto found;
cch = cch-next;
} while(cch);
}
return NULL;
+found:
+if (is_data == ISIDE_TLB !cch-ed) {
+ /*The case is very rare, and it may lead to incorrect setting
+ for itlb's ed bit! Purge it from hash vTLB and let guest os
+ determin the ed bit of the itlb entry.*/
+ vtlb_purge(v, va, ps);
+ cch = NULL;
+}
+return cch;
}
fix_itlb_ed.patch
Description: fix_itlb_ed.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
Isaku Yamahata wrote: On Thu, Dec 11, 2008 at 09:07:15AM -0700, Alex Williamson wrote: On Thu, 2008-12-11 at 09:04 -0700, Alex Williamson wrote: On Thu, 2008-12-11 at 11:05 +0900, Isaku Yamahata wrote: Just to make sure. Is fpswa.efi installed in hvm domain? You can also confirm it by dh command in efi shell. Argh, that was it. I loaded fpswa.efi into my EFI partition after the tests started failing, but I didn't have it in the right location for elilo to pick it up automatically. Running load fpswa.efi makes it work, and copying fpswa.efi to \efi\intel firmware\fpswa.efi also works. I'll add your panic fix and let it run for a while, seems like it's running well now. Thanks, Thank you for testing. I'll commit my patches with some clean up. One other comment on the patches, I'd recommend removing both instances of this: printk(ia64_handle_reflection: handling FP trap\n); from ia64_handle_reflection(). If we're properly handling the trap, this is just unnecessary noise. Thanks, Agreed. It should be quietened somehow. Good news indeed! Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
Isaku Yamahata wrote: On Wed, Dec 10, 2008 at 10:43:01AM -0700, Alex Williamson wrote: On Tue, 2008-12-09 at 21:23 -0700, Alex Williamson wrote: On Wed, 2008-12-10 at 10:51 +0800, Zhang, Xiantao wrote: I've been testing this for a few hours today (over 25k iterations) and it seems to fix the problem for me. Thanks! Hi, Alex Have you verified vmx domain as well ? Good point, no I was just testing in dom0. Adding in Isaku's last patch and testing on an HVM domain, it doesn't take long to hit problems. 4-way/4G HVM guest running 4 instances of the test program in parallel will eventually get this in the guest kernel: handle_fpu_swa: fp_emulate() returned -1 and the test program gets killed with a SIGFPE. Just to make sure. Is fpswa.efi installed in hvm domain? You can also confirm it by dh command in efi shell. Yes, I think it should be installed by default in OS distros. Before handing the trap in hypervisor, all traps are injected to guests, and handing it in hypervisor is just an optimization. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
Alex Williamson wrote: On Tue, 2008-12-09 at 18:29 +0900, Isaku Yamahata wrote: Hi. This patch series addresses the bug reported as http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392 Please test it. It includes some clean ups and a reimplementation of fpswa hypercall. When fp fault/trap occurs, xen vmm tries to get a bundle in question from guest virtual address space. It sometimes fails because of I/D tlb cache. In that case inject the fault/trap into a guest and let a guest to call fpswa hypercall. Hi Isaku, I've been testing this for a few hours today (over 25k iterations) and it seems to fix the problem for me. Thanks! Hi, Alex Have you verified vmx domain as well ? Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]
Isaku Yamahata wrote:
On Fri, Dec 05, 2008 at 04:02:51PM +0900, Isaku Yamahata wrote:
On Fri, Dec 05, 2008 at 02:36:25PM +0800, Zhang, Xiantao wrote:
Isaku Yamahata wrote:
For those who want to test it, here is the slightly update patch.
NOTE: this version doesn't solve the potential infinite loop
which Alex is suspecting about.
IA64: fix emulation of fp emulation
This patch fixes bug reported as
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392
When pv domain case, FPSWA hypercall isn't implemented properly.
So avoid the injecting floating point fault/trap at this moment.
However this may cause infinite loop depending on dtlb cache.
The right fix is to implement the hypercall properly however
it wouldn't be very straight forward because the argument
of fpswa is large and includes pointers.
When hvm domain case, floating point trap case iip was incremented
improperly. removed the increment
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/xen/arch/ia64/vmx/vmx_fault.c
b/xen/arch/ia64/vmx/vmx_fault.c --- a/xen/arch/ia64/vmx/vmx_fault.c
+++ b/xen/arch/ia64/vmx/vmx_fault.c
@@ -130,10 +130,8 @@ void vmx_reflect_interruption(u64 ifa, u
status = handle_fpu_swa(0, regs, isr);
if (!status)
return;
-else if (IA64_RETRY == status) {
-vcpu_decrement_iip(vcpu);
+else if (IA64_RETRY == status)
return;
-}
break;
case 29: // IA64_DEBUG_VECTOR
Hi, Isaku
Why do you think the decrement is useless ? For trap case, the
iip should point to the next instruction instead of the one which
results in the trap. So once need retry, the iip should be back to
the privious one ?
Ouch, you are correct.
When I compared the handler with Linux one, I was confused.
Hmm, more thoughts.
Trap means that the instruction was already executed, so backing iip
means the instruction will be executed twice.
The result would be wrong. For example, how about if the destination
register is one of the source register.
(Or is it safe to execute the instruction twice given that
FP trap was triggered? I'm not sure about such a corner case. need
to dig into the specs...)
Oh, that maybe a potential issue we didn't sense it before.
If we fail to get a bundle in a guest when FP trap,
we can't reexecute the instruction. We have to inject floating
point trap into guest.
For HVM, injecting it to guest should be the right way to go.
Arrg, so FPSWA hypercall has to be implemented correctly?
What about HVM domain case?
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]
Isaku Yamahata wrote:
For those who want to test it, here is the slightly update patch.
NOTE: this version doesn't solve the potential infinite loop
which Alex is suspecting about.
IA64: fix emulation of fp emulation
This patch fixes bug reported as
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392
When pv domain case, FPSWA hypercall isn't implemented properly.
So avoid the injecting floating point fault/trap at this moment.
However this may cause infinite loop depending on dtlb cache.
The right fix is to implement the hypercall properly however
it wouldn't be very straight forward because the argument
of fpswa is large and includes pointers.
When hvm domain case, floating point trap case iip was incremented
improperly. removed the increment
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/xen/arch/ia64/vmx/vmx_fault.c
b/xen/arch/ia64/vmx/vmx_fault.c --- a/xen/arch/ia64/vmx/vmx_fault.c
+++ b/xen/arch/ia64/vmx/vmx_fault.c
@@ -130,10 +130,8 @@ void vmx_reflect_interruption(u64 ifa, u
status = handle_fpu_swa(0, regs, isr);
if (!status)
return;
-else if (IA64_RETRY == status) {
-vcpu_decrement_iip(vcpu);
+else if (IA64_RETRY == status)
return;
-}
break;
case 29: // IA64_DEBUG_VECTOR
Hi, Isaku
Why do you think the decrement is useless ? For trap case, the iip should
point to the next instruction instead of the one which results in the trap. So
once need retry, the iip should be back to the privious one ?
Thanks
Xiantao
diff --git a/xen/arch/ia64/xen/faults.c b/xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.c
+++ b/xen/arch/ia64/xen/faults.c
@@ -318,6 +318,7 @@ handle_fpu_swa(int fp_fault, struct pt_r
IA64_BUNDLE bundle;
unsigned long fault_ip;
fpswa_ret_t ret;
+ unsigned long rc;
fault_ip = regs-cr_iip;
/*
@@ -328,16 +329,15 @@ handle_fpu_swa(int fp_fault, struct pt_r
if (!fp_fault (ia64_psr(regs)-ri == 0))
fault_ip -= 16;
- if (VMX_DOMAIN(current)) {
- if (IA64_RETRY == __vmx_get_domain_bundle(fault_ip, bundle))
- return IA64_RETRY;
- } else
- bundle = __get_domain_bundle(fault_ip);
-
- if (!bundle.i64[0] !bundle.i64[1]) {
- printk(%s: floating-point bundle at 0x%lx not mapped\n,
-__FUNCTION__, fault_ip);
- return -1;
+ if (VMX_DOMAIN(current))
+ rc = __vmx_get_domain_bundle(fault_ip, bundle);
+ else
+ rc = __get_domain_bundle(fault_ip, bundle);
+ if (rc == IA64_RETRY) {
+ gdprintk(XENLOG_DEBUG,
+ %s(%s): floating-point bundle at 0x%lx not mapped\n,
+ __FUNCTION__, fp_fault ? fault : trap, fault_ip);
+ return IA64_RETRY;
}
ret = fp_emulate(fp_fault, bundle, regs-cr_ipsr, regs-ar_fpsr,
diff --git a/xen/arch/ia64/xen/vcpu.c b/xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c
+++ b/xen/arch/ia64/xen/vcpu.c
@@ -1325,6 +1325,16 @@ static TR_ENTRY *vcpu_tr_lookup(VCPU * v
return NULL;
}
+unsigned long
+__get_domain_bundle(unsigned long iip, IA64_BUNDLE *bundle)
+{
+ *bundle = __get_domain_bundle_asm(iip);
+ if (!bundle-i64[0] !bundle-i64[1])
+ return IA64_RETRY;
+
+ return 0;
+}
+
// return value
// 0: failure
// 1: success
@@ -1335,6 +1345,7 @@ vcpu_get_domain_bundle(VCPU * vcpu, REGS
u64 gpip; // guest pseudo phyiscal ip
unsigned long vaddr;
struct page_info *page;
+ unsigned long rc;
again:
#if 0
@@ -1387,11 +1398,11 @@ vcpu_get_domain_bundle(VCPU * vcpu, REGS
if (swap_rr0) {
set_virtual_rr0();
}
- *bundle = __get_domain_bundle(gip);
+ rc = __get_domain_bundle(gip, bundle);
if (swap_rr0) {
set_metaphysical_rr0();
}
- if (bundle-i64[0] == 0 bundle-i64[1] == 0) {
+ if (rc == IA64_RETRY) {
dprintk(XENLOG_INFO, %s gip 0x%lx\n, __func__, gip);
return 0;
}
diff --git a/xen/arch/ia64/xen/xenasm.S b/xen/arch/ia64/xen/xenasm.S
--- a/xen/arch/ia64/xen/xenasm.S
+++ b/xen/arch/ia64/xen/xenasm.S
@@ -389,7 +389,7 @@ END(ia64_prepare_handle_reflection)
END(ia64_prepare_handle_reflection)
#endif
-GLOBAL_ENTRY(__get_domain_bundle)
+GLOBAL_ENTRY(__get_domain_bundle_asm)
EX(.failure_in_get_bundle,ld8 r8=[r32],8)
;;
EX(.failure_in_get_bundle,ld8 r9=[r32])
@@ -403,7 +403,7 @@ GLOBAL_ENTRY(__get_domain_bundle)
;;
br.ret.sptk.many rp
;;
-END(__get_domain_bundle)
+END(__get_domain_bundle_asm)
/* derived from linux/arch/ia64/hp/sim/boot/boot_head.S */
[Xen-ia64-devel] [PATCH] Fix a bug for XEN_VIRT_UC_BIT use.
Fix a bug for XEN_VIRT_UC_BIT use. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] diff -r 9bc00e9716cd xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 19:34:59 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Mon Nov 17 11:12:58 2008 +0800 @@ -314,7 +314,7 @@ vmx_alt_itlb_miss_vmm: movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; and r19=r19,r16 // clear ed, reserved bits, and PTE control bits -extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit +extr.u r18=r16,XEN_VIRT_UC_BIT, 1// extract UC bit ;; or r19=r17,r19 // insert PTE control bits into r19 mov r20=IA64_GRANULE_SHIFT2 Fix-XEN_VIRT_UC_BIT-use.patch Description: Fix-XEN_VIRT_UC_BIT-use.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix a bug for XEN_VIRT_UC_BIT use.
Yes, only bit 0 is used for dep. Xiantao Isaku Yamahata wrote: Hi. This patch itself looks okay. Just for confirming. This patch doesn't affect the result because the following line sees only the lsb 0 bit of r18. Correct? extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit ... dep r19=r18,r19,4,1 // set bit 4 (uncached) if the access was to UC region On Mon, Nov 17, 2008 at 11:20:49AM +0800, Zhang, Xiantao wrote: Fix a bug for XEN_VIRT_UC_BIT use. Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] diff -r 9bc00e9716cd xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.SFri Nov 07 19:34:59 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.SMon Nov 17 11:12:58 2008 +0800 @@ -314,7 +314,7 @@ vmx_alt_itlb_miss_vmm: movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; and r19=r19,r16 // clear ed, reserved bits, and PTE control bits -extr.u r18=r16,XEN_VIRT_UC_BIT, 15// extract UC bit +extr.u r18=r16,XEN_VIRT_UC_BIT, 1// extract UC bit ;; or r19=r17,r19 // insert PTE control bits into r19 mov r20=IA64_GRANULE_SHIFT2 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Okay, Updated :) Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 16:35:55 2008 +0800 @@ -343,7 +343,7 @@ END(vmx_alt_itlb_miss) // 0x1000 Entry 4 (size 64 bundles) Alt DTLB (7,46) ENTRY(vmx_alt_dtlb_miss) VMX_DBG_FAULT(4) -mov r29=cr.ipsr +mov r29=cr.ipsr//frametable_miss needs ipsr is saved in r29. mov r31=pr adds r22=IA64_VCPU_MMU_MODE_OFFSET, r21 ;; @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr is saved in r29 #endif movl r17=PAGE_KERNEL mov r20=cr.isr diff -r f6795589ef82 xen/arch/ia64/xen/ivt.S --- a/xen/arch/ia64/xen/ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/xen/ivt.S Fri Nov 07 16:35:55 2008 +0800 @@ -184,10 +184,12 @@ late_alt_dtlb_miss: late_alt_dtlb_miss: mov r20=cr.isr movl r17=PAGE_KERNEL - mov r21=cr.ipsr + mov r29=cr.ipsr // frametable_miss is shared by paravirtual and HVM sides + // and it assumes ipsr is saved in r29. If change the + // registers usage here, please check both sides! movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; - extr.u r23=r21,IA64_PSR_CPL0_BIT,2 // extract psr.cpl + extr.u r23=r29,IA64_PSR_CPL0_BIT,2 // extract psr.cpl and r22=IA64_ISR_CODE_MASK,r20 // get the isr.code field tbit.nz p6,p7=r20,IA64_ISR_SP_BIT // is speculation bit on? extr.u r18=r16,XEN_VIRT_UC_BIT,1// extract UC bit @@ -234,7 +236,7 @@ late_alt_dtlb_miss: br.cond.spnt page_fault ;; alt_dtlb_miss_identity_map: - dep r21=-1,r21,IA64_PSR_ED_BIT,1 + dep r29=-1,r29,IA64_PSR_ED_BIT,1 or r19=r19,r17 // insert PTE control bits into r19 mov cr.itir=r20 // set itir with cleared key ;; @@ -243,7 +245,7 @@ alt_dtlb_miss_identity_map: cmp.eq.or p8,p0=0x18,r22// Region 6 is UC for EFI ;; (p8) dep r19=-1,r19,4,1 // set bit 4 (uncached) if access to UC area -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 ;; (p7) itc.d r19 // insert the TLB entry mov pr=r31,-1 @@ -288,17 +290,17 @@ GLOBAL_ENTRY(frametable_miss) rfi END(frametable_miss) -ENTRY(frametable_fault) +ENTRY(frametable_fault)//ipsr saved in r29 before coming here! ssm psr.dt // switch to using virtual data addressing mov r18=cr.iip movl r19=ia64_frametable_probe ;; cmp.eq p6,p7=r18,r19// is faulting addrress ia64_frametable_probe? mov r8=0// assumes that 'probe.r' uses r8 - dep r21=-1,r21,IA64_PSR_RI_BIT+1,1 // return to next instruction in + dep r29=-1,r29,IA64_PSR_RI_BIT+1,1 // return to next instruction in // bundle 2 ;; -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 mov r19=4 // FAULT(4) (p7) br.spnt.few dispatch_to_fault_handler ;; Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 03:47:10PM +0800, Zhang, Xiantao wrote: Hi, Isaku Attached patch should fix the issue. Paravirtualized ivt and HVM ivt share the code for frametable_miss handling, but they have different assumptions for registers useage. IPSR is savded in r21 at paravirtualized side, but r29 is used for HVM side. This patch uniform them to use r29 for ipsr save. Oh great! That explains why mfn_valid() didn't work and the patch looks good. Could you please add the comment above late_alt_dtlb_miss why the r29 is used instead of r21 in ivt.S? thanks, Thanks Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.SThu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.SFri Nov 07 15:31:26 2008 +0800 @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr
[Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); vti-broken.patch Description: vti-broken.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.cThu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.cFri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 11:33:43AM +0800, Zhang, Xiantao wrote: But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? mfn_valid() with invalid parameter shouldn't cause panic. It may cause tlb miss fault, but the fault should be handled specially by frametable_fault in ivt.S and should be recovered resulting in mfn_valid() returning false. I agree with you that there's something wrong in mfn_valid() I haven't aware of the issue. Okay, if so, frametable_fault maybe not handled in a correct way in vmx_ivt.S. Xiantao thanks, Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(pte_pfn(__pte(pte))) phy_pte.ma != VA_MATTR_NATPAGE) +if (mfn_valid(pte_pfn(__pte(maddr))) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue.
Hi, Isaku Attached patch should fix the issue. Paravirtualized ivt and HVM ivt share the code for frametable_miss handling, but they have different assumptions for registers useage. IPSR is savded in r21 at paravirtualized side, but r29 is used for HVM side. This patch uniform them to use r29 for ipsr save. Thanks Xiantao PATCH: Fix frametable_miss handling for HVM guests. For hvm guests, hypervisor use mfn_valid to check mfn, but it will incur weird faults. It is becasue ipsr is saved in r29, but frametalbe miss assumes saved in r21. Signed-off-by Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Fri Nov 07 15:31:26 2008 +0800 @@ -356,7 +356,7 @@ vmx_alt_dtlb_miss_vmm: // Test for the address of virtual frame_table shr r22=r16,56;; cmp.eq p8,p0=((VIRT_FRAME_TABLE_ADDR56)0xff)-0x100,r22 -(p8)br.cond.sptk frametable_miss ;; +(p8)br.cond.sptk frametable_miss ;; //Make sure ipsr is saved in r29 #endif movl r17=PAGE_KERNEL mov r20=cr.isr diff -r f6795589ef82 xen/arch/ia64/xen/ivt.S --- a/xen/arch/ia64/xen/ivt.S Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/xen/ivt.S Fri Nov 07 15:31:26 2008 +0800 @@ -184,10 +184,10 @@ late_alt_dtlb_miss: late_alt_dtlb_miss: mov r20=cr.isr movl r17=PAGE_KERNEL - mov r21=cr.ipsr + mov r29=cr.ipsr movl r19=(((1 IA64_MAX_PHYS_BITS) - 1) ~0xfff) ;; - extr.u r23=r21,IA64_PSR_CPL0_BIT,2 // extract psr.cpl + extr.u r23=r29,IA64_PSR_CPL0_BIT,2 // extract psr.cpl and r22=IA64_ISR_CODE_MASK,r20 // get the isr.code field tbit.nz p6,p7=r20,IA64_ISR_SP_BIT // is speculation bit on? extr.u r18=r16,XEN_VIRT_UC_BIT,1// extract UC bit @@ -234,7 +234,7 @@ late_alt_dtlb_miss: br.cond.spnt page_fault ;; alt_dtlb_miss_identity_map: - dep r21=-1,r21,IA64_PSR_ED_BIT,1 + dep r29=-1,r29,IA64_PSR_ED_BIT,1 or r19=r19,r17 // insert PTE control bits into r19 mov cr.itir=r20 // set itir with cleared key ;; @@ -243,7 +243,7 @@ alt_dtlb_miss_identity_map: cmp.eq.or p8,p0=0x18,r22// Region 6 is UC for EFI ;; (p8) dep r19=-1,r19,4,1 // set bit 4 (uncached) if access to UC area -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 ;; (p7) itc.d r19 // insert the TLB entry mov pr=r31,-1 @@ -288,17 +288,17 @@ GLOBAL_ENTRY(frametable_miss) rfi END(frametable_miss) -ENTRY(frametable_fault) +ENTRY(frametable_fault)//ipsr saved in r29 before coming here! ssm psr.dt // switch to using virtual data addressing mov r18=cr.iip movl r19=ia64_frametable_probe ;; cmp.eq p6,p7=r18,r19// is faulting addrress ia64_frametable_probe? mov r8=0// assumes that 'probe.r' uses r8 - dep r21=-1,r21,IA64_PSR_RI_BIT+1,1 // return to next instruction in + dep r29=-1,r29,IA64_PSR_RI_BIT+1,1 // return to next instruction in // bundle 2 ;; -(p6) mov cr.ipsr=r21 +(p6) mov cr.ipsr=r29 mov r19=4 // FAULT(4) (p7) br.spnt.few dispatch_to_fault_handler ;; Isaku Yamahata wrote: On Fri, Nov 07, 2008 at 11:33:43AM +0800, Zhang, Xiantao wrote: But another thing to meation, why mfn_valid with invalid parameter will incur the fault? Seems mfn_valid has something wrong, I have no enough time to find the cause. Is it a known issue ? Or mfn_valid has some limitation ? mfn_valid() with invalid parameter shouldn't cause panic. It may cause tlb miss fault, but the fault should be handled specially by frametable_fault in ivt.S and should be recovered resulting in mfn_valid() returning false. I agree with you that there's something wrong in mfn_valid() I haven't aware of the issue. thanks, Thanks Xiantao Zhang, Xiantao wrote: Yes. Should be addressed. -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2008 11:03 AM To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Fix vti guests broken issue. Oh, my bad. Thank you for debugging. I applied and pushed out. Does this fixed the issue you repoted? thanks, On Fri, Nov 07, 2008 at 10:42:57AM +0800, Zhang, Xiantao wrote: PATCH : Fix vti guests broken issue. mfn_valid should use machine physical pfn, not guest physical pfn. Sign-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r f6795589ef82 xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Nov 06 12:14:57 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Fri Nov 07 10:35:11 2008 +0800 @@ -522,7 +522,7 @@ static u64 translate_phy_pte(VCPU *v, u6 * which
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Isaku Yamahata wrote: On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote: Hi all, There is one new regression in Cset#18691. With latest Cset#18694, all the case can pass! One regression between Cset#18688 and Cset#18691: == 1. Qemu graphic mode display abnormally while booting VTI_Windows and Linux-Xwin. This issue existed in either sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688. Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure. Hi, Isaku We found the cause,maybe rootcause. 18669 may has a poetentail issue, but doesn't lead to the issue. We found valid_mfn() doesn't work in its way, and seems it is buggy. I have no enough time to debug it, but the following patch should fix the current issue. diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma == VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Zhang, Xiantao wrote: Isaku Yamahata wrote: On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote: Hi all, There is one new regression in Cset#18691. With latest Cset#18694, all the case can pass! One regression between Cset#18688 and Cset#18691: == 1. Qemu graphic mode display abnormally while booting VTI_Windows and Linux-Xwin. This issue existed in either sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688. Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure. Hi, Isaku We found the cause,maybe rootcause. 18669 may has a poetentail issue, but doesn't lead to the issue. We found valid_mfn() doesn't work in its way, and seems it is buggy. I have no enough time to debug it, but the following patch should fix the current issue. diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma == VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); Xiantao Oops. .. Forget to rebase to tip. Should be: diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 14:13:27 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
I found the reason why mfn_valid behaves abnormally. We should mask out
TLB_TRACK bits from p2m entry before using it as mfn_valid's parameter.
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
Zhang, Xiantao wrote:
Isaku Yamahata wrote:
On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote:
Hi all,
There is one new regression in Cset#18691. With latest
Cset#18694, all the case can pass!
One regression between Cset#18688 and Cset#18691: ==
1. Qemu graphic mode display abnormally while booting
VTI_Windows and Linux-Xwin. This issue existed in either
sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688.
Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure.
Hi, Isaku
We found the cause,maybe rootcause. 18669 may has a poetentail
issue, but doesn't lead to the issue. We found valid_mfn() doesn't
work in its way, and seems it is buggy. I have no enough time to
debug it, but the following patch should fix the current issue.
diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800
@@ -522,7 +522,7 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma ==
VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma ==
VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr
~PAGE_MASK);
Xiantao
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
fix-vga-abnormal.patch
Description: fix-vga-abnormal.patch
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706, ioemu#b4d410a1.. Status --- 1 new
Here it is! :)
PATCH: Fix HVM VGA abnormal.
Conversion from p2m entry to physical address, it needs to use
_PAGE_PPN_MASK to mask out some bits which are used by other
purposes by p2m entry.
Sign-off-by : Xiantao Zhang [EMAIL PROTECTED]
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.cThu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
-Original Message-
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: Friday, October 31, 2008 9:46 AM
To: Zhang, Xiantao
Cc: Zhang, Jingke; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18694, Linux#706,
ioemu#b4d410a1.. Status --- 1 new
Oh great. Thank you for debugging.
Could you provide your signed-off-by?
On Thu, Oct 30, 2008 at 11:07:56PM +0800, Zhang, Xiantao wrote:
I found the reason why mfn_valid behaves abnormally. We should mask out
TLB_TRACK bits from p2m entry before using it as mfn_valid's parameter.
diff -r 4a5acf020c0f xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.cThu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.cThu Oct 30 21:57:38 2008 +0800
@@ -522,7 +522,8 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE)
+if (mfn_valid((maddr _PAGE_PPN_MASK) PAGE_SHIFT)
+ phy_pte.ma != VA_MATTR_NATPAGE)
phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
diff -r 4a5acf020c0f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Thu Oct 30 11:51:55 2008 +0900
+++ b/xen/arch/ia64/xen/mm.c Thu Oct 30 21:57:38 2008 +0800
@@ -926,7 +926,8 @@
/* in HVM guest, when VTD is enabled,
* P2M entry may change from _PAGE_IO type to real MMIO page
*/
-if(VMX_DOMAIN(d-vcpu[0]) (pte_val(ret_pte) _PAGE_IO)) {
+if(is_hvm_domain(d) (pte_val(ret_pte) _PAGE_IO)
+ !mfn_valid(physaddr PAGE_SHIFT)) {
old_pte = ret_pte;
goto again_hvm_page_io;
}
Zhang, Xiantao wrote:
Isaku Yamahata wrote:
On Wed, Oct 29, 2008 at 04:10:50PM +0800, Zhang, Jingke wrote:
Hi all,
There is one new regression in Cset#18691. With latest
Cset#18694, all the case can pass!
One regression between Cset#18688 and Cset#18691: ==
1. Qemu graphic mode display abnormally while booting
VTI_Windows and Linux-Xwin. This issue existed in either
sdl=1 or vnc=1 mode. And this issue does not exist with Cset#18688.
Hmm, I suspect the change set 18689:7ad8c47f5c4b. But I'm not sure.
Hi, Isaku
We found the cause,maybe rootcause. 18669 may has a poetentail
issue, but doesn't lead to the issue. We found valid_mfn() doesn't
work in its way, and seems it is buggy. I have no enough time to
debug it, but the following patch should fix the current issue.
diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900
+++ b/xen/arch/ia64/vmx/vtlb.c Thu Oct 30 13:47:08 2008 +0800
@@ -522,7 +522,7 @@
* which is required by vga acceleration since qemu maps shared
* vram buffer with WB.
*/
-if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma ==
VA_MATTR_NATPAGE) +if (!(maddr 61) phy_pte.ma ==
VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr
~PAGE_MASK);
Xiantao
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
fix-vga-abnormal.patch
Description: fix-vga-abnormal.patch
[Xen-ia64-devel] PATCH: Fix an memory attribute issue.
PATCH: Fix an memory attribute issue. We should ensure Qemu and Guest use same attribute for accessing the VGA ram, otherwise, host may hang. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] diff -r a6b1be5a83de xen/arch/ia64/vmx/vtlb.c --- a/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 11:02:23 2008 +0900 +++ b/xen/arch/ia64/vmx/vtlb.c Wed Oct 29 16:14:34 2008 +0800 @@ -522,7 +522,7 @@ * which is required by vga acceleration since qemu maps shared * vram buffer with WB. */ -if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma == VA_MATTR_NATPAGE) +if (mfn_valid(maddr PAGE_SHIFT) phy_pte.ma != VA_MATTR_NATPAGE) phy_pte.ma = VA_MATTR_WB; maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK); mem_attr_fix.patch Description: mem_attr_fix.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote: On Tue, Oct 28, 2008 at 12:12:45PM +0900, Isaku Yamahata wrote: I thought Jingke isn't saying this topic. What he found maybe he failed to create the domain when the domain is created and destoryed continuously for more 62 times. Seems the issue is from the the algorithm for deallocating rid blocks doesn't work, when destroying the guest. Oh I see. Thank you for the explanation. Could you try the following patch? IA64: fix XENMEM_add_to_physmap with XENMAPSPACE_mfn. page reference count was leaked so that hvm domain wasn't freed. This patch fixes it. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c --- a/xen/arch/ia64/xen/mm.c +++ b/xen/arch/ia64/xen/mm.c @@ -3365,7 +3365,6 @@ arch_memory_op(int op, XEN_GUEST_HANDLE( /* Map at new location. */ /* Here page-count_info = PGC_allocated | N where N = 1*/ __guest_physmap_add_page(d, xatp.gpfn, mfn); -page = NULL; /* prevent put_page() */ out: domain_unlock(d); Hi, Isuka Good catch! That can explain why deallocation algorithm doesn't work. Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18688, Linux#705, ioemu#629adb3f... Status --- no new issue, report 3 old bugs
Isaku Yamahata wrote: On Fri, Oct 24, 2008 at 09:59:58AM +0800, Zhang, Jingke wrote: 3. IPF-Xen can not boot up domain with dom_id 62 (not regression, should be there for a long time) Long ago, I posted the patch to address this issue. Probably there are two ways. (Is there other better way?) a.) abandon the rid partitioning, and flush mTLB every time vcpu context switch. Current kvm adopts this method, we didn't find any performance regression through benchmark. But sine the architecture difference between xen and kvm, so maybe should investigate more through enough benchmark data. (some bits of rid space needs to be reserved for real mode emulation.) b.) keep the rid partitioning and allow rid collision. When vcpu context switch, check the rid collision and flush mTLB if necessary. Benchmark would be necessary to decide which one is better and to estimate performance degradation. I implemented b). However no one has implemented a). So no further step was taken. I thought Jingke isn't saying this topic. What he found maybe he failed to create the domain when the domain is created and destoryed continuously for more 62 times. Seems the issue is from the the algorithm for deallocating rid blocks doesn't work, when destroying the guest. Xiantao thanks, ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Q] How to download pv_ops git tree
Akio Takebe wrote: Hi, Xiantao-san We also meet the same issue days ago. Maybe you can use the mirror I set up in repo.or.cz. It works well, if you are behind the http_proxy . It is easy to use, clone http://repo.or.cz/w/pv_ops_mirror.git, and checkout the related branches :) Xiantao Thnak you. I could download your git tree with git clone git://repo.or.cz/pv_ops_mirror.git Good news! :) We may be not able to use http protocol of git... Thank you for always helping us. Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Q] How to download pv_ops git tree
Akio Takebe wrote: Hi, Eddie Thank you. I am not a git expert either :( But would you please check if the http_proxy is set correctly? Xiantao'tree support git port I think. Yes, I did export http_proxy=http://xxx.yyy.zzz:;, then git clone, but I cannot download it. I could get index.html with wget http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git; Hi, Akio We also meet the same issue days ago. Maybe you can use the mirror I set up in repo.or.cz. It works well, if you are behind the http_proxy . It is easy to use, clone http://repo.or.cz/w/pv_ops_mirror.git, and checkout the related branches :) Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] GFW release
I checked it at kvm side. It also works well. :) Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Gingold Sent: 2008年3月13日 20:46 To: Xen-ia64-devel Subject: [Xen-ia64-devel] GFW release Hi, I have just updated the GFW binary. Please test it. If it is OK, it will be used for the official GFW release. [ I made this patch before adding INIT support. Should I make a new release ?] Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: tools/ioemu/ia64.ld ?
Aron Griffis wrote: Hi, Does anybody know why xen's ioemu has its own custom linker script? This was inherited from qemu, apparently contributed by David Mosberger over 2 years ago. It's been patched for kvm (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg10306.htm l) but as far as I can see, that's essentially bringing part of it up to date with the default linker script in binutils. Hi, Aron The fix for kvm is just for moving the code section to region 2, and has no other purposes :) I'm asking about this because it's the last thing in the way of a clean cross build of xen tools. You can see the build failure at http://markmail.org/message/zowwwfs3mdipseiv The first failure in that message is because the custom linker script was using the wrong library directories. That is easily fixed. The second build failure is opaque to me: ../../xenstore/libxenstore.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status However, if I comment out the linker script in the Makefile then the build works, and hvm domains seem to run fine built with the default linker script. When I diff ia64.ld to Debian's /usr/lib/ldscripts/elf64_ia64.x I don't see anything significant, but I'm not an expert in this area. Can anybody tell me why we need this? If not, I'll submit a patch to remove it. I guess you can remove it and use the default, since ia64 arch has no special requirment for it. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Hi, Tristan Thank you! Attached. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2008年2月20日 0:40 To: Zhang, Xiantao Cc: Tristan Gingold; xen-ia64-devel Subject: RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use. Quoting Zhang, Xiantao [EMAIL PROTECTED]: Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. Hi, I was about to commit this patch, but shouldn't EdkQemuPkg/Pei/BochsPciScan/BochsPciScan.c be updated too ? Yes. Sure to change. Maybe we need to consolidate these two definitions to one. Do you know how to ? Hi, old issue... If you can send me a changeset that changes both BochsPciScan and build.c I will be happy to apply it. Tristan. Diff Description: Diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: paravirt_ops support in IA64
Dong, Eddie wrote: In X86, there are another enhancement (dynamic patching) base on pv_ops. The purpose is to improve cpu predication by converting indriect function call to direct function call for both C ASM code. We may take similar approach some time later too. We really need advices from community before we jump into coding. CC some active members that I though may be interested in pv_ops since KVM-IA64 mailinglist doesn;t exist yet. Hi, Eddie we just created the kvm-ia64-devel mailing list, and cc to the guys from this list who maybe interested in this topic. If you or other guys who are interested in kvm-ia64-devel or pv_virt_ops for ia64, please subscribe it here http://kvm.qumranet.com/kvmwiki/Lists%2C_IRC Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] MINSTATE_PHYS?
Hi, Alex What's your opinion about this cleanup patch ? Thanks Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2008年2月2日 10:17 To: Akio Takebe; Dong, Eddie; xen-ia64-devel Cc: Alex Williamson Subject: RE: [Xen-ia64-devel] MINSTATE_PHYS? Akio Takebe wrote: Hi, Eddie and Kaz I did a quick grep and find MINSTATE_PHYS is never defined in xenlinux. Xen mca code did. Anything missed? The minstate.h is a little old, it seems to be around linux-2.6.9. Current linux-xen is 2.6.18, so the code may be not nessesary. Kaz, do you know about it? Hi, Akio all Attached the patch did some cleanups. Please review. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] VHPI restore mechanism at save/restore
Hi,Isaku I have a question about the mechanism for save/restore vhpi. In current save/restore code, vhpi register is only saved and restored by vlsapic_save/load, but it maybe not enough for ensuring correctness. IMO, we need to call PAL_VPS_SET_PENDING_INTERRUPT again to set it， and make cpu aware of its value. Do I miss something ? :) Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] VHPI restore mechanism at save/restore
Isaku Yamahata wrote: On Fri, Feb 01, 2008 at 06:11:13PM +0800, Zhang, Xiantao wrote: Hi,Isaku I have a question about the mechanism for save/restore vhpi. In current save/restore code, vhpi register is only saved and restored by vlsapic_save/load, but it maybe not enough for ensuring correctness. IMO, we need to call PAL_VPS_SET_PENDING_INTERRUPT again to set it， and make cpu aware of its value. Do I miss something ? :) Please notice the line in vlsapic_load() v-arch.irq_new_pending = 1; /* to force checking irq */ Why need to set the force check here? Any special reasons or scenarios which need it ? :) and see leave_hypervisor_tail() which is always called before entering VTi guest. leave_hypervisor_tail() eventually calls PAL_VPS_SET_PENDING_INTERRUPT. At least this is my intention. Do you find any path where it isn't called? The force check may workaround the lost VHPI, so it should work. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] MINSTATE_PHYS?
Akio Takebe wrote: Hi, Eddie and Kaz I did a quick grep and find MINSTATE_PHYS is never defined in xenlinux. Xen mca code did. Anything missed? The minstate.h is a little old, it seems to be around linux-2.6.9. Current linux-xen is 2.6.18, so the code may be not nessesary. Kaz, do you know about it? Hi, Akio all Attached the patch did some cleanups. Please review. Xiantao pv_ops_cleanup1.patch Description: pv_ops_cleanup1.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. Hi, I was about to commit this patch, but shouldn't EdkQemuPkg/Pei/BochsPciScan/BochsPciScan.c be updated too ? Yes. Sure to change. Maybe we need to consolidate these two definitions to one. Do you know how to ? Thanks Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. I fear that with only 2 bits set, only INTA and INTB will be set. However from piix_pci-dm.c, it appears we don't really use INTA/D mapping. Am I right ? Yes, you are right. Seems all pci device should get an irq 16 from the algorithm. But for KVM, we also need to use assigned irqs for INTA-INTD. But irq 6 shouldn't use for this purpose, it may confilicts with floppy disk controller. Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. diff -r f263d2bca359 edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c --- a/edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c Wed Dec 12 02:02:32 2007 +0100 +++ b/edk2-sparse/EdkXenPkg/Dxe/XenAcpi/build.c Tue Dec 25 14:59:34 2007 +0800 @@ -33,7 +33,7 @@ #define LSAPIC_ID(n) n extern int get_vcpu_nr (void); #define get_apic_mode() 1 -#define PCI_ISA_IRQ_MASK0x0c60U /* ISA IRQs 5,6,10,11 are PCI connected */ +#define PCI_ISA_IRQ_MASK0x0c00U /* ISA IRQs 10,11 are PCI connected */ #endif #define align16(sz) (((sz) + 15) ~15) diff Description: diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] the xenLinux/IA64 upstream merge and Fedora.
Alex Williamson wrote: On Tue, 2007-12-04 at 10:58 +0900, Isaku Yamahata wrote: I'd like to share informations and opinions to avoid duplicate works. Please comments. Some questions. - Is anyone already working on it? - What code base is best to begin with? Although the official xenLinux/IA64 tree is http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg Does Fedora have any forward ported tree? This is definitely one of the tricky parts. Obviously we'll need to submit patches against upstream Linux, but we'll likely need to leverage the work of others for forward porting the core of the xen enabled components. The Fedora Xen kernel module may be a reasonable target, but there are probably lots of small architecture specific parts we can isolate into functional chunks and clean-up for upstream in the meantime. Some thoughts. - domU first and then dom0. the domu/IA64 part would be easy because MMU is fully virtualized on IA64. Yes, this would also allow us to start out focused on architecture specific parts while others solidify what the basis for dom0 looks like on upstream. - Coding Style The current code's style should be clean up. Definitely, although I think we've done a reasonable job matching Linux coding style for XenLinux files, I'm sure we'll find examples to the contrary. - Although xenLinux/x86 uses pv_ops, probably the machine vector should be considered at first. Then consider on the ia64 pv_ops. Yes, it's been unclear to me the extent to which ia64 needs pv_ops. We already have the xen machine vector and we may be able to expand the machine vector to incorporate a few more things where it makes sense. Then we need to see what pieces are left and whether it makes sense to create an ia64 pv_ops or implement more of the binary replacement type things we've discussed previously. - The kernel initialization might need to be revised. Especially the hypervisor detection and the initialization order. I think all of the xenlinux code should be carefully reviewed and re-evaluated as we try to get it upstream. This is also an opportunity to improve the code. - other VMM. Possibly kvm/ia64 or lguest/ia64 may have their opinion on paravirtualization. But their code aren't opened yet. This might make our merge easier or more difficult. Anyway we'll see. Yes, ia64 is at a bit of a disadvantage here since x86 has several implementations of paravirtualization to help tune their pv_ops. We should probably expect some of the interfaces to change over time as new PV guests are added, but we should try to solicit feedback from Jes and Xiantao as much as we can. Worked with kvm community guys in last two months, we almost completed kvm re-frame work. Currently, I have almost compelted kvm/ia64 rebase per the new framwork of kvm, although it is still need to refine by commnunity. So, after performing internal process, we will send out our kvm/ia64 patches to community soon. :) Thanks for your attention! Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Small fix for vpd size
New pal has fixed vpd size issue, so change its size to 64K. Xiantao vpd_64k.diff Description: vpd_64k.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Small fix for vpd size
Hi Kan, This issue is just in early stage pal for internal use, and it doesn't exist in any release version, so you can use it safely with any version you got. Xiantao -Original Message- From: Masaki Kanno [mailto:[EMAIL PROTECTED] Sent: 2007年5月18日 12:09 To: Zhang, Xiantao; xen-ia64-devel Cc: Alex Williamson Subject: Re: [Xen-ia64-devel] Small fix for vpd size Hi Xiantao, What is a version number of new PAL? Does old PAL need 128K for VPD? Best regards, Kan New pal has fixed vpd size issue, so change its size to 64K. Xiantao ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head, or double TLB miss occurs.
Hi Alex, Please drop the previous one. Don't need to disable IRQ during possible collision chain recycle, because it may need long time. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2007年4月26日 18:00 To: xen-ia64-devel Subject: [Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head,or double TLB miss occurs. Patch: Always insert entry to VHPT head, or TLB miss will occur again although the translation exists in its collision chain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Xiantao diff.patch Description: diff.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Always insert entry to VHPT's head, or double TLB miss occurs.
Patch: Always insert entry to VHPT head, or TLB miss will occur again although the translation exists in its collision chain. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Xiantao Insert entry to VHPT's head.patch Description: Insert entry to VHPT's head.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Let memory scrub done in time
Currently, memory scrub logic is done in SOFTIRQ, but it doesn't raise in time, so contiguous domain creation and destroy would come across fail. Xiantao patch.diff Description: patch.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Patch] Let memory scrub done in time
Sorry for getting sign-off-by. Sign-off-by : Zhang xiantao [EMAIL PROTECTED] -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2007年3月29日 3:14 To: Zhang, Xiantao Cc: xen-ia64-devel Subject: Re: [Xen-ia64-devel] [Patch] Let memory scrub done in time On Wed, 2007-03-28 at 21:00 +0800, Zhang, Xiantao wrote: Currently, memory scrub logic is done in SOFTIRQ, but it doesn't raise in time, so contiguous domain creation and destroy would come across fail. Ok, but I need a Signed-off-by. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cset is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007年2月27日 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF
Tsunehisa, Thanks for your information. Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 2007年2月27日 14:23 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel Subject: Re: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi, I've checked it. We'll have to modify the arch_memory_op code to follow dynamic grant table size feature in the hypervisor side. The latest change set (that is stable enough) is cs:13904, I think. This change set was confirmed by Kuwamura-san. I (Doi.Tsunehisa) said: Hi, Sorry, I'm bulding the test environment, now. I'll check it. Thanks You (xiantao.zhang) said: Hi Tsunehisa, Unluckily, we met xen crash with this patch. Do you know which #Cse t is stable enough for us to use VBD driver for HVM domain? :) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DOI Tsunehisa Sent: 2007$BDj(B2$BTB(B27$BHU(B 7:34 To: xen-ia64-devel Subject: [Xen-ia64-devel] [Patch] Fix for compiling PV-on-HVM on IPF Hi all, In the latest ia64-unstable tree, we can't build PV-on-HVM driver, because of a compile error about HYPERVISOR_grant_table_op(). I'll submit a patch to modify it. But, I don't have the test environment that I use at once, thus I did compile test only. Thanks, - Tsunehisa Doi ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] stacked pal call for VTi
Hi Tristan, I don't think this patch is needed for VTi domain. Oppositely, it may cause errors for stacked converntion calls. Because I recalled that stacked convention calls' parameters have been transferred into static ones before trapping into VMM in vPAL. I will check the code here and to see whether stack registers are tainted before the trap. Thanks, Xiantao 2007/2/16, [EMAIL PROTECTED] [EMAIL PROTECTED]: Hi, [I thought I have already sent this patch but I can't see it in the ml archive]. This patch implements stacked PAL call in VTi. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Qemu]Fix for VTi's 3G memroy limit
This patch fixed 3G memory limit for VTi domain. Due to some logic change in Qemu, so initializing ram_size should be moved up. Signed-off-by : Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation fix_vti_3G.patch Description: fix_vti_3G.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch] Add buffer IO mechanism for Xen/VTi domain.
This patch adds buffer IO mechanism for Xen/VTi domain. It catches up with Xen/IA32 side. Current implementation can accelerate Windows geust's dense IO operations @ boot time. I divided it into two parts. One is only related to Qemu, and the other one is main body. Signed-off-by : Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Patch]Add buffer IO mechanism for Xen/VTi domain[Part 2]
Main part. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation buffer_io.patch Description: buffer_io.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][IA64] Fix Qemu memory access beyond 3G
This patch intends to fix memory access beyond 3G for VTi domain. Currently VTi's memory beyond 3G was moved to 4G at build time. So it should be mapped correctly in qemu. If not, it will cause qemu's segmentation fault when guest use memory beyond 4G for DMA. Signed-off-by: Zhang Xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation fix_mem_access_beyond_3G.patch Description: fix_mem_access_beyond_3G.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][Qemu]Free page_page after foreign map.
Seems no special reason for keeping page_array after foreign map. Free it to avoid memory leak in Qemu. Signed-off-by: Zhang xiantao [EMAIL PROTECTED] Thanks Best Regards -Xiantao OTC,Intel Corporation free_page_array.patch Description: free_page_array.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64
Hi Aron, Could you share me the current status for fedora-xen-ia64? Through your mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when I applied the patch 199684 on it, conflicts occurs. Do you have any suggestion for contributing to Fedora ? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006年7月27日 12:11 To: Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; Alex Williamson; xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64 Hi Juan, These patches are the result of Akio, Prarit, Alex and me working on fixing the ia64 build of your tree. At this point the bare-metal Linux kernel builds and boots. The xen kernel builds but doesn't complete booting. Nonetheless, since these patches seem to take us most of the way there, we'd like to request them to be applied to your tree. Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi
This patch intends to remove the confusing flag ARCH_VMX_CONTIG_MEM for VTi. It was used for indicating that VTi needs contiguous memory. Currently, it seems useless. In addition, add the flag ARCH_VMX_DOMAIN to ensure VMX_DOMAIN check correctly with all vcpus. Thanks Best Regards -Xiantao OTC,Intel Corporation remove_contig_mem_flag.patch Description: remove_contig_mem_flag.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Hi, a question about 32bit OS running at xen-ia64
Hi Tom, Currently, 32 bit OS couldn’t be run on xen-ia64 due to different architectures between IA32 and IA64. 32 bit application should work well in 64 bit guest with BT technology. Anyway, your idea is very good. Maybe somebody will implement it in future. Thanks Best Regards -Xiantao OTC,Intel Corporation From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Sent: 2006年7月27日 16:35 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Hi,a question about 32bit OS running at xen-ia64 hi,guys. I guess it may seempretty much weird. I am not sure if 32bit OS such as 32bit Red Hat Linux distribution can run at xen-ia64? I really appreciate any suggestion, thanks a million. Tom ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi
Hi, Tristan Yes, but current VMX_DOMAIN check based on vcpu, so I think we had better set a flag in arch_vcpu for convenience or change VMX_DOMAIN implementation. Am I right? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: 2006年7月27日 16:54 To: Zhang, Xiantao; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH] Remove unused contig mem flag for VTi Le Jeudi 27 Juillet 2006 10:15, Zhang, Xiantao a écrit : This patch intends to remove the confusing flag ARCH_VMX_CONTIG_MEM for VTi. It was used for indicating that VTi needs contiguous memory. Currently, it seems useless. In addition, add the flag ARCH_VMX_DOMAIN to ensure VMX_DOMAIN check correctly with all vcpus. The ARCH_VMX_DOMAIN flag is the same as arch.is_vti. I suppose we don't want this double use. One of them must be removed. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64
Hi Akio, Thank you for your information. I am using the CSet34705 which should be latest, and do you mean I should apply Aron's patches on it. right? In addition, what's status about it? BTW, Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年7月27日 16:47 To: Zhang, Xiantao; Aron Griffis; Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64 Hi, Xiantao BZ's patch is old. Today 139 cset is added to linux-2.6-xen-fedora tree. So I think we should use Aron's patches. Best Regards, Akio Takebe Hi Aron, Could you share me the current status for fedora-xen-ia64? Through your mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when I applied the patch 199684 on it, conflicts occurs. Do you have any suggestion for contributing to Fedora ? Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006ト・ヤツ27ネユ 12:11 To: Juan Quintela Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright; [EMAIL PROTECTED]; Alex Williamson; xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64 Hi Juan, These patches are the result of Akio, Prarit, Alex and me working on fixing the ia64 build of your tree. At this point the bare-metal Linux kernel builds and boots. The xen kernel builds but doesn't complete booting. Nonetheless, since these patches seem to take us most of the way there, we'd like to request them to be applied to your tree. Thanks, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5] fixlinux-2.6-xen-fedora on ia64
Very clear now! Thank you very much.
-Xiantao
OTC,Intel Corporation
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: 2006年7月27日 17:36
To: Zhang, Xiantao; Aron Griffis; Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com; Akio
Takebe
Subject: RE: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5]
fixlinux-2.6-xen-fedora on ia64
Hi, Xiantao
Yes, you are right.
And I think you must use the following patch.
Now I cannot boot by using xen-ia64-unstable
(not linux-2.6-xen-fedora) on FC6.
I'm debuging it.
Then I'll try to boot by using xen-ia64-unstable/xen and linux-2.6-xen-
fedora.
diff -r 61b945565398 drivers/char/tpm/tpm.h
--- a/drivers/char/tpm/tpm.h Wed Jul 26 17:22:38 2006 +0200
+++ b/drivers/char/tpm/tpm.h Wed Aug 02 00:30:00 2006 +0900
@@ -125,7 +125,7 @@ static inline void tpm_write_index(int b
static inline u32 get_chip_buffersize(struct tpm_chip *chip)
{
- return chip-vendor-buffersize;
+ return chip-vendor.buffersize;
}
extern void tpm_get_timeouts(struct tpm_chip *);
Best Regards,
Akio Takebe
Hi Akio,
Thank you for your information. I am using the CSet34705 which should
be
latest, and do you mean I should apply Aron's patches on it. right? In
addition, what's status about it?
BTW,
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
-Original Message-
From: Akio Takebe [mailto:[EMAIL PROTECTED]
Sent: 2006年7月27日 16:47
To: Zhang, Xiantao; Aron Griffis; Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] RE: [Fedora-xen] [PATCH 0 of 5]
fixlinux-2.6-xen-fedora on ia64
Hi, Xiantao
BZ's patch is old.
Today 139 cset is added to linux-2.6-xen-fedora tree.
So I think we should use Aron's patches.
Best Regards,
Akio Takebe
Hi Aron,
Could you share me the current status for fedora-xen-ia64? Through your
mails, I see we should focus our efforts on linux-2.6-xen-fedora. But when
I applied the patch 199684 on it, conflicts occurs. Do you have any
suggestion for contributing to Fedora ?
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Aron Griffis
Sent: 2006ト・ヤツ27ネユ 12:11
To: Juan Quintela
Cc: Prarit Bhargava; [EMAIL PROTECTED]; Chris Wright;
[EMAIL PROTECTED]; Alex Williamson;
xen-ia64-devel@lists.xensource.com
Subject: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64
Hi Juan,
These patches are the result of Akio, Prarit, Alex and me working on
fixing
the
ia64 build of your tree. At this point the bare-metal Linux kernel
builds and
boots. The xen kernel builds but doesn't complete booting.
Nonetheless,
since
these patches seem to take us most of the way there, we'd like to
request
them
to be applied to your tree.
Thanks,
Aron
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] dom0-smp issue.
Hi Alex, I remembered I have sent out the patch to increase CONFIG_NR_CPUS to 16 for domain0 to enable SMP. It works well on Tiger4 platform but you said it would break HP's box. Seems need to think more about this issue before change:) Thanks Best Regards -Xiantao OTC,Intel Corporation Because Fujita already went home, I post console log instead of Fujita. Thanks. I suppose Isaku was right: your kernel was compiled with CONFIG_NR_CPUS=4, and according to the MADT, the fourth processor is not enabled. You should configure your kernel with 16 cpus. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [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:[EMAIL PROTECTED]
Sent: 2006年7月26日 19:24
To: Zhang, Xiantao; [EMAIL PROTECTED]
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][QEMU] Add IA64-specific code for new
qemu.
Hi, Xiantao
Is the following testandset redefine?
diff -r bbabdebc54ad tools/ioemu/exec-all.h
--- a/tools/ioemu/exec-all.h Wed Jul 19 21:13:36 2006 +0100
+++ b/tools/ioemu/exec-all.h Tue Jul 25 09:30:05 2006 +0800
@@ -391,6 +391,15 @@ static inline int testandset (int *p)
}
#endif
+#ifdef __ia64__
+#include ia64_intrinsic.h
+static inline int testandset (int *p)
+{
+uint32_t o = 0, n = 1;
+return (int)cmpxchg_acq(p, o, n);
+}
+#endif
+
#ifdef __s390__
static inline int testandset (int *p)
{
Best Regards,
Akio Takebe
This patch adds the ia64-specific code for new Qemu .
In addition, some ia64 patches aren't checked into xen-unstable.hg, so I
reversed the related logic temporarily. Once sync with
xen-ia64-unstable.hg, the logic will regain automatically.
Thanks Best Regards
-Xiantao
OTC,Intel Corporation
---text/plain---
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi Alex, That's very strange. We tried to boot VTi on CSet(10784) with VGA initialization fix and didn't met your issue. I am trying to reproduce your issue here. Hope to find it:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年7月27日 3:20 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization On Wed, 2006-07-26 at 13:38 +0800, Zhang, Xiantao wrote: Hi Alex, With this fix and previous patches, we can boot VTi successfully with new Qemu on xen-ia64-unstable.hg 's tip(10784). Should we make xen-unstable.hg sync with xen-ia64-unstable.hg happen next step? Yes, I sync'd with xen-unstable.hg. There's still a build issue with the qemu files, and I've sent a patch to Christian that fixes it: http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00861.html There's still some debugging left to do on xen-ia64 though. When starting a VTI domain on the xen-ia64-unstable.hg tip (cset 10809) the domain sits in the blocked state and doesn't accumulate cpu time. If I apply the attached patch (reinstating changes from xen-ia64 cset 10570), I get a little farther and can connect to the VNC session for the domain, but we never get to EFI. Thanks, Alex Signed-off-by: Alex Williamson [EMAIL PROTECTED] --- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi, Christian Thank you for your comments. But I check the patch on tip. Seems the following line not in upstream. I don't know why this part was lost when check-in. diff -r 254c090854de tools/ioemu/hw/vga.c --- a/tools/ioemu/hw/vga.c Wed Jul 26 15:59:36 2006 -0600 +++ b/tools/ioemu/hw/vga.c Thu Jul 27 09:27:03 2006 +0800 @@ -1953,6 +1953,7 @@ void vga_common_init(VGAState *s, Displa vga_screen_dump, s); /* XXX: currently needed for display */ vga_state = s; +vga_bios_init(s); } Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Christian Limpach [mailto:[EMAIL PROTECTED] Sent: 2006年7月26日 22:23 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] Add lost logic for VGA initialization On 7/26/06, Zhang, Xiantao [EMAIL PROTECTED] wrote: This patch adds lost logic for vga initialization. It was lost after changing to new Qemu. Signed-off-by : Kevin Tian [EMAIL PROTECTED] Signed-off-by : Zhang Xiantao [EMAIL PROTECTED] I've applied this -- it would be nice if you could cleanup the code some more to use arrays to initialize s-sr[], s-gr[], s-ar[] and s-cr[]. Thanks! christian ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization
Hi Alex, I found the reason why VTi couldn't get into EFi. Seems the patch which adds VGA bios initialization lost one part @check-in. With this fix and your attached patch. VTi should be healthy except network issue. diff -r 254c090854de tools/ioemu/hw/vga.c --- a/tools/ioemu/hw/vga.c Wed Jul 26 15:59:36 2006 -0600 +++ b/tools/ioemu/hw/vga.c Thu Jul 27 09:27:03 2006 +0800 @@ -1953,6 +1953,7 @@ void vga_common_init(VGAState *s, Displa vga_screen_dump, s); /* XXX: currently needed for display */ vga_state = s; +vga_bios_init(s); } Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Williamson Sent: 2006年7月27日 3:20 To: Zhang, Xiantao Cc: [EMAIL PROTECTED]; xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-devel] [PATCH] Add lost logic for VGA initialization On Wed, 2006-07-26 at 13:38 +0800, Zhang, Xiantao wrote: Hi Alex, With this fix and previous patches, we can boot VTi successfully with new Qemu on xen-ia64-unstable.hg 's tip(10784). Should we make xen-unstable.hg sync with xen-ia64-unstable.hg happen next step? Yes, I sync'd with xen-unstable.hg. There's still a build issue with the qemu files, and I've sent a patch to Christian that fixes it: http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00861.html There's still some debugging left to do on xen-ia64 though. When starting a VTI domain on the xen-ia64-unstable.hg tip (cset 10809) the domain sits in the blocked state and doesn't accumulate cpu time. If I apply the attached patch (reinstating changes from xen-ia64 cset 10570), I get a little farther and can connect to the VNC session for the domain, but we never get to EFI. Thanks, Alex Signed-off-by: Alex Williamson [EMAIL PROTECTED] --- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][XEND]Fix memory allocation for VTi domain with new Qemu on xen-unstagle.hg
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 fix_ia64_mem_alloc.patch Description: fix_ia64_mem_alloc.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][QEMU] Add IA64-specific code for new qemu.
This patch adds the ia64-specific code for new Qemu . In addition, some ia64 patches aren't checked into xen-unstable.hg, so I reversed the related logic temporarily. Once sync with xen-ia64-unstable.hg, the logic will regain automatically. Thanks Best Regards -Xiantao OTC,Intel Corporation ia64_specific_code_for_qemu.patch Description: ia64_specific_code_for_qemu.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang
Hi Alex, Seems this issue was caused by Cset 10688. In vcpu_itr_d, the current logic purges vhpt with cpu_flush_vhpt_range but it is very heavy to xen0. When creating VTi domain @ early stage, IO operation is very excessive, so qemu was scheduled out and in very frequently and this logic was executed every time. In addition, cpu_flush_vhpt_range using identity map to purge vhpt may cause more tlb miss due to no TR map. If remove vcpu_flush_tlb_vhpt_range logic although it definitely needed, seems VTi becomes healthy. Maybe potential bugs exist there.:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年7月11日 11:28 To: Zhang, Jingke Cc: xen-ia64-devel@lists.xensource.com; Zhang, Xiantao; [EMAIL PROTECTED] Subject: RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang On Tue, 2006-07-11 at 10:13 +0800, Zhang, Jingke wrote: Just add comments to this problem: With Cset 10684, VTI domain creating does well. Cset 10685 emulate PAL_HALT_LIGHT on domU seems to play a significant part of this. On cset 10690 it takes ~30 seconds to get to an EFI shell prompt for a VTI domain. If I 'hg export 10685 | patch -p1 -R' (ie. back out cset 10685), VTI domains start in ~5 seconds. Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang
Hi Alex, Our QA team reported that xen0 would hang after creating VTi domain @CSet 10688-10694. Should we reverse the logic of vcpu_itr_d first ? Maybe we can find out the real bottleneck later.:) Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Atsushi SAKAI [mailto:[EMAIL PROTECTED] Sent: 2006年7月11日 21:46 To: Alex Williamson; Zhang, Xiantao Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating a VTImake xen0 hang Hi, Alex Sorry for late. I found your problem(boot time difference w/ PAL_HALT_LIGHT emulation patch) occurred in SMP(credit). But, it does not occurred in UP, SMP(bvt) and SMP(credit w/ affinity). I think the emulation of pal_halt_light for domU does not good work for DomVTI boot up under credit scheduling w/o affinity. And consider the Xiantao survey, qemu make heavy I/O operations at the boot up. Consider the above two conditions, I think credit scheduler algorithm does not consider the block state.(caused by pal_halt_light emulation) So I want to switch off the vcpu migration at heavy load I planned as follows. 1)In the short term, I want to avoid this problem by HALT the PAL_HALT_LIGHT emulation while DomVTI boot up. or Lock VCPUs migrations while DomVTI boot up. (when Credit scheduler runs) 2)In the long term, I will make a patch to avoid this problem. (Consider the heavy io w/ vcpu migration) N.B. I checked under CS:10559.(original patch made) Thanks, Atsushi SAKAI On Tue, 2006-07-11 at 19:42 +0800, Zhang, Xiantao wrote: Hi Alex, Seems this issue was caused by Cset 10688. In vcpu_itr_d, the current logic purges vhpt with cpu_flush_vhpt_range but it is very heavy to xen0. When creating VTi domain @ early stage, IO operation is very excessive, so qemu was scheduled out and in very frequently and this logic was executed every time. In addition, cpu_flush_vhpt_range using identity map to purge vhpt may cause more tlb miss due to no TR map. If remove vcpu_flush_tlb_vhpt_range logic although it definitely needed, seems VTi becomes healthy. Maybe potential bugs exist there.:) Thanks for investigating Xiantao. Isaku, any thoughts on how to regain VTI performance? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Enable FW accleration for VTi
This patch intends to turn on FW acceleration for VTi. Thanks Best Regards -Xiantao OTC,Intel Corporation fw_acc.patch Description: fw_acc.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]A typo fix
Fix a typo. Thanks Best Regards -Xiantao OTC,Intel Corporation typo_fix.diff Description: typo_fix.diff ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2 LPs
Hi Alex, I couldn't reproduce your troubles here with this change. Could you check with xm vcpu-list to see the time of vcpus? I also found xenU state -, but I think it should be normal, because LPs were occupied by xen0 at that time. Only if time of vcpus is increasing, domU should be alive. I am also confused that CONFIG_NR_CPUS was set to 16 in xenU's configuration file(linux-defconfig_xenU_ia64), Why not come across those troubles before? Maybe we should come out a better solution for this issue. Anyway it is a must to set CONFIG_NR_CPUS to 4 for xen0 and XenU when LPs 4. Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月21日 7:41 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2 LPs On Tue, 2006-06-20 at 18:02 +0800, Zhang, Xiantao wrote: This patch intends to enable xen0's smp when machine only has 2 LPs. Thanks Best Regards Xiantao, For such a simply change, this patch caused me a lot of trouble. When I repeatedly reboot domU, I can get it into a state reported as -- by xm list. The domU console appears hung. I can always get it out of this state by running xenctx on the domain. At that point the console wakes up again and I get a software watchdog oops in the domU. The backtrace in the oops is a standard cpu_idle kind of patch. My HVM capable systems sometimes even failed to boot dom0 when I applied this patch. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2LPs
Very strange! Seems it is related to different platforms. Maybe potential bugs invoked these troubles in smp environment. :) I will retry to produce them and wish to get it. Thanks. -Xiantao OTC,Intel Corporation -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月21日 11:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Enable xen0 smp when machine only has2LPs On Wed, 2006-06-21 at 10:04 +0800, Zhang, Xiantao wrote: Hi Alex, I couldn't reproduce your troubles here with this change. Could you check with xm vcpu-list to see the time of vcpus? I also found xenU state -, but I think it should be normal, because LPs were occupied by xen0 at that time. Only if time of vcpus is increasing, domU should be alive. Hi Xiantao, The vcpu time on my domU was not increasing. The watchdog oops in the domU when kicking it with xenctx also indicates that domU was getting no time. FWIW, I saw this on a zx6000, madison system (2-way box). I was booting a UP dom0 w/ 2GB of memory, and a UP domU w/ 1GB of memory. DomU is configured with 1 vnif, and only booted to single user mode. I usually saw the domU hang within about 5 reboots. I am also confused that CONFIG_NR_CPUS was set to 16 in xenU's configuration file(linux-defconfig_xenU_ia64), Why not come across those troubles before? Nobody tests the -xenU kernel on a regular basis anymore. I typically only test the -xen kernel. Maybe we should come out a better solution for this issue. Anyway it is a must to set CONFIG_NR_CPUS to 4 for xen0 and XenU when LPs 4. I agree, and I can't explain why such a seemingly simple change triggered this problem. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Resend [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Just resend. Thanks Best Regards -Xiantao OTC,Intel Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年6月1日 16:29 To: Alex Williamson Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. Hi Alex, The updated patch should be happy for all platforms. If EFI doesn't provide md for range(0xa-0xc) to OS. It maybe a hole or occupied by legacy vga. Therefore, I used the efi_mmio function to check it. If these pages was not mapped yet and efi_mmio return true, we can map them as MMIO safely. BTW, this patch based on Yamahata's check memory descriptor overlap patch. Please give comments. :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月1日 10:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. xen0_console.patch Description: xen0_console.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] Handle VTi's fp fault and trap inhypervisor instead of injecting to guest.
Hi Alex, Please drop this patch. Thanks Best Regards -Xiantao OTC,Intel corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年6月2日 16:37 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH] Handle VTi's fp fault and trap inhypervisor instead of injecting to guest. This patch intends to handle VTi's fp fault and trap in hypervisor instead of injecting to guest. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Hi Alex, The updated patch should be happy for all platforms. If EFI doesn't provide md for range(0xa-0xc) to OS. It maybe a hole or occupied by legacy vga. Therefore, I used the efi_mmio function to check it. If these pages was not mapped yet and efi_mmio return true, we can map them as MMIO safely. BTW, this patch based on Yamahata's check memory descriptor overlap patch. Please give comments. :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年6月1日 10:11 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. xen0_console.patch Description: xen0_console.patch ---BeginMessage--- This patch tries to check MD's overlap and tries not to assign page to non conventional area. Maybe you may want to apply this patch before VGA-related modifications. On Wed, May 31, 2006 at 08:10:42PM -0600, Alex Williamson wrote: On Thu, 2006-06-01 at 09:45 +0800, Zhang, Xiantao wrote: Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Hi Xiantao, One of my test systems has VGA, the other does not. We cannot assume VGA in the system. If the MDT on the tiger4 doesn't describe that range, then we probably need to at least revert to the test the Linux kernel uses and test whether that range has a WB memory attribute before assuming it's VGA. Also, try not to double map the range for platforms that do describe this as type EFI_MEMORY_MAPPED_IO. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata # HG changeset patch # User [EMAIL PROTECTED] # Node ID e3e02e227b3e8d97537c38d5cdba9959bdd05d6a # Parent f6774d15d763fead75e6320e63fa1f14fabab26a check memory descriptor over lap in dom_fw_init() and assign page to dom0 precisely. PATCHNAME: assign_page_to_dom0_precisely Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff -r f6774d15d763 -r e3e02e227b3e xen/arch/ia64/xen/dom_fw.c --- a/xen/arch/ia64/xen/dom_fw.cThu Jun 01 11:39:04 2006 +0900 +++ b/xen/arch/ia64/xen/dom_fw.cThu Jun 01 11:39:06 2006 +0900 @@ -1017,11 +1017,16 @@ dom_fw_init (struct domain *d, const cha /* simulate 1MB free memory at physical address zero */ MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 0);//XXX +#else +int num_mds; +int j; #endif /* hypercall patches live here, masquerade as reserved PAL memory */ MAKE_MD(EFI_PAL_CODE,EFI_MEMORY_WB|EFI_MEMORY_RUNTIME,HYPERCALL_START,HYPERCALL_END, 0); + + +#ifndef CONFIG_XEN_IA64_DOM0_VP MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,HYPERCALL_END,maxmem-IA64_GRANULE_SIZE, 0);//XXX make sure this doesn't overlap on i/o, runtime area. -#ifndef CONFIG_XEN_IA64_DOM0_VP /* hack */ MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,last_start,last_end,1); #endif @@ -1054,6 +1059,52 @@ dom_fw_init (struct domain *d, const cha dom_fw_dom0_passthrough, arg); } else MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0); + +#ifdef CONFIG_XEN_IA64_DOM0_VP +// simple +// MAKE_MD(EFI_CONVENTIONAL_MEMORY, EFI_MEMORY_WB, +// HYPERCALL_END, maxmem, 0); +// is not good. Check overlap. +sort(efi_memmap, i, sizeof(efi_memory_desc_t), efi_mdt_cmp
RE: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI
Hi Rodrigo, Akio is right. Of course, you can make a try with old initrd.img . Maybe it is OK for your system. Thanks -Xiantao -Original Message- From: Akio Takebe [mailto:[EMAIL PROTECTED] Sent: 2006年6月2日 9:46 To: Rodrigo Lord; Zhang, Xiantao; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Re: [Xen-users] XEN on machines with EFI Hi, Rodrigo # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . Did you do the below? 5. make initrd for Dom0/DomU # cd linux-2.6.16.13-xen/ # make modules_install --this one # mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.16.13-xen.img 2.6.16. 13-xen --builtin mptbase --builtin mptscsih # cd .. And you may use --builtin option. Whenever I mkinitrd, I do the below. mkinitrd -f /boot/efi/efi/xen/initrd-2.6.16.13-xen.img 2.6.16.13-xen -- builtin mptbase --builtin mptscsih Best Regards, Akio Takebe Hello! Yes, I understood! I think that the EFI isn`t more my problem! :) I`m with problems to create my initrd! # mkinitrd -o /boot/efi/efi/debian/initrd-2.6.16.13-xen0.img 2.6.16.13-xen0 find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory find: /lib/modules/2.6.16.13-xen0/kernel/drivers: No such file or directory . . . Any help? Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
After enabling dom0_vp mode, we lost domain0's VGA console, and we have to connect it through network or serial console. The reason is that VGA frame buffer(0xa-0xc) was set to conventional memory not IO in dom0's p2m table. Attached patch fixes it. Thanks -Xiantao fix_dom0_vga_console.patch Description: fix_dom0_vga_console.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug.
Hi Alex, We are using tiger4 platform. I didn't find md about space: 0xa-0xc in efi memmap, maybe it was assumed EFI_MEMORY_MAPPED_IO in native OS. But dom_fw_init shouldn't neglect it to set IO space according to MDs efi provides. Seems your platform has VGA console. So this patch can enable VGA console on all platforms explicitly, maybe as you said this step is better to do in dom_fw_init :) Thanks -Xiantao -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年5月31日 23:32 To: Zhang, Xiantao Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [PATCH]Fix domain0 no VGA console bug. On Wed, 2006-05-31 at 20:30 +0800, Zhang, Xiantao wrote: After enabling dom0_vp mode, we lost domain0's VGA console, and we have to connect it through network or serial console. The reason is that VGA frame buffer(0xa-0xc) was set to conventional memory not IO in dom0's p2m table. Attached patch fixes it. Hi Xiantao, What about systems that don't have VGA? What memory type does your system report in the EFI MDT for address 0xA? I would expect EFI_MEMORY_MAPPED_IO, but if it's something else, it probably needs to be assigned a passthrough in dom_fw_init(). Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
This patch intends to fix isr setting before injecting fault to it. With this small fix, CPU2000 in VTi can pass now. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest.
Sorry for forgetting the attachment. Patch attached. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2006年5月31日 10:35 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] [PATCH]set isr before injecting fault to guest. This patch intends to fix isr setting before injecting fault to it. With this small fix, CPU2000 in VTi can pass now. Thanks -Xiantao ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel set_isr.patch Description: set_isr.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] XEN on machines with EFI
Rodrigo, From your log, it should be caused by incorrect elilo. The current elilo for xen is a modified version, and it can support vmm option. You can get it from xen source @ ./xen/arch/ia64/tools/xelilo/xlilo.efi. Pls have a try . Thanks -Xiantao From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Lord Sent: 2006年5月26日 20:40 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] XEN on machines with EFI Hello! I installed the xen-ia64 version on an Itanium2. I`m using Debian Sarge 3.1! I configured the elilo.conf normally, but when I reboot... not shows the option XEN on my elilo! How do I boot the xen using EFI? Anything different? It hangs when try to load the line vmm=/boot/xen.gz: Unkown option vmm 7 0 0x6B 0x0018 unexpected trap 7 0 0x66 0x0018 trap taken,number in ext PE 7 0 0x3C 0x5400 trap taken,offset in ext PE My elilo.conf: install=/usr/lib/elilo/elilo.efi boot=/dev/sda1 delay=20 default=linux image=/boot/vmlinuz label=linux root=/dev/sda2 initrd=/boot/initrd.img read-only image=/boot/xenlinuz vmm=/boot/xen.gz label=xen root=/dev/sda2 initrd=/boot/initrd.xen read-only append=sync_console dom0_mem=768M max_addr=64G -- nomca root=/dev/sda2 xencons=ttyS8 console=ttyS8 Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
