similar to: xenoprof passive profiling and "mode" setting

See below... ---------- Forwarded Message ---------- Subject: RE: [Xen-devel] xenoprof passive profiling and "mode" setting Date: Wednesday 05 July 2006 21:53 From: "Yang, Xiaowei" <xiaowei.yang@intel.com> To: "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>, "Ray Bryant" <raybry@mpdtxmail.amd.com> Cc: xen-devel@lists.xensource.com

1: correct LDT checks 2: add address validity check to guest_map_l1e() 3: use {rd,wr}{fs,gs}base when available 4: check for canonical address before doing page walks Signed-off-by: Jan Beulich <jbeulich@suse.com>

Hi Renato, This patch is to add Xenoprof passive domain support in SMP environment. Basically: - It allocates per vcpu buffers for passive domain and maps them into primary domain''s space. - When primary domain gets sampled and triggers virq, its kernel module will handle passive domain'' samples besides its owns. There is potential buffer overflow if passive is very busy while

I''m looking into getting Xenoprof to tun in an HVM domain, since we will eventually need a profiler for HVM domains to track down areas of poor performance. (HVMs have poor performance? :) ) Being relatively new to OProfile, Xenoprof, and Xen internals, I would appreciate any pointers, tips, and comments on how to work the implementation. I see three basic areas of work. 1. Implement

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

an obvious fix to PIC IO intercept. In PIC IO, address from send_pio_req is physical address already. Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com> Signed-off-by: Xiaowei Yang <xiaowei.yang@intel.com> Signed-off-by: Xin Li <xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Keir, This patch fixes cirrus and rt8139 co-exist issue in new qemu-dm. The root cause is that if two MMIO spaces are continuous, qemu may misuse last MMIO space''s read/write to handle current request. Thanks, Xiaowei Signed-off-by: Yang Xiaowei <xiaowei.yang@intel.com> diff -r ecb8ff1fcf1f tools/ioemu/target-i386-dm/exec-dm.c --- a/tools/ioemu/target-i386-dm/exec-dm.c Fri

On map: only flush when old PTE was valid or invalid PTE may be cached. On unmap: always flush old entry, but skip flush for unaffected IOMMUs. Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com> -- iommu.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- diff -r 8187fd8113f9 xen/drivers/passthrough/vtd/iommu.c ---

We weren''t taking the guest mode (CPSR) into account and would always access the user version of the registers. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- v2: Fix r8 vs r8_fiq thinko. --- xen/arch/arm/traps.c | 62 ++++++++++++++++++++++++++++++++++++++++++- xen/arch/arm/vgic.c | 4 +- xen/arch/arm/vpl011.c | 4 +- xen/arch/arm/vtimer.c

Keir, The patch moves ACPI timer to HV, which is the last platform timer in Qemu. We found Vista polls ACPI timer very frequently (about 15 times averagely) when handling timer (RTC @ 64HZ) interrupt routine. Though the exact reason is known, it should be related to system time adjustment. When it''s in Qemu, the overhead is big. After moving, Vista''s idle overhead decreases

Keir: This is to to make the IDE device model multithreading so that the VMX domain IO access completion (triggering DMA operation) can be asynchronize with the completion of DMA operation. With this patch we get 8%--14% performance gain for kernel build. Thanks, eddie Yang, Xiaowei wrote: > Originally in qemu when a IDE dma transfer is started which is > triggered by access to 0xc000

Hi, I am using a freebsd 4.5-stable system. I am using the latest "rsync version 2.5.5 protocol version 26". I tried to rsync my home directory to another machine: rsync -Cavz /homes/yxw/ baggie.mit.edu:/disk1/ &> rsync.out& However, I ran into the error: www/wf-02.jpg www/wf-03.jpg www/www.c www/www.tar www/xiaowei.doc www/xiaowei_dadmom.jpg www/yxw-contact.txt wrote

[HVM] Pick up SMBIOS entry point in the ROMBIOS. Signed-off-by: Andrew D. Ball <aball@us.ibm.com> diff -r 1d817bfc5ed9 tools/firmware/rombios/rombios.c --- a/tools/firmware/rombios/rombios.c Fri Aug 11 14:22:54 2006 +0100 +++ b/tools/firmware/rombios/rombios.c Fri Aug 11 14:55:22 2006 -0400 @@ -9443,6 +9443,43 @@ rom_scan_increment: mov ds, ax ret +#ifdef HVMASSIST + +; Copy the

The original code only sets EN bit of IA32_PERFEVTSEL0 when profiling is started. Signed-off-by: Xiaowei Yang <xiaowei.yang@intel.com> Regards, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

From: "Xiaowei.Hu" <xiaowei.hu at oracle.com> ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace:

Recently we had a try of stubdom, whose general status is good. One issue we found is with aio/sync blktap as backend, disk performance is obviously slower, and there are some IDE kernel error messages (like irq timeout) at boot time. Another issue (not stubdom specific) comes from blktap''s support for QCOW image which is based on a backing file. We never tried this configure

While removing a non-empty directory, the kernel dumps a message: (rmdir,21743,1):ocfs2_unlink:953 ERROR: status = -39 Suppress the error message from being printed in the dmesg so users don't panic. Signed-off-by: Goldwyn Rodrigues <rgoldwyn at suse.com> --- diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c index 04ee1b5..33c7b91 100644 --- a/fs/ocfs2/namei.c +++ b/fs/ocfs2/namei.c @@

Hi, I implemented my own Hypercall in xen. Now I wish my application under dom0 could talk to Xen via my hypercall. Currently, I make a stub in dom0''s kernel, which works as a proxy to forward the request. So, my application first makes a system call to dom0, which then makes hypercall to xen. Is this design necessary? May I call hypercalls from user application under dom0 directly?

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values

Hi, I''ve added some preliminary support for VT-d for paravirtualized guests. This must be enabled using an ''iommu_pv'' boot parameter (disabled by default). I''ve added some python bindigs to allow xend to assign PCI devices to IOMMU for PV guests. For HVM guests this is handled in ioemu. Not sure if it makes sense to handle both cases in one place. The