[Xen-ia64-devel] [PATCH] Fix of C/S 10529:4260eb8c08740de0000081c61a6237ffcb95b2d5 for IA64.
Fix of C/S 10529:4260eb8c08740de081c61a6237ffcb95b2d5 for IA64.
When page is zapped from a domain, the page referenced counter
is checked. But it results in false positive alert on Xen/IA64
because a page 'in use' has reference count 2 on Xen/IA64.
- a page is assigned to guest domain's psudo physical address space.
This is decremented by guest_physmap_remove_page()
- a page is allocated for a domain.
This is decremented by the following put_page()
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID be2fdd72c5ad7e527de4e1a3ba7fdf306632e106
# Parent 5d76b22f80e408294b59c51e3f0f3bf61cb36268
Fix of C/S 10529:4260eb8c08740de081c61a6237ffcb95b2d5 for IA64.
When page is zapped from a domain, the page referenced counter
is checked. But it results in false positive alert on Xen/IA64
because a page 'in use' has reference count 2 on Xen/IA64.
- a page is assigned to guest domain's psudo physical address space.
This is decremented by guest_physmap_remove_page()
- a page is allocated for a domain.
This is decremented by the following put_page()
PATCHNAME: ia64_fix_cs_10529
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 5d76b22f80e4 -r be2fdd72c5ad xen/common/memory.c
--- a/xen/common/memory.c Wed Jul 26 21:13:24 2006 +0100
+++ b/xen/common/memory.c Thu Jul 27 16:08:30 2006 +0900
@@ -170,7 +170,7 @@ guest_remove_page(
if ( test_and_clear_bit(_PGC_allocated, page-count_info) )
put_page(page);
-if ( unlikely((page-count_info PGC_count_mask) != 1) )
+if ( unlikely(!page_is_removable(page)) )
{
/* We'll make this a guest-visible error in future, so take heed! */
DPRINTK(Dom%d freeing in-use page %lx (pseudophys %lx):
diff -r 5d76b22f80e4 -r be2fdd72c5ad xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Wed Jul 26 21:13:24 2006 +0100
+++ b/xen/include/asm-ia64/mm.h Thu Jul 27 16:08:30 2006 +0900
@@ -211,6 +211,11 @@ static inline int get_page_and_type(stru
}
return rc;
+}
+
+static inline int page_is_removable(struct page_info *page)
+{
+return ((page-count_info PGC_count_mask) == 2);
}
#defineset_machinetophys(_mfn, _pfn) do { } while(0);
diff -r 5d76b22f80e4 -r be2fdd72c5ad xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h Wed Jul 26 21:13:24 2006 +0100
+++ b/xen/include/asm-x86/mm.h Thu Jul 27 16:08:30 2006 +0900
@@ -241,6 +241,11 @@ static inline int get_page_and_type(stru
return rc;
}
+static inline int page_is_removable(struct page_info *page)
+{
+return ((page-count_info PGC_count_mask) == 1);
+}
+
#define ASSERT_PAGE_IS_TYPE(_p, _t)\
ASSERT(((_p)-u.inuse.type_info PGT_type_mask) == (_t)); \
ASSERT(((_p)-u.inuse.type_info PGT_count_mask) != 0)
___
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
[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] 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] Hi, a question about 32bit OS running at xen-ia64
Hi, Tom Xen-ia64 support only ia64 OS. Xen-x86_64 can support both x86_64 OS and x86_32 OS. Best Regards, Akio Takebe hi,guys. I guess it may seem pretty 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 ---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] PATCH: iomem support for driver domains.
Hi,
this is the first patch for drivers domains. With this patch and another one
for pcifront, I was able to use an ethernet card in a domU.
This patch adds the IOPORT_PERMISSION hypercall (with no effects other than
setting the rangeset), checks iomem caps and provides a more flexible way to
handle memory attribute.
Currently IO ports are not supported in driver domain. I'd plan to start a
discussion about it.
Tested by using a ethernet card in domU and retesting live migration.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 64fd80e1b24f94d2c9de520c5c113b9566997bd4
# Parent 254c090854de353cf9859575c2bed0549d0ff5dd
First steps in hypevisor to support driver domains.
IO ports capabilities added (not yet used).
IO mem capabilities checked.
ASSIGN_nocache flag added.
Memory attributes checked.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 254c090854de -r 64fd80e1b24f xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Wed Jul 26 15:59:36 2006 -0600
+++ b/xen/arch/ia64/xen/dom0_ops.c Thu Jul 27 09:05:51 2006 +0200
@@ -20,6 +20,7 @@
#include public/sched_ctl.h
#include asm/vmx.h
#include asm/dom_fw.h
+#include xen/iocap.h
void build_physmap_table(struct domain *d);
@@ -279,6 +280,29 @@ long arch_do_dom0_op(dom0_op_t *op, XEN_
}
break;
+case DOM0_IOPORT_PERMISSION:
+{
+struct domain *d;
+unsigned int fp = op-u.ioport_permission.first_port;
+unsigned int np = op-u.ioport_permission.nr_ports;
+
+ret = -ESRCH;
+if ( unlikely((d = find_domain_by_id(
+op-u.ioport_permission.domain)) == NULL) )
+break;
+
+if ( np == 0 )
+ret = 0;
+else {
+if ( op-u.ioport_permission.allow_access )
+ret = ioports_permit_access (d, fp, fp + np - 1);
+else
+ret = ioports_deny_access (d, fp, fp + np - 1);
+}
+
+put_domain(d);
+}
+break;
default:
printf(arch_do_dom0_op: unrecognized dom0 op: %d!!!\n,op-cmd);
ret = -ENOSYS;
@@ -289,6 +313,24 @@ long arch_do_dom0_op(dom0_op_t *op, XEN_
}
#ifdef CONFIG_XEN_IA64_DOM0_VP
+static unsigned long dom0vp_ioremap (struct domain *d,
+ unsigned long mpaddr, unsigned long size)
+{
+unsigned long end;
+
+/* Linux may use a 0 size! */
+if (size == 0)
+size = PAGE_SIZE;
+
+end = PAGE_ALIGN(mpaddr + size);
+
+if (!iomem_access_permitted
+(d, mpaddr PAGE_SHIFT, (end PAGE_SHIFT) - 1))
+return -EPERM;
+
+return assign_domain_mmio_page(d, mpaddr, size);
+}
+
unsigned long
do_dom0vp_op(unsigned long cmd,
unsigned long arg0, unsigned long arg1, unsigned long arg2,
@@ -299,7 +341,7 @@ do_dom0vp_op(unsigned long cmd,
switch (cmd) {
case IA64_DOM0VP_ioremap:
-ret = assign_domain_mmio_page(d, arg0, arg1);
+ret = dom0vp_ioremap (d, arg0, arg1);
break;
case IA64_DOM0VP_phystomach:
ret = lookup_domain_mpa(d, arg0 PAGE_SHIFT);
diff -r 254c090854de -r 64fd80e1b24f xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.c Wed Jul 26 15:59:36 2006 -0600
+++ b/xen/arch/ia64/xen/domain.c Thu Jul 27 09:05:51 2006 +0200
@@ -360,6 +360,9 @@ int arch_domain_create(struct domain *d)
if ((d-arch.mm.pgd = pgd_alloc(d-arch.mm)) == NULL)
goto fail_nomem;
+ d-arch.ioport_caps = rangeset_new
+ (d, I/O Ports, RANGESETF_prettyprint_hex);
+
printf (arch_domain_create: domain=%p\n, d);
return 0;
@@ -885,6 +888,8 @@ static void physdev_init_dom0(struct dom
BUG();
if (irqs_permit_access(d, 0, NR_IRQS-1))
BUG();
+ if (ioports_permit_access(d, 0, 0x))
+ BUG();
}
int construct_dom0(struct domain *d,
diff -r 254c090854de -r 64fd80e1b24f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Wed Jul 26 15:59:36 2006 -0600
+++ b/xen/arch/ia64/xen/mm.c Thu Jul 27 09:05:51 2006 +0200
@@ -418,13 +418,13 @@ u64 translate_domain_pte(u64 pteval, u64
u64 mask, mpaddr, pteval2;
u64 arflags;
u64 arflags2;
+u64 maflags2;
pteval = ((1UL 53) - 1);// ignore [63:53] bits
// FIXME address had better be pre-validated on insert
mask = ~itir_mask(itir.itir);
- mpaddr = (((pteval ~_PAGE_ED) _PAGE_PPN_MASK) ~mask) |
- (address mask);
+ mpaddr = ((pteval _PAGE_PPN_MASK) ~mask) | (address mask);
#ifdef CONFIG_XEN_IA64_DOM0_VP
if (itir.ps PAGE_SHIFT) {
itir.ps = PAGE_SHIFT;
@@ -454,6 +454,8 @@ u64 translate_domain_pte(u64 pteval, u64
}
#endif
pteval2 = lookup_domain_mpa(d, mpaddr, entry);
+
+/* Check access rights. */
arflags = pteval _PAGE_AR_MASK;
arflags2 = pteval2 _PAGE_AR_MASK;
if (arflags != _PAGE_AR_R arflags2 == _PAGE_AR_R) {
@@ -468,34 +470,52 @@ u64 translate_domain_pte(u64 pteval, u64
pteval = (pteval ~_PAGE_AR_MASK) | _PAGE_AR_R;
}
- pteval2 = _PAGE_PPN_MASK; // ignore non-addr bits
- pteval2 |= (pteval _PAGE_ED);
Re: [Xen-ia64-devel] PAGE_ED in translate_domain_pte
Le Jeudi 27 Juillet 2006 10:01, Isaku Yamahata a écrit : It seems that you are right. Probably I was somewhat confused at that time. It seems everybody was confused ;-) Tristan. ___ 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] [PATCH] Remove unused contig mem flag for VTi
Le Jeudi 27 Juillet 2006 11:05, Zhang, Xiantao a écrit : 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 Oh yes, I missed the point. Sorry! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] pcifront for ia64
Hi,
this patch ports pcifont to ia64. pciback compiles without any change.
I had to make a few change because pcifront use its own structure
(struct pcifront_sd) for sysdata while ia64 wants it own (at least for
pcibios_fixup_bus). My solution is to reuse the ia64 sysdata structure
for pcifront, at the cost of a few ugly #ifdef.
Comments and ideas are welcome to improve this.
Also the patch fix a compile-time warning for xenbus.c.
Using this patch I was able to use an ethernet card in domU. This is
the good news.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 1ffb1200700b08420a1656b817171798ff45bad4
# Parent 64fd80e1b24f94d2c9de520c5c113b9566997bd4
Pcifront for ia64.
Added in Kconfig.
Use ia64 sysdate instead of pcifront genuine one.
Fix a warning on xenbus.c
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 64fd80e1b24f -r 1ffb1200700b linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/KconfigThu Jul 27 09:05:51 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/KconfigThu Jul 27 09:46:31 2006 +0200
@@ -438,6 +438,21 @@ config PCI_DOMAINS
bool
default PCI
+config XEN_PCIDEV_FRONTEND
+ bool Xen PCI Frontend
+ depends on PCI XEN
+ default y
+ help
+ The PCI device frontend driver allows the kernel to import arbitrary
+ PCI devices from a PCI backend to support PCI driver domains.
+
+config XEN_PCIDEV_FE_DEBUG
+ bool Xen PCI Frontend Debugging
+ depends on XEN_PCIDEV_FRONTEND
+ default n
+ help
+ Enables some debug statements within the PCI Frontend.
+
source drivers/pci/Kconfig
source drivers/pci/hotplug/Kconfig
diff -r 64fd80e1b24f -r 1ffb1200700b
linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c
--- a/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.cThu Jul 27
09:05:51 2006 +0200
+++ b/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.cThu Jul 27
09:46:31 2006 +0200
@@ -105,7 +105,7 @@ static int pcifront_bus_read(struct pci_
.size = size,
};
struct pcifront_sd *sd = bus-sysdata;
- struct pcifront_device *pdev = sd-pdev;
+ struct pcifront_device *pdev = pcifront_get_pdev(sd);
if (verbose_request)
dev_info(pdev-xdev-dev,
@@ -144,7 +144,7 @@ static int pcifront_bus_write(struct pci
.value = val,
};
struct pcifront_sd *sd = bus-sysdata;
- struct pcifront_device *pdev = sd-pdev;
+ struct pcifront_device *pdev = pcifront_get_pdev(sd);
if (verbose_request)
dev_info(pdev-xdev-dev,
@@ -207,8 +207,17 @@ int pcifront_scan_root(struct pcifront_d
err = -ENOMEM;
goto err_out;
}
+#ifdef __ia64__
+ sd-segment = domain;
+ sd-acpi_handle = NULL;
+ sd-iommu = NULL;
+ sd-windows = 0;
+ sd-window = NULL;
+ sd-platform_data = pdev;
+#else
sd-domain = domain;
sd-pdev = pdev;
+#endif
b = pci_scan_bus_parented(pdev-xdev-dev, bus, pcifront_bus_ops, sd);
if (!b) {
diff -r 64fd80e1b24f -r 1ffb1200700b
linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c
--- a/linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.cThu Jul 27
09:05:51 2006 +0200
+++ b/linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.cThu Jul 27
09:46:31 2006 +0200
@@ -7,6 +7,7 @@
#include linux/init.h
#include linux/mm.h
#include xen/xenbus.h
+#include xen/gnttab.h
#include pcifront.h
#define INVALID_GRANT_REF (0)
diff -r 64fd80e1b24f -r 1ffb1200700b linux-2.6-xen-sparse/include/xen/pcifront.h
--- a/linux-2.6-xen-sparse/include/xen/pcifront.h Thu Jul 27 09:05:51
2006 +0200
+++ b/linux-2.6-xen-sparse/include/xen/pcifront.h Thu Jul 27 09:46:31
2006 +0200
@@ -11,6 +11,7 @@
#ifdef __KERNEL__
+#ifndef __ia64__
struct pcifront_device;
struct pcifront_sd {
@@ -20,7 +21,13 @@ struct pcifront_sd {
struct pci_bus;
-#ifdef CONFIG_PCI_DOMAINS
+static inline struct pcifront_device *
+pcifront_get_pdev (struct pcifront_sd *sd)
+{
+ return sd-pdev;
+}
+
+#if defined(CONFIG_PCI_DOMAINS)
static inline int pci_domain_nr(struct pci_bus *bus)
{
struct pcifront_sd *sd = bus-sysdata;
@@ -31,6 +38,17 @@ static inline int pci_proc_domain(struct
return pci_domain_nr(bus);
}
#endif /* CONFIG_PCI_DOMAINS */
+#else
+#include asm/pci.h
+#define pcifront_sd pci_controller
+
+static inline struct pcifront_device *
+pcifront_get_pdev (struct pcifront_sd *sd)
+{
+ return (struct pcifront_device *)sd-platform_data;
+}
+
+#endif /* __ia64__ */
extern spinlock_t pci_bus_lock;
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 1ffb1200700b08420a1656b817171798ff45bad4
# Parent 64fd80e1b24f94d2c9de520c5c113b9566997bd4
Pcifront for ia64.
Added in Kconfig.
Use ia64 sysdate instead of pcifront genuine one.
Fix a warning on xenbus.c
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r
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
[Xen-ia64-devel] dom0-smp issue.
Hi I will report a new issue, which was found by Yongkang at first. As already reported by Yongkang, we also met the same dom0-smp issue. Our test environment is as below. cset :10700 physical CPUs :3 (2 cores) HyperThred:enable We tried 3 patterns of tests. The first testing was done with the following parameters in elilo.conf. append=dom0_max_vcpus=4 com2=115200,8n1 console=com2 sched=bvt tbuf_size=128 -- nomca console=tty0 console=ttyS1,115200,8n1 rhgb root=/dev/sda2 System can boot up. But I can see only 3 CPUs in /proc/cpuinfo. And xm vcpu-list result is below. [EMAIL PROTECTED] ~]# xm vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 00 r-- 351.5 0 Domain-0 0 11 r-- 351.2 any cpu Domain-0 0 22 r-- 350.9 any cpu Domain-0 0 3- --p 0.0 any cpu In addition, I tried other test with parameter 8 and 0 of dom0_max_vcpus=. Each the results are as below. #case param 8 [EMAIL PROTECTED] ~]# xm vcpu-l Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 00 r-- 643.4 0 Domain-0 0 11 r-- 643.1 any cpu Domain-0 0 22 r-- 642.9 any cpu Domain-0 0 3- --p 0.0 any cpu Domain-0 0 4- --p 0.0 any cpu Domain-0 0 5- --p 0.0 any cpu Domain-0 0 6- --p 0.0 any cpu Domain-0 0 7- --p 0.0 any cpu #case param 0 [EMAIL PROTECTED] ~]# xm vcpu-l Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 00 r-- 176.4 0 Domain-0 0 11 r-- 176.1 any cpu Domain-0 0 22 r-- 175.9 any cpu Domain-0 0 3- --p 0.0 any cpu Domain-0 0 4- --p 0.0 any cpu Domain-0 0 5- --p 0.0 any cpu Domain-0 0 6- --p 0.0 any cpu Domain-0 0 7- --p 0.0 any cpu Domain-0 0 8- --p 0.0 any cpu Domain-0 0 9- --p 0.0 any cpu Domain-0 010- --p 0.0 any cpu Domain-0 011- --p 0.0 any cpu Through all the tests, active VCPUs are only 3 and others are p. I think xen0 can only recognize the 1st CPU of each physical CPU. Thanks, Fujita ___ 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.
Le Jeudi 27 Juillet 2006 12:23, yo.fujita a écrit : Hi I will report a new issue, which was found by Yongkang at first. As already reported by Yongkang, we also met the same dom0-smp issue. Our test environment is as below. Thank you for the report. I will try to understand the issue. Tristan. ___ 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.
Le Jeudi 27 Juillet 2006 12:23, yo.fujita a écrit : Hi I will report a new issue, which was found by Yongkang at first. As already reported by Yongkang, we also met the same dom0-smp issue. Our test environment is as below. cset :10700 physical CPUs :3 (2 cores) HyperThred:enable We tried 3 patterns of tests. The first testing was done with the following parameters in elilo.conf. append=dom0_max_vcpus=4 com2=115200,8n1 console=com2 sched=bvt tbuf_size=128 -- nomca console=tty0 console=ttyS1,115200,8n1 rhgb root=/dev/sda2 I have juest tried on a tiger4 4 cpus, with dom0_max_vcpus=8. The 8 cpus started. Can you post the console log ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10811:254c090854de
Hi.
On Thu, Jul 27, 2006 at 05:43:36PM +0800, You, Yongkang wrote:
Other Issue:
1. SMP_VTI_Boot may stop to boot after Calibrating delay loop...
I'm seeing a similar issue.
My case is UP VTI domain. VTI domain doesn't share pcpu with dom0.
FWIW
- vITV
By inserting debug print code to vtm_set_itv(), vtm_set_itm() and
vtm_timer_fn(), I found that vtm_set_itv() wasn't called.
vITV.m bit isn't cleared so that VTI domain doesn't receives
timer interrupt. Thus the calibrating delay loop isn't terminated.
On the other hand Linux/ia64 surely clears itv.m in ia64_cpu_local_tick()
which is called before the calibration.
- struct arch_vmx_struct::vtm
VTI domain code seems to assume that vtime_t::vtm_timer is running on
same physical cpu of its vcpu.
Probably the attached patch is needed for credit scheduler.
It is only compile tested.
2. SMP Xen0 couldn't see all vcpus, no matter dom0_max_vcpus=4 or 2.
xm vcpu-list can show the other vcpus status are P
xenLinux default config has CONFIG_NR_CPUS=4.
Does increasing it up to 8 or 16 make difference?
Thanks.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1153997893 -32400
# Node ID 41d895195c5aa95152518a0419c6f0615d0558e9
# Parent 572d08aa4ab90122624f359e78a47ca78614e09e
VTi domain assumes that current-arch.arch_vmx.vtm.vtm_timer is
running on the same physical cpu of vcpu.
However vcpu is migrated between phsyical cpus, the assumption isn't true.
PATCHNAME: vtm_timer
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 572d08aa4ab9 -r 41d895195c5a xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cThu Jul 27 16:03:01 2006 +0900
+++ b/xen/arch/ia64/xen/domain.cThu Jul 27 19:58:13 2006 +0900
@@ -368,6 +368,10 @@ if (!i--) { i = 100; printk(+); }
local_irq_restore(spsr);
flush_vtlb_for_context_switch(current);
context_saved(prev);
+if (VMX_DOMAIN(current)){
+migrate_timer(current-arch.arch_vmx.vtm.vtm_timer,
+ current-processor);
+}
}
void continue_running(struct vcpu *same)
___
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.
On Thu, Jul 27, 2006 at 01:01:15PM +0200, Tristan Gingold wrote: I have juest tried on a tiger4 4 cpus, with dom0_max_vcpus=8. The 8 cpus started. Did you increase CONFIG_NR_CPUS of your linux dot config? -- yamahata ___ 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.
Le Jeudi 27 Juillet 2006 13:16, Isaku Yamahata a écrit : On Thu, Jul 27, 2006 at 01:01:15PM +0200, Tristan Gingold wrote: I have juest tried on a tiger4 4 cpus, with dom0_max_vcpus=8. The 8 cpus started. Did you increase CONFIG_NR_CPUS of your linux dot config? Its value is 8. If this is the same issue we have already met, we should maybe re-order MADT entries. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] pcifront for ia64
On 27 Jul 2006, at 10:41, Tristan Gingold wrote: this patch ports pcifont to ia64. pciback compiles without any change. I had to make a few change because pcifront use its own structure (struct pcifront_sd) for sysdata while ia64 wants it own (at least for pcibios_fixup_bus). My solution is to reuse the ia64 sysdata structure for pcifront, at the cost of a few ugly #ifdef. Comments and ideas are welcome to improve this. Also the patch fix a compile-time warning for xenbus.c. Using this patch I was able to use an ethernet card in domU. This is the good news. Move the sysdata initialisation to static inline functions in pcifront.h. That means you only have a single big ifdef in the header, and none in the main C files. With that change this will be fine to check in. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: io ports
Hi,
this patch allows IO ports to be mapped/unmapped in domU.
Using it I was able to mount a usb-key in domU.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID d7bb72ade3d3adfca6dff3a43b04fd19fa3541d6
# Parent 1ffb1200700b08420a1656b817171798ff45bad4
IO ports for driver domains.
Map/unmap IO ports.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 1ffb1200700b -r d7bb72ade3d3 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Thu Jul 27 09:46:31 2006 +0200
+++ b/xen/arch/ia64/xen/dom0_ops.c Thu Jul 27 12:49:06 2006 +0200
@@ -285,6 +285,7 @@ long arch_do_dom0_op(dom0_op_t *op, XEN_
struct domain *d;
unsigned int fp = op-u.ioport_permission.first_port;
unsigned int np = op-u.ioport_permission.nr_ports;
+unsigned int lp = fp + np - 1;
ret = -ESRCH;
if ( unlikely((d = find_domain_by_id(
@@ -295,9 +296,9 @@ long arch_do_dom0_op(dom0_op_t *op, XEN_
ret = 0;
else {
if ( op-u.ioport_permission.allow_access )
-ret = ioports_permit_access (d, fp, fp + np - 1);
+ret = ioports_permit_access (d, fp, lp);
else
-ret = ioports_deny_access (d, fp, fp + np - 1);
+ret = ioports_deny_access (d, fp, lp);
}
put_domain(d);
diff -r 1ffb1200700b -r d7bb72ade3d3 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch/ia64/xen/dom_fw.c Thu Jul 27 09:46:31 2006 +0200
+++ b/xen/arch/ia64/xen/dom_fw.c Thu Jul 27 12:49:06 2006 +0200
@@ -855,15 +855,17 @@ dom_fw_init (struct domain *d, struct ia
} else {
#ifndef CONFIG_XEN_IA64_DOM0_VP
/* Dom0 maps legacy mmio in first MB. */
- MAKE_MD(EFI_LOADER_DATA,EFI_MEMORY_WB,0*MB,1*MB, 1);
- MAKE_MD(EFI_CONVENTIONAL_MEMORY,EFI_MEMORY_WB,HYPERCALL_END,maxmem, 1);
-#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, 1);
- /* Create a dummy entry for IO ports, so that IO accesses are
- trapped by Xen. */
- MAKE_MD(EFI_MEMORY_MAPPED_IO_PORT_SPACE,EFI_MEMORY_UC,
- 0x0c00, 0x0fff, 1);
+ MAKE_MD(EFI_LOADER_DATA, EFI_MEMORY_WB, 0*MB, 1*MB, 1);
+ MAKE_MD(EFI_CONVENTIONAL_MEMORY, EFI_MEMORY_WB,
+ HYPERCALL_END, maxmem, 1);
+#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, 1);
+ /* Create an entry for IO ports. */
+ MAKE_MD(EFI_MEMORY_MAPPED_IO_PORT_SPACE, EFI_MEMORY_UC,
+ IO_PORTS_PADDR, IO_PORTS_PADDR + IO_PORTS_SIZE, 1);
MAKE_MD(EFI_RESERVED_TYPE,0,0,0,0);
}
diff -r 1ffb1200700b -r d7bb72ade3d3 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Thu Jul 27 09:46:31 2006 +0200
+++ b/xen/arch/ia64/xen/mm.c Thu Jul 27 12:49:06 2006 +0200
@@ -179,6 +179,8 @@ static void domain_page_flush(struct dom
static void domain_page_flush(struct domain* d, unsigned long mpaddr,
unsigned long old_mfn, unsigned long new_mfn);
#endif
+
+extern unsigned long ia64_iobase;
static struct domain *dom_xen, *dom_io;
@@ -892,6 +894,60 @@ assign_domain_page(struct domain *d,
// because __assign_domain_page() uses set_pte_rel() which has
// release semantics, smp_mb() isn't needed.
__assign_domain_page(d, mpaddr, physaddr, ASSIGN_writable);
+}
+
+int
+ioports_permit_access (struct domain *d, unsigned long fp, unsigned long lp)
+{
+int ret;
+unsigned long off;
+unsigned long fp_offset;
+unsigned long lp_offset;
+
+ret = rangeset_add_range(d-arch.ioport_caps, fp, lp);
+if (ret != 0)
+return ret;
+
+fp_offset = IO_SPACE_SPARSE_ENCODING (fp) ~PAGE_MASK;
+lp_offset = PAGE_ALIGN (IO_SPACE_SPARSE_ENCODING (lp));
+
+for (off = fp_offset; off = lp_offset; off += PAGE_SIZE)
+__assign_domain_page
+(d, IO_PORTS_PADDR + off, ia64_iobase + off, ASSIGN_nocache);
+
+return 0;
+}
+
+int
+ioports_deny_access (struct domain *d, unsigned long fp, unsigned long lp)
+{
+int ret;
+struct mm_struct *mm = d-arch.mm;
+unsigned long off;
+unsigned long fp_offset;
+unsigned long lp_offset;
+
+ret = rangeset_remove_range(d-arch.ioport_caps, fp, lp);
+if (ret != 0)
+return ret;
+
+fp_offset = IO_SPACE_SPARSE_ENCODING (fp) ~PAGE_MASK;
+lp_offset = PAGE_ALIGN (IO_SPACE_SPARSE_ENCODING (lp));
+
+for (off = fp_offset; off = lp_offset; off += PAGE_SIZE) {
+unsigned long mpaddr = IO_PORTS_PADDR + off;
+volatile pte_t *pte;
+pte_t old_pte;
+
+pte = lookup_noalloc_domain_pte_none(d, mpaddr);
+BUG_ON (pte == NULL);
+BUG_ON (pte_none(*pte));
+
+// clear pte
+old_pte = ptep_get_and_clear(mm, mpaddr, pte);
+}
+domain_flush_vtlb_all ();
+return 0;
}
#ifdef CONFIG_XEN_IA64_DOM0_VP
diff -r 1ffb1200700b -r d7bb72ade3d3
[Xen-ia64-devel] Re: [Xen-devel] pcifront for ia64
Le Jeudi 27 Juillet 2006 14:12, Keir Fraser a écrit :
On 27 Jul 2006, at 10:41, Tristan Gingold wrote:
this patch ports pcifont to ia64. pciback compiles without any change.
I had to make a few change because pcifront use its own structure
(struct pcifront_sd) for sysdata while ia64 wants it own (at least for
pcibios_fixup_bus). My solution is to reuse the ia64 sysdata structure
for pcifront, at the cost of a few ugly #ifdef.
Comments and ideas are welcome to improve this.
Also the patch fix a compile-time warning for xenbus.c.
Using this patch I was able to use an ethernet card in domU. This is
the good news.
Move the sysdata initialisation to static inline functions in
pcifront.h. That means you only have a single big ifdef in the header,
and none in the main C files. With that change this will be fine to
check in.
Thank you for your quick reply.
Here is the updated patch.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 4519e440e05c4083ce28187dd771416a31fbeda1
# Parent 254c090854de353cf9859575c2bed0549d0ff5dd
Pcifront for ia64.
Added in Kconfig.
On ia64, use ia64 sysdata instead of pcifront genuine one.
Fix a warning on xenbus.c
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 254c090854de -r 4519e440e05c linux-2.6-xen-sparse/arch/ia64/Kconfig
--- a/linux-2.6-xen-sparse/arch/ia64/Kconfig Wed Jul 26 15:59:36 2006 -0600
+++ b/linux-2.6-xen-sparse/arch/ia64/Kconfig Thu Jul 27 13:30:37 2006 +0200
@@ -438,6 +438,21 @@ config PCI_DOMAINS
bool
default PCI
+config XEN_PCIDEV_FRONTEND
+ bool Xen PCI Frontend
+ depends on PCI XEN
+ default y
+ help
+ The PCI device frontend driver allows the kernel to import arbitrary
+ PCI devices from a PCI backend to support PCI driver domains.
+
+config XEN_PCIDEV_FE_DEBUG
+ bool Xen PCI Frontend Debugging
+ depends on XEN_PCIDEV_FRONTEND
+ default n
+ help
+ Enables some debug statements within the PCI Frontend.
+
source drivers/pci/Kconfig
source drivers/pci/hotplug/Kconfig
diff -r 254c090854de -r 4519e440e05c linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c
--- a/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c Wed Jul 26 15:59:36 2006 -0600
+++ b/linux-2.6-xen-sparse/drivers/xen/pcifront/pci_op.c Thu Jul 27 13:30:37 2006 +0200
@@ -105,7 +105,7 @@ static int pcifront_bus_read(struct pci_
.size = size,
};
struct pcifront_sd *sd = bus-sysdata;
- struct pcifront_device *pdev = sd-pdev;
+ struct pcifront_device *pdev = pcifront_get_pdev(sd);
if (verbose_request)
dev_info(pdev-xdev-dev,
@@ -144,7 +144,7 @@ static int pcifront_bus_write(struct pci
.value = val,
};
struct pcifront_sd *sd = bus-sysdata;
- struct pcifront_device *pdev = sd-pdev;
+ struct pcifront_device *pdev = pcifront_get_pdev(sd);
if (verbose_request)
dev_info(pdev-xdev-dev,
@@ -207,8 +207,7 @@ int pcifront_scan_root(struct pcifront_d
err = -ENOMEM;
goto err_out;
}
- sd-domain = domain;
- sd-pdev = pdev;
+ pcifront_init_sd (sd, domain, pdev);
b = pci_scan_bus_parented(pdev-xdev-dev, bus, pcifront_bus_ops, sd);
if (!b) {
diff -r 254c090854de -r 4519e440e05c linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c
--- a/linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c Wed Jul 26 15:59:36 2006 -0600
+++ b/linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c Thu Jul 27 13:30:37 2006 +0200
@@ -7,6 +7,7 @@
#include linux/init.h
#include linux/mm.h
#include xen/xenbus.h
+#include xen/gnttab.h
#include pcifront.h
#define INVALID_GRANT_REF (0)
diff -r 254c090854de -r 4519e440e05c linux-2.6-xen-sparse/include/xen/pcifront.h
--- a/linux-2.6-xen-sparse/include/xen/pcifront.h Wed Jul 26 15:59:36 2006 -0600
+++ b/linux-2.6-xen-sparse/include/xen/pcifront.h Thu Jul 27 13:30:37 2006 +0200
@@ -11,6 +11,7 @@
#ifdef __KERNEL__
+#ifndef __ia64__
struct pcifront_device;
struct pcifront_sd {
@@ -20,7 +21,20 @@ struct pcifront_sd {
struct pci_bus;
-#ifdef CONFIG_PCI_DOMAINS
+static inline struct pcifront_device *
+pcifront_get_pdev (struct pcifront_sd *sd)
+{
+ return sd-pdev;
+}
+
+static inline void pcifront_init_sd (struct pcifront_sd *sd, int domain,
+ struct pcifront_device *pdev)
+{
+ sd-domain = domain;
+ sd-pdev = pdev;
+}
+
+#if defined(CONFIG_PCI_DOMAINS)
static inline int pci_domain_nr(struct pci_bus *bus)
{
struct pcifront_sd *sd = bus-sysdata;
@@ -31,6 +45,28 @@ static inline int pci_proc_domain(struct
return pci_domain_nr(bus);
}
#endif /* CONFIG_PCI_DOMAINS */
+#else
+#include asm/pci.h
+#define pcifront_sd pci_controller
+
+static inline struct pcifront_device *
+pcifront_get_pdev (struct pcifront_sd *sd)
+{
+ return (struct pcifront_device *)sd-platform_data;
+}
+
+static inline void pcifront_init_sd (struct pcifront_sd *sd, int domain,
+ struct pcifront_device *pdev)
+{
+ sd-segment = domain;
+ sd-acpi_handle = NULL;
+ sd-iommu = NULL;
+ sd-windows = 0;
+ sd-window = NULL;
+ sd-platform_data = pdev;
+}
+
+#endif /* __ia64__ */
extern spinlock_t
Re: [Xen-ia64-devel] Problems booting 2 vm!
2006/7/21, Tristan Gingold [EMAIL PROTECTED]: Le Vendredi 21 Juillet 2006 15:50, Rodrigo Lord a écrit : Hi! I`m testing xen-ia64 on an Itanium2 rx2600 (hp integrity) with 4 processors. but an error shows some times (in vm01 and dom0 too): kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d111 kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d1d1 kernel unaligned access to 0xe0005ec2201e, ip=0xa0010093d260 kernel unaligned access to 0xe0005ec2202e, ip=0xa0010093d4e0 kernel unaligned access to 0xe0005ec2202e, ip=0xa0010093b9c1This is harmless. Other problem: just boots 1 virtual machine! (when I try to boot 2 vm, the system hangs)... I don`t know how to capture this error to post here!Difficult to say without details!Check memory usage: 'xm info' before 'xm create'; amount of memory for vm#2... Tristan. Hi Tristan! My 'xm info' is here: host : peso release : 2.6.16.13-xen0 version : #2 SMP Tue Jul 11 05:09:48 BRT 2006 machine : ia64 nr_cpus : 4 nr_nodes : 1 sockets_per_node : 4 cores_per_socket : 1 threads_per_core : 1 cpu_mhz : 900 hw_caps : :::::::: total_memory : 8169 free_memory : 6041 xen_major : 3 xen_minor : 0 xen_extra : -unstable xen_caps : xen-3.0-ia64 xen_pagesize : 16384 platform_params : virt_start=0xe800 xen_changeset : Wed Jun 28 07:52:21 2006 -0600 10559:4b51d081378d cc_compiler : gcc version 3.3.5 (Debian 1:3.3.5-13) cc_compile_by : root cc_compile_domain : localdomain cc_compile_date : Tue Jul 11 05:12:15 BRT 2006 Thanks! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: remove a debug message
Hi,
debug message to be removed.
Tested by compiling.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID b57145901e732be16f51f33191fe444621de160f
# Parent 4519e440e05c4083ce28187dd771416a31fbeda1
Cleanup: remove a debugging message.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 4519e440e05c -r b57145901e73 linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Thu Jul 27 13:30:37 2006 +0200
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/irq_ia64.c Thu Jul 27 14:50:43 2006 +0200
@@ -451,8 +451,6 @@ init_IRQ (void)
init_IRQ (void)
{
#ifdef CONFIG_XEN
- printk(KERN_INFO init_IRQ called from %p\n,
- __builtin_return_address (0));
/* Maybe put into platform_irq_init later */
if (is_running_on_xen()) {
struct callback_register event = {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: include asm/vhpt.h in ivt.S
Hi, some macros were lost. Re-add them. ivt.S definitly needs cleanup! Tested by booting dom0+domU. Tristan. # HG changeset patch # User [EMAIL PROTECTED] # Node ID c8fbf705c8dc1b05c1898830fda9f8ed57b2d609 # Parent b57145901e732be16f51f33191fe444621de160f Include asm/vhpt.h to define VHPT_GLOBAL and VHPT_ENABLED. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r b57145901e73 -r c8fbf705c8dc xen/arch/ia64/xen/ivt.S --- a/xen/arch/ia64/xen/ivt.S Thu Jul 27 14:50:43 2006 +0200 +++ b/xen/arch/ia64/xen/ivt.S Thu Jul 27 15:13:28 2006 +0200 @@ -1,5 +1,6 @@ #ifdef XEN #include asm/debugger.h +#include asm/vhpt.h #endif /* * arch/ia64/kernel/ivt.S ___ 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
Xiantao and Akio, Sorry that I'm not very good sharing status. Here is an update to hopefully put us on the same page again. First, a review of the repos available, since this is always a point of confusion: http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora - This is Juan's tree from which he generates linux-2.6-xen.patch for the Fedora kernel rpm. Juan creates this tree as a combination of pulls from: http://kernel.org/hg/linux-2.6 - automatic mirror of Linus' git tree http://xenbits.xensource.com/linux-2.6-xen.hg - sparse tree patches applied to 2.6.16 kernel, maintained mostly-daily by Christian http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg - sparse tree patches merged to 2.6.18 kernel, maintained sporadically by Chris Wright PLUS Juan's own patches to make it all work together. http://free.linux.hp.com/~agriffis/linux-2.6-xen-fedora-ia64 - This pulls from linux-2.6-xen-fedora, but also includes our patches to fix building on ia64. http://free.linux.hp.com/~agriffis/kernel-cvs - This is a mercurial mirror of the Fedora kernel cvs (see http://people.redhat.com/davej), updated numerous times per day by me. http://free.linux.hp.com/~agriffis/kernel-cvs-ia64 - This pulls from kernel-cvs, but also includes spec-file changes necessary to build and test on ia64. In particular, this includes linux-2.6-xen-ia64.patch which is our current collection of updates to Juan's tree to support ia64. Second, what works, what doesn't: kernel-cvs-ia64 builds on ia64, both with and without CONFIG_XEN. The normal kernel boots, the xen kernel doesn't yet. Considering that everything builds at this point, I've requested for Juan to update his repo *and* update the spec to enable building on ia64. This is driven by wanting to land in FC6 T2. We still need to make the xen kernel boot though :-) Third, how to contribute: If you prefer to work with raw xen and kernel sources instead of the rpm, do this first to get the kernel configs: hg clone http://free.linux.hp.com/~agriffis/kernel-cvs-ia64 cd kernel-cvs-ia64/devel make configs That generates these files, which you can use in a kernel tree with oldconfig: kernel-2.6.17-ia64.config kernel-2.6.17-ia64-xen.config Next get the kernel to work on: hg clone http://free.linux.hp.com/~agriffis/linux-2.6-xen-fedora-ia64 Send your patches to me and cc fedora-xen and xen-ia64-devel. To know what hypervisor changeset to use, check the spec file: cd kernel-cvs-ia64/devel grep -m1 xen_hv_cset kernel-2.6.spec Thanks, Aron ___ 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
Akio Takebe wrote: [Thu Jul 27 2006, 04:46:45AM EDT] 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. Thanks, I just put an updated patch in BZ 199684, but best approach is to work from the mercurial trees I described in my previous email. Aron ___ 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
Akio,
I intentionally omitted this from what I submitted to Juan because the
rpm currently backs out ALL the xen modifications to the tpm code.
But you're right... to build from linux-2.6-xen-fedora-ia64, you need
to either (1) apply this patch, or (2) disable tpm in the config.
Aron
Akio Takebe wrote: [Thu Jul 27 2006, 05:35:34AM EDT]
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 *);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] please pull xen-ia64-unstable.hg
Hi Keir, We finally seem to have mostly stabilized with the latest big changes in xen-unstable.hg. Therefore, please pull: http://xenbits.xensource.com/ext/xen-ia64-unstable.hg Changeset 10831 of this tree is in sync with cset 10756 of xen-unstable.hg. Highlights include: * credit scheduler fixes * enabling VTi firmware acceleration * ia64 INIT handling support * standard xencons usage * domain save restore * domain coredump support * live migration support * preliminary driver domain support And as always, many bug fixes, optimizations, and smaller additions. 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] Remove unused contig mem flag for VTi
On Thu, 2006-07-27 at 16:15 +0800, Zhang, Xiantao wrote: 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. Applied. -- 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] Re: PATCH: iomem support for driver domains.
On Thu, 2006-07-27 at 11:03 +0200, Tristan Gingold wrote: Hi, this is the first patch for drivers domains. With this patch and another one for pcifront, I was able to use an ethernet card in a domU. Very cool! Applied. -- 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] Re: PATCH: io ports
On Thu, 2006-07-27 at 14:35 +0200, Tristan Gingold wrote: Hi, this patch allows IO ports to be mapped/unmapped in domU. Using it I was able to mount a usb-key in domU. Applied. -- 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] Re: PATCH: remove a debug message
On Thu, 2006-07-27 at 16:36 +0200, Tristan Gingold wrote: Hi, debug message to be removed. Applied. -- 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] Hi, a question about 32bit OS running at xen-ia64
If you are trying to run a specific app that runs on 32bit Red Hat Linux (without porting or recompiling), you may be able to run it using ia32el (the Intel IA-32 Execution Layer**) on a Red Hat ia64 guest OS running on xen-ia64. However as others have pointed out, xen-ia64 doesn't support running 32 bit OS's directly. Has anybody in the Xen/ia64 community tried ia32el either on a PV guest or a vti guest? Dan ** Google doesn't reveal much information on ia32el which might imply it is not widely used. This link might help: http://www.gelato.org/community/view_linear.php?id=10_146 Others at Intel might be able to point to better docs. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Sent: Thursday, July 27, 2006 2:35 AM 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 seem pretty 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
[Xen-ia64-devel] General Question on IA-64
Hello, I know that Xen is now setup for IA-64 but how setup is it. I noticed that many bugs are out there, are these minor errors or is IA-64 still problematic? I guess I really want to know how close Xen is to being fully optimized on IA-64? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] General Question on IA-64
On Thu, 2006-07-27 at 15:18 -0700, David Drummond wrote: Hello, I know that Xen is now setup for IA-64 but how setup is it. I noticed that many bugs are out there, are these minor errors or is IA-64 still problematic? I guess I really want to know how close Xen is to being fully optimized on IA-64? Hi David, Xen/ia64 has made an amazing amount of progress in the past few months and is now something that is pretty usable and has near functional parity with Xen/x86. So far Xen/ia64 as been mainly for developers, but I believe we're to the point where the project is useful to users as well. For the next phase of development, we need to move stability and performance work up in the priority list. We're not quite to the point where I would deploy Xen/ia64 into production, but I think you'll find we have a very responsive community and the code features and quality get better every day. 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] Xen/IA64 Healthiness Report -Cset#10811:254c090854de
Hi Isaku, Thank you for investigating the VTI booting issues. In my side, this issue is a little hard to reproduce. Actually we only see a few times in the past 2 weeks. Do you often meet this situation? For the credit schedule, we are preparing to switch schedule from bvt to credit in our nightly testing. But we also meet some unstable issues in VTI. I want to have more trying and report some bugs, for example, we found Oops: time before its due... in SMP VTI when using credit. Today we will try more testing with credit and report the issues. Could somebody give some comments to this patch? Maybe it fix some potential issue for VTI domain. Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年7月27日 19:15 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10811:254c090854de Hi. On Thu, Jul 27, 2006 at 05:43:36PM +0800, You, Yongkang wrote: Other Issue: 1. SMP_VTI_Boot may stop to boot after Calibrating delay loop... I'm seeing a similar issue. My case is UP VTI domain. VTI domain doesn't share pcpu with dom0. FWIW - vITV By inserting debug print code to vtm_set_itv(), vtm_set_itm() and vtm_timer_fn(), I found that vtm_set_itv() wasn't called. vITV.m bit isn't cleared so that VTI domain doesn't receives timer interrupt. Thus the calibrating delay loop isn't terminated. On the other hand Linux/ia64 surely clears itv.m in ia64_cpu_local_tick() which is called before the calibration. - struct arch_vmx_struct::vtm VTI domain code seems to assume that vtime_t::vtm_timer is running on same physical cpu of its vcpu. Probably the attached patch is needed for credit scheduler. It is only compile tested. 2. SMP Xen0 couldn't see all vcpus, no matter dom0_max_vcpus=4 or 2. xm vcpu-list can show the other vcpus status are P xenLinux default config has CONFIG_NR_CPUS=4. Does increasing it up to 8 or 16 make difference? Thanks. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10811:254c090854de
On Fri, Jul 28, 2006 at 08:55:36AM +0800, You, Yongkang wrote: Hi Isaku, Thank you for investigating the VTI booting issues. In my side, this issue is a little hard to reproduce. Actually we only see a few times in the past 2 weeks. Do you often meet this situation? Hi Yongkan. Always it happens. I can't boot domVTI. I'm not sure it is my environmental issue (hw or firmware) or xen issue. -- yamahata ___ 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] Xen/IA64 Healthiness Report -Cset#10811:254c090854de
-Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年7月28日 9:39 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10811:254c090854de little hard to reproduce. Actually we only see a few times in the past 2 weeks. Do you often meet this situation? Hi Yongkan. Always it happens. I can't boot domVTI. I'm not sure it is my environmental issue (hw or firmware) or xen issue. Hi Yamahata, I am using PAL 8.15. Guest firmware is 7.25, md5sum is e7fe6875659ab6c73da6e71594c9ef85 I am using bvt scheduler and UP Xen0. Best Regards, Yongkang (Kangkang) 永康 ___ 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.
On Fri, 2006-07-28 at 09:42 +0800, Zhang, Xiantao wrote: 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:) Hi Xiantao, As I recall, I had trouble rebooting domUs with this change. It may have been an unrelated problem though. We should test again. 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] Xen/IA64 Healthiness Report -Cset#10831
Xen/IA64 Healthiness Report Good news: VTI domain can start up in new Qemu 0.8.1 without vif option. Bad news: __coexisting__ domain testing failed in latest upstream. That means can not create 2 domains at the same time. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 4 Service OS: RHEL4u3 IA64 VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 10831:2d73714911c2 Xen Schedule: bvt VTI Guest Firmware MD5: e7fe6875659ab6c73da6e71594c9ef85 Summary Test Report: - Total cases: 12 Passed:6 Failed: 6 Detailed test cases info: - One_VTI pass One_XenU pass Two_VTI_Coexist __fail__(Note 2) One_VTI_and_One_XenU __fail__ Two_XenU_Coexist __fail__ (Note 1) One_VTI_4096M pass VTI_Network __fail__ XenU_Network pass One_SMP_XenU pass One_SMP_VTI pass VTI_Kernel_Build __fail__ (cause network start fail) UP_VTI_LTP __fail__ (cause network start fail) Notes: - 1. Create 2 XenU at the same time, the 2nd XenU report can not open initial console. 2. Create 2 VTI domains at the same time, the 2nd VTI domain can not boot up successfully. The last stable changeset: - 10706:2db50529223e Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report-Cset#10811:254c090854de
From: Isaku Yamahata 1. SMP_VTI_Boot may stop to boot after Calibrating delay loop... I'm seeing a similar issue. My case is UP VTI domain. VTI domain doesn't share pcpu with dom0. FWIW - vITV By inserting debug print code to vtm_set_itv(), vtm_set_itm() and vtm_timer_fn(), I found that vtm_set_itv() wasn't called. vITV.m bit isn't cleared so that VTI domain doesn't receives timer interrupt. Thus the calibrating delay loop isn't terminated. On the other hand Linux/ia64 surely clears itv.m in ia64_cpu_local_tick() which is called before the calibration. We only found this issue on SMP_VTI, never found on UP_VTI, I am not sure the ITV issue, maybe you use too old PAL, My hand is full now; I will look at this issue when I'm free. - struct arch_vmx_struct::vtm VTI domain code seems to assume that vtime_t::vtm_timer is running on same physical cpu of its vcpu. Probably the attached patch is needed for credit scheduler. It is only compile tested. You are right, current virtual timer for VTI domain doesn't support migration. That will be great, if you would like to cover this task. Thanks, Anthony 2. SMP Xen0 couldn't see all vcpus, no matter dom0_max_vcpus=4 or 2. xm vcpu-list can show the other vcpus status are P xenLinux default config has CONFIG_NR_CPUS=4. Does increasing it up to 8 or 16 make difference? Thanks. -- yamahata ___ 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 Tristan, Isaku, Thanks for your reply and sorry for my ignorance... I tried recompile with CONFIG_NR_CPUS=8. As it turned out, I can boot up with 4 CPUs when specifying dom0_max_vcpus=4. [EMAIL PROTECTED] ~]# xm vcpu-l Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 00 r-- 193.1 0 Domain-0 0 11 r-- 192.8 any cpu Domain-0 0 22 r-- 192.6 any cpu Domain-0 0 33 r-- 192.3 any cpu But, I could see only 6 CPUs when I specified dom0_max_vcpus=8. (see attachment) The #3 CPU's socket of this machine is empty. I think the empty CPU's socket is not recognized. Is this correct work? [EMAIL PROTECTED] ~]# xm vcpu-l Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 00 r-- 351.8 0 Domain-0 0 11 r-- 351.4 any cpu Domain-0 0 22 r-- 351.2 any cpu Domain-0 0 33 r-- 350.9 any cpu Domain-0 0 44 r-- 350.7 any cpu Domain-0 0 55 r-- 350.4 any cpu Domain-0 0 6- --p 0.0 any cpu Domain-0 0 7- --p 0.0 any cpu Thanks, Fujita -Original Message- From: Tristan Gingold [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:22 PM To: Masaki Kanno; yo.fujita; xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] dom0-smp issue. Le Jeudi 27 Juillet 2006 15:07, Masaki Kanno a écrit : Hi Tristan, 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. dmesg_dom0_smp.log Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10831
BTW, two XenU domain coexisting testing can pass in Changeset 10818:199d53efd029 Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006年7月28日 10:49 To: xen-ia64-devel@lists.xensource.com Subject: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10831 Xen/IA64 Healthiness Report Good news: VTI domain can start up in new Qemu 0.8.1 without vif option. Bad news: __coexisting__ domain testing failed in latest upstream. That means can not create 2 domains at the same time. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 4 Service OS: RHEL4u3 IA64 VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 10831:2d73714911c2 Xen Schedule: bvt VTI Guest Firmware MD5: e7fe6875659ab6c73da6e71594c9ef85 Summary Test Report: - Total cases: 12 Passed:6 Failed: 6 Detailed test cases info: - One_VTI pass One_XenU pass Two_VTI_Coexist __fail__(Note 2) One_VTI_and_One_XenU __fail__ Two_XenU_Coexist __fail__ (Note 1) One_VTI_4096M pass VTI_Network __fail__ XenU_Network pass One_SMP_XenU pass One_SMP_VTI pass VTI_Kernel_Build __fail__ (cause network start fail) UP_VTI_LTP __fail__ (cause network start fail) Notes: - 1. Create 2 XenU at the same time, the 2nd XenU report can not open initial console. 2. Create 2 VTI domains at the same time, the 2nd VTI domain can not boot up successfully. The last stable changeset: - 10706:2db50529223e Best Regards, Yongkang (Kangkang) 永康 ___ 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: [Fedora-xen] [PATCH 0 of 5] fix linux-2.6-xen-fedora on ia64
Akio Takebe wrote: [Thu Jul 27 2006, 09:00:41PM EDT] To know what hypervisor changeset to use, check the spec file: cd kernel-cvs-ia64/devel grep -m1 xen_hv_cset kernel-2.6.spec Which is this cset xen-ustable's cset or xen-ia64-unstable's cset? xen-unstable Aron ___ 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
Zhang, Xiantao wrote: [Thu Jul 27 2006, 09:13:23PM EDT] Thanks you for detail. Seems very clear now. I have the same question with Akio. Which Cset for xen and xenLinux is using for debug? Are they compatible? I have a tracker on my web page that might help answer this question. It updates automatically. See the top of http://free.linux.hp.com/~agriffis/ Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10831
Yes. Xm list shows everything is right. But I can not connect to the 2nd one. Could you? :( Best Regards, Yongkang (Kangkang) 永康 -Original Message- From: Alex Williamson [mailto:[EMAIL PROTECTED] Sent: 2006年7月28日 11:11 To: You, Yongkang Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#10831 On Fri, 2006-07-28 at 10:59 +0800, You, Yongkang wrote: BTW, two XenU domain coexisting testing can pass in Changeset 10818:199d53efd029 Strange, I can run 2 domUs concurrently on 10831: Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 2018 1 r- 340.5 sarge1 1 1024 1 r- 214.8 sarge2 2 2048 2 -- 143.9 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
