[Xen-ia64-devel] Large memory support
Hi, I've recently started to set up xen on one of my itanium servers. The domains boot smoothly with only one thing being salt-in-the-eye:. I cannot assign more than about 700MB to all my machines. My node has 2Gb of RAM in total. I found on mailing lists, that you should enable high memory support in the kernel's config. This should be located in Processor type and features tab in make menuconfig. I cannot find this option for itanium. I tried to enable the Virtual mem map for both domO and domU with no luck. Can anyone help me with this? Thanks, -Piotr ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Large memory support
Le Lundi 24 Juillet 2006 12:40, Piotr Siwczak a écrit : Hi, I've recently started to set up xen on one of my itanium servers. The domains boot smoothly with only one thing being salt-in-the-eye:. I cannot assign more than about 700MB to all my machines. My node has 2Gb of RAM in total. I found on mailing lists, that you should enable high memory support in the kernel's config. This should be located in Processor type and features tab in make menuconfig. I cannot find this option for itanium. I tried to enable the Virtual mem map for both domO and domU with no luck. Can anyone help me with this? Recent versions of Xen support sparse memory. Which version are you using ? What is the result of 'xm info' from dom0 ? NB: I was able to run Xen on a 48GB machine! Xen recognized all the memory. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC] Enable dom0 to start X
Le Lundi 24 Juillet 2006 14:22, Akio Takebe a écrit : Hi, all I'm debugging Xwindow system of dom0. [...] At the results, I could startx, but not completely. I found X run while using 100% CPU with top command. The following messages were shown at that time. (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000) (XEN) lookup_domain_mpa: d 0xf4288080 id 0 current 0xf426 id 0 I think this 0xf4288080 is I/O page to be used by X. (this 0xf4288080 is also not shown in memmap of Tiger4) The I/O page seem to be not allocated. How/When should xen allocate this page? Hi, you are misreading the message. The bad mpa is 0xfbfd0738! 0xf4288080 is the address of struct domain, which is a valid virtual address. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC] Enable dom0 to start X
Le Lundi 24 Juillet 2006 14:22, Akio Takebe a 馗rit :
Hi, all
I'm debugging Xwindow system of dom0.
[...]
At the results, I could startx, but not completely.
I found X run while using 100% CPU with top command.
The following messages were shown at that time.
(XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (= 0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0 (XEN) lookup_domain_mpa: bad mpa 0xfbfd0738 (=
0x2000)
(XEN) lookup_domain_mpa: d 0xf4288080 id 0 current
0xf426 id 0
I think this 0xf4288080 is I/O page to be used by X.
(this 0xf4288080 is also not shown in memmap of Tiger4)
The I/O page seem to be not allocated.
How/When should xen allocate this page?
Hi,
you are misreading the message.
The bad mpa is 0xfbfd0738!
0xf4288080 is the address of struct domain, which is a valid virtual
address.
Hi,
Thanks, I understand this messages.
I overlooked the following comment.
unsigned long lookup_domain_mpa(struct domain *d, unsigned long mpaddr)
{
[snip...]
//XXX This is a work around until the emulation memory access to a region
//where memory or device are attached is implemented.
return pte_val(pfn_pte(0, __pgprot(__DIRTY_BITS | _PAGE_PL_2 |
_PAGE_AR_RWX)));
}
Hmmm... I'll continue to debug this issue.
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] Mini-OS on ia64
Le Lundi 24 Juillet 2006 15:11, Dietmar Hahn a écrit : Am Montag, 24. Juli 2006 10:15 schrieben Sie: Le Lundi 24 Juillet 2006 09:20, Dietmar Hahn a écrit : Hi, is anybody working on the port of the mini-os from the xen hg to ia64? As far as I know nobody is working on it. OK, then I will start. If not and if there is a common interest I would do it. This is a low priority item on my TODO list. I can see three interest points for mini-os/ia64: * if hvm moves to a stub domain approach it will require mini-os. Thus VTi would require mini-os too. * mini-os can be used for corner case tests * mini-os can be used for experimentations. Currently I use it to get more familiar with xen and the interfaces between xen and domU. Tristan. At the moment I have running a rudimentary trap handler for the physically addresses (start_info, bootinfo and console page) and the event handler for timer and console events. Are there any guidelines to get in the sources? I have not looked into mini-os for a while. As far as I remember the low level layers (exception, time and context switch) have to be rewritten for ia64 (of course!). The higher levels (console) should be portable without any change. The lowest level of event handler has to be rewritten too. You have to look into linux-2.6-xen-sparse, both into arch/ia64 and drivers/xen. Feel free to ask more questions here. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Mini-OS on ia64
On Mon, 2006-07-24 at 15:12 +0200, Dietmar Hahn wrote: As far as I know nobody is working on it. OK, then I will start. Thanks Dietmar. I think this is something we need to watch closely so that ia64 can be ready should mini-os start being used for fully virtualized domains. At the moment I have running a rudimentary trap handler for the physically addresses (start_info, bootinfo and console page) and the event handler for timer and console events. Are there any guidelines to get in the sources? I imagine you'll have to do some re-architecture of the code to allow ia64 to fit cleanly into the existing code. The might mean making architecture specific sub-directories under extras/mini-os and moving the existing architecture specific files under them. That should probably be coordinated on xen-devel, but please keep xen-ia64-devel in the loop. When you're ready to add the ia64 code, submit that to the xen-ia64-devel list. 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] Re: PATCH: live migration
Hi Tristan,
Sorry for the delay, I didn't have as much spare time last week at
OLS as I was hoping. A few comments on this patch below. Thanks,
Alex
On Tue, 2006-07-18 at 11:03 +0200, Tristan Gingold wrote:
+
+#define BITS_PER_LONG (sizeof(unsigned long) * 8)
+#define BITMAP_SIZE ((max_pfn + BITS_PER_LONG - 1) / 8)
Looks like this is just borrowed from the x86 flavors, but I'm not
sure it makes sense. It appears we're rounding BITMAP_SIZE up, but why
not round it up to an even multiple of longs? Would something like this
work better:
(((max_pfn + (BITS_PER_LONG - 1)) ~(BITS_PER_LONG - 1)) / 8)
+/* Dirtied pages won't be saved.
+ slightly wasteful to peek the whole array evey time,
+ but this is fast enough for the moment. */
+if (!last_iter) {
+/* FIXME!! */
+for (i = 0; i BITMAP_SIZE; i += PAGE_SIZE)
+to_send[i] = 0;
This zero'ing loop is repeated in several places, but it doesn't make
sense to me. BITMAP_SIZE is in bytes, to_send is an unsigned long
pointer, and the PAGE_SIZE increment seems rather random. Looks like it
should segfault and only very sparsely zero the bitmap array. Am I
missing the point?
+
free (page_array);
-
+free (to_send);
+free (to_skip);
Shouldn't we check for NULL before free'ing?
if (to_send)
free(to_send);
etc...
+
+ atomic64_set (d-arch.shadow_fault_count, 0);
+ atomic64_set (d-arch.shadow_dirty_count, 0);
+
+ d-arch.shadow_bitmap_size = (d-max_pages + 63)
~63;
63 may be an obvious value, but I prefer the (BITS_PER_LONG - 1)
usage in the userspace tools. Magic numbers are bad.
+
+ if ( sc-pages d-arch.shadow_bitmap_size )
+ sc-pages = d-arch.shadow_bitmap_size;
+
+#define chunk (8*1024) /* Transfer and clear in 1kB chunks for L1
cache. */
Please move this #define out of the function and rename it to
something in all caps so it's easy to recognize as a macro.
+ for ( i = 0; i sc-pages; i += chunk )
+ {
+ int bytes = sc-pages - i) chunk) ?
+ chunk : (sc-pages - i)) + 7) /
8;
+
+ if ( copy_to_guest_offset(
+sc-dirty_bitmap,
+i/(8*sizeof(unsigned long)),
+d-arch.shadow_bitmap
+(i/(8*sizeof(unsigned long))),
BITS_PER_LONG would seem to be a useful simplification here.
+
+ if ( sc-pages d-arch.shadow_bitmap_size )
+ sc-pages = d-arch.shadow_bitmap_size;
+
+ if ( copy_to_guest(sc-dirty_bitmap,
+ d-arch.shadow_bitmap,
+ (((sc-pages+7)/8)+sizeof(unsigned
long)-1) /
+ sizeof(unsigned long)) )
A comment might be in order for the calculations going on in this
last parameter.
+/* Bitmap of shadow dirty bits.
+ Set iff shadow mode is enabled. */
+u64 *shadow_bitmap;
+/* Length (in byte) of shadow bitmap. */
+unsigned long shadow_bitmap_size;
The usage of shadow_bitmap_size seems to be in bits. Is this comment
correct?
--
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][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] [PATCH][RFC] per vcpu VHPT
On Mon, Jul 24, 2006 at 04:43:28PM +0200, Tristan Gingold wrote:
I don't understand why the per-vcpu patch relies on tlb-tracking. Is it for
convienience ?
It was just because of the patch order in my local repository.
It seems to be likely that the per-vcpu vhpt patch will be accepted
before the tlb-trackig patch. So I reordered them now.
Because I like flexibility, I'd vote for integrating this patch. However I'd
vote for removing #if CONFIG_XEN_IA64_PERVCPU_VHPT. The command line option
is good and the overhead should be very small.
The most of ifdef can be removed.
They were there for maintenance to mark modifications because
I expected that it would take a while to accept.
I attached the cleaned-up patch which isn't depend on the tlb tracking patch.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 28e7938f2e6e1096c09ccdf7e8352dfeccba6584
# Parent b2abc70be89e02d0d380674096c8c1fb9e552431
implement per vcpu vhpt option. allocate VHPT per vcpu.
added compile time option, xen_ia64_pervcpu_vhpt=n, to disable it.
added xen boot time option, pervcpu_vhpt=0, to disable it.
PATCHNAME: pervcpu_vhpt
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r b2abc70be89e -r 28e7938f2e6e xen/arch/ia64/Rules.mk
--- a/xen/arch/ia64/Rules.mkWed Jul 19 07:17:54 2006 -0600
+++ b/xen/arch/ia64/Rules.mkTue Jul 25 11:56:38 2006 +0900
@@ -4,6 +4,7 @@ HAS_ACPI := y
HAS_ACPI := y
VALIDATE_VT?= n
xen_ia64_dom0_virtual_physical ?= y
+xen_ia64_pervcpu_vhpt ?= y
no_warns ?= n
ifneq ($(COMPILE_ARCH),$(TARGET_ARCH))
@@ -39,6 +40,9 @@ ifeq ($(xen_ia64_dom0_virtual_physical),
ifeq ($(xen_ia64_dom0_virtual_physical),y)
CFLAGS += -DCONFIG_XEN_IA64_DOM0_VP
endif
+ifeq ($(xen_ia64_pervcpu_vhpt),y)
+CFLAGS += -DCONFIG_XEN_IA64_PERVCPU_VHPT
+endif
ifeq ($(no_warns),y)
CFLAGS += -Wa,--fatal-warnings -Werror -Wno-uninitialized
endif
diff -r b2abc70be89e -r 28e7938f2e6e xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cWed Jul 19 07:17:54 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cTue Jul 25 11:56:38 2006 +0900
@@ -114,8 +114,10 @@ static void flush_vtlb_for_context_switc
if (VMX_DOMAIN(vcpu)) {
// currently vTLB for vt-i domian is per vcpu.
// so any flushing isn't needed.
+ } else if (HAS_PERVCPU_VHPT(vcpu-domain)) {
+ // nothing to do
} else {
- vhpt_flush();
+ local_vhpt_flush();
}
local_flush_tlb_all();
}
@@ -130,9 +132,13 @@ void schedule_tail(struct vcpu *prev)
vmx_do_launch(current);
} else {
ia64_set_iva(ia64_ivt);
- ia64_set_pta(VHPT_ADDR | (1 8) | (VHPT_SIZE_LOG2 2) |
- VHPT_ENABLED);
+ // disable VHPT. ia64_new_rr7() might cause VHPT
+ // fault without this because it flushes dtr[IA64_TR_VHPT]
+ // (VHPT_SIZE_LOG2 2) is just for avoid
+ // Reserved Register/Field fault.
+ ia64_set_pta(VHPT_SIZE_LOG2 2);
load_region_regs(current);
+ ia64_set_pta(vcpu_pta(current));
vcpu_load_kernel_regs(current);
__ia64_per_cpu_var(current_psr_i_addr) = current-domain-
shared_info-vcpu_info[current-vcpu_id].evtchn_upcall_mask;
@@ -183,9 +189,13 @@ if (!i--) { i = 100; printk(+); }
nd = current-domain;
if (!is_idle_domain(nd)) {
- ia64_set_pta(VHPT_ADDR | (1 8) | (VHPT_SIZE_LOG2 2) |
-VHPT_ENABLED);
+ // disable VHPT. ia64_new_rr7() might cause VHPT
+ // fault without this because it changes dtr[IA64_TR_VHPT]
+ // (VHPT_SIZE_LOG2 2) is just for avoid
+ // Reserved Register/Field fault.
+ ia64_set_pta(VHPT_SIZE_LOG2 2);
load_region_regs(current);
+ ia64_set_pta(vcpu_pta(current));
vcpu_load_kernel_regs(current);
vcpu_set_next_timer(current);
if (vcpu_timer_expired(current))
@@ -302,6 +312,18 @@ struct vcpu *alloc_vcpu_struct(struct do
v-arch.ending_rid = d-arch.ending_rid;
v-arch.breakimm = d-arch.breakimm;
v-arch.last_processor = INVALID_PROCESSOR;
+
+ DPRINTK(%s:%d allocating d 0x%p %d v 0x%p %d
+ has_pervcpu_vhpt %d\n,
+ __func__, __LINE__,
+ d, d-domain_id, v, vcpu_id, HAS_PERVCPU_VHPT(d));
+ if (HAS_PERVCPU_VHPT(d)) {
+ if (pervcpu_vhpt_alloc(v) 0) {
+ free_xenheap_pages(v-arch.privregs,
get_order(sizeof(mapped_regs_t)));
+ free_xenheap_pages(v, KERNEL_STACK_SIZE_ORDER);
+ return NULL;
+ }
+
Re: [Xen-ia64-devel] Fix fetch code method when FP fault occurs @VTi side
On Fri, 2006-07-21 at 09:48 +0800, Zhang, Xiantao wrote: This patch intends to use __vmx_get_domain_bundle to fetch code when FP fault @VTi side. 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] [Patch] Support domU of coredump on ia64
On Fri, 2006-07-21 at 19:14 +0900, Akio Takebe wrote: Hi, This patch support domU of coredump on ia64. xen_panic_event() is registered to panic_notifier_list, and xen_panic_event() call HYPERVISOR_shutdown(SHUTDOWN_crash) at panic time. If xend notify crashed status, xend call dumpCore() and create domU's core in /var/xen/dump. Applied. I modified the patch to only register the panic notifier on the running on xen path. 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] remove unnecessary panic_domain() declarations
remove unnecessary panic_domain() declarations
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID ad9d0d6179c0a2877971280d09c52a285e61f751
# Parent c80625d2fc06a4524411b4028076a78911dc843d
remove unnecessary panic_domain() declarations
PATCHNAME: remove_unnecessary_panic_domain_decl
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r c80625d2fc06 -r ad9d0d6179c0 xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c Mon Jul 24 21:25:29 2006 +0900
+++ b/xen/arch/ia64/xen/vcpu.c Mon Jul 24 21:25:30 2006 +0900
@@ -30,7 +30,6 @@ extern void getfpreg (unsigned long regn
extern void setfpreg (unsigned long regnum, struct ia64_fpreg *fpval, struct
pt_regs *regs);
-extern void panic_domain(struct pt_regs *, const char *, ...);
extern IA64_BUNDLE __get_domain_bundle(UINT64);
typedefunion {
diff -r c80625d2fc06 -r ad9d0d6179c0 xen/include/asm-ia64/vmx.h
--- a/xen/include/asm-ia64/vmx.hMon Jul 24 21:25:29 2006 +0900
+++ b/xen/include/asm-ia64/vmx.hMon Jul 24 21:25:30 2006 +0900
@@ -37,7 +37,6 @@ extern void vmx_setup_platform(struct do
extern void vmx_setup_platform(struct domain *d);
extern void vmx_wait_io(void);
extern void vmx_io_assist(struct vcpu *v);
-extern void panic_domain(struct pt_regs *regs, const char *fmt, ...);
extern int ia64_hypercall (struct pt_regs *regs);
extern void vmx_save_state(struct vcpu *v);
extern void vmx_load_state(struct vcpu *v);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] increase buffer size in panic_domain()
increase buffer size in panic_domain().
128 bytes is too short.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 23fc30baae321d79b9225ce92a8ac5e704afbc45
# Parent ad9d0d6179c0a2877971280d09c52a285e61f751
increase buffer size in panic_domain().
128 bytes is too short.
PATCHNAME: increase_buffer_in_panic_domain
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r ad9d0d6179c0 -r 23fc30baae32 xen/arch/ia64/xen/xenmisc.c
--- a/xen/arch/ia64/xen/xenmisc.c Mon Jul 24 21:25:30 2006 +0900
+++ b/xen/arch/ia64/xen/xenmisc.c Mon Jul 24 21:25:30 2006 +0900
@@ -172,7 +172,7 @@ void panic_domain(struct pt_regs *regs,
void panic_domain(struct pt_regs *regs, const char *fmt, ...)
{
va_list args;
- char buf[128];
+ static char buf[1024];
struct vcpu *v = current;
printf($ PANIC in domain %d (k6=0x%lx): ,
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
