similar to: No noht?

(Moving from offlist discussion.) I''m interested in opinions... Assume there are four single vcpu domains A, B, C, D, running on a 2-CPU physical machine. We wish to test for time skew on domain A. Assuming B, C, and D are all running some workload that attempts to fully saturate the (single) cpu. 1) Should the affect on domain A be essentially the same regardless of what load

Folks, A new release candidate for 3.2.0 has just been checked into the xen-unstable tree. It''s available from staging and will be in the main tree when it has passed internal regression tests. Meanwhile, in preparation for 3.1.3, please let me know if there are any further patches from xen-unstable that should be backported into the 3.1 branch. You can pull the xen-3.1-testing.hg

Folks, The second release candidate for Xen 3.4.0 is available at http://xenbits.xensource.com/xen-unstable.hg, tagged as ''3.4.0-rc2''. Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I am trying to write a script to handle setup of domains using virtual block devices for their root FS and have been unable to get the virtual devices to work with any sort of consistency. This is using xen-1.1.bk on Redhat 7.3 (I had to rebuild all the tool binaries to run on 7.3). Anyway, I would first like to make sure I am using the vd/vbd stuff correctly. Here is an example of the problem I

I''ve noticed with xen-unstable on my quad-core x dual-thread (that''s 8 processors to xen), the boot info spewed for all the C-state/P-state stuff quickly fills the xm dmesg buffer and I lose some of the early-in-boot lines. Do we really need to know "reg.{space_id,bit_width,bit_offset,access_size, address}" and all that other info? Even if so, is there a more compact

Various versions of Linux under various circumstances select TSC as the primary clocksource for the kernel. This is especially true for uniprocessor kernels, but also in some cases for multiprocessor kernels. In most cases, this is because a processor bit (tsc_invariant? constant_tsc?) is passed through directly from the hardware via Xen and tested by the hvm guest and the result implies that

Hello, I read an interesting article on 2cpu.com that talks about the performance differences between a P4 processor with Hyperthreading(HT) enabled and disabled. http://www.2cpu.com/articles/ht_explored/index.html The bottom line of the article is that processor intensive applications greatly benefit from HT being enabled, but memory intensive applications can actually see a slight decrease in

Hi, Dan, This patch fixes strange behavior on IA64, that IDLE is scheduled more than Dom0 with default sEDF scheduler. The key point is reprogram_ac_timer at the end of ac_timer dispatcher, which programs local apic timer with expire of next ac_timer on x86. Higher precision lapic timer can trigger ac_timer more precisely than simply done in PIT interrupt handler. That works perfectly on x86

I am adding code in Xen that printk''s a size_t and find that I can''t write code (short of ifdef''ing) that compiles on both 32-bit and 64-bit because size_t is typedef''d in Xen as an unsigned long. C.f. http://www.velocityreviews.com/forums/t438359-portable-way-to-printf-a-sizet-instance.html It appears that the %z format is understood by Xen printk. Is the

This patch replaces the Xen xmalloc engine with tlsf, an allocation engine that is both more space efficient and time-bounded, especially for allocation sizes between PAGE_SIZE/2 and PAGE_SIZE. The file xmalloc.c is deprecated but not yet deleted. A simple switch of a comment line in common/Makefile will change back to the legacy xmalloc/xfree if needed for testing. Code adapted from Nitin

Xenlinux uses a special architecture-dependent bit in the page table, called PG_arch_1 to indicate that a page is "foreign" (PG_foreign). It also apparently uses it to determine if a page is pinned (PG_pinned). Linux/ia64 (and apparently Linux/ppc and Linux/ppc64) use the PG_arch_1 bit for other purposes. On Linux/ia64, it is used to determine if the instruction cache needs to be

Attached patch makes the balloon driver arch-neutral (compiles on ia64... look ma, no #ifdef''s!). Please apply to xen-unstable. One change should be eyeballed, line 257 in balloon.c, because phys_to_machine_mapping[pfn] is not identical to pfn_to_mfn (different by sign bit, should be OK?) Signed-off by: Dan Magenheimer <dan.magenheimer@hp.com> diff -r 0255f48b757f

I think this is the last of the header fixes I''ve run across. Though it''s sometimes difficult to tell, I believe Xen/ia64 has asm/mm.h, flushtlb.h, page.h, and shadow.h. Please apply. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> -- Hollis Blanchard IBM Linux Technology Center

The Xen boot option ''ser_baud=<baud>'' has been removed from the unstable tree. If you were still using this obsolete option then the effect is that you will get no serial output when you boot Xen, which may lead you to believe that there is a more serious problem. To fix this you must move to the new boot option: ''com1=<baud>,8n1'' -- Keir

> http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00238.html > > > > > > The issue is that PG_arch_1 is reserved for arch-specific > > usage, the paravirtualization changes for Xenlinux utilize > > it (to mark foreign pages) because it was otherwise unused > > in Linux/x86. But Xen is no longer an arch. > > > > Grep''ing

A while ago (I think at the Xummit), I recall someone saying that the structure of the files in xenlinux may change soon so that the xen-specific files would move to a subdirectory or arch/<arch> (e.g. linux/arch/i386/xen instead of linux/arch/xen/i386). Is this still planned? If so, what is the timing? If it''s in progress, I''d like to get in the loop... Thanks, Dan

Due to recent changes in timer handling (specifically building hpet emulation on top of Xen system time and ensuring it is monotonic), I wonder if it now makes sense to: 1) change hvm default for hpet to 1 (was 0) 2) change hvm timer_mode default from 0 to 2 I encouraged adding the hvm hpet parameter and defaulting it to 0 because the virtual hpet was not reliable and many guests/versions

All, I am running xen3.0.2 and xen unstable on RHEL 4, and get this error when trying to boot Xen kernel(domain0) ...... Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempting to kill init! Then system reboot.In grub.conf,I have

All, I am running xen3.0.2 and xen unstable on RHEL 4, and get this error when trying to boot Xen kernel(domain0) ...... Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempting to kill init! Then system reboot.In grub.conf,I have

Hi, all Those days, we spent some efforts to check severe error handling (panic, BUG_ON, BUG, ASSERT) in XEN. We have several round internal discussions as well as several mail threads with Keir. Below is the discussion writeup. If agreed, after review, we want to place it in XEN document folder or XEN wiki since we think it might be helpful to developers. Thanks a lot for your help! Regards,