similar to: hypercall implementation

Xen Developers, I noticed that my PV ops guests cause the hypervisor to invoke hypercall_page_initialise twice from traps.c (i.e. through wrmsr_hypervisor_regs), for different hypercall_page addresses. Looking at the code, I see hvmloader.c causing one of those, in its main. I read the HVM Loader Xen wiki page, Googled, spelunked the source, etc. but cannot find where / why the other hypercall

Hi I need to use hypercalls from HVM domain (e.g. HYPERVISOR_add_to_physmap). However, it does not work when I am trying to invoke it from HVM Linux guest. Basically, I don''t see that anything happens on hypervisor''s side. I also grep''ed the guest code for ''vmmcall''/''vmcall'' and did not find anything. Is it possible to do it at all?

Hello, I am studing Xen hypercall now. I found that hypercall is invoked via hypercall_page, which is only filled with (in no-hypervisor-kernel-mode ): mov $i, %eax int $0x82 ret Why not invoked the hypercall directly by "int $0x82" ? What''s the advantage of using hypercall_page? Thanks, Wu _______________________________________________ Xen-devel mailing list

I am working on some other bugs and perf issues - and while working I noticed that both sparse and Coverity have reported some issues with Xen drivers. Please see attached various bug-fixes that I am proposing for 3.6.

This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. All DPRINT calls have been removed, and where needed have been replaced with pr_XX native calls. Many debug DPRINT calls have been removed outright. The amount of clutter this driver prints has been significantly reduced. Signed-off-by: Hank Janssen <hjanssen at microsoft.com>

This group of patches removes all DPRINT from hv_vmbus.ko. It is divided in several patches due to size. All DPRINT calls have been removed, and where needed have been replaced with pr_XX native calls. Many debug DPRINT calls have been removed outright. The amount of clutter this driver prints has been significantly reduced. Signed-off-by: Hank Janssen <hjanssen at microsoft.com>

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

Xen i386 xen-head.S fix sections mixup xen-head.S does not come back to the data section, leaving the text section as current section. It causes problems with a slightly enhanced DEBUG_RODATA that supports CONFIG_HOTPLUG and bringing a CPU up after the text has been marked read-only: reference to early_gdt_descr causes a page fault. It applies on 2.6.22-rc2-mm2. Signed-off-by: Mathieu Desnoyers

From: Haiyang Zhang <haiyangz at microsoft.com> Convert camel cased struct fields in hv.h to lower cases Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/hv.c | 95 +++++++++++++++++++++++--------------------- drivers/staging/hv/hv.h | 20 +++++----- drivers/staging/hv/vmbus.c |

From: Haiyang Zhang <haiyangz at microsoft.com> Convert camel cased struct fields in hv.h to lower cases Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/hv.c | 95 +++++++++++++++++++++++--------------------- drivers/staging/hv/hv.h | 20 +++++----- drivers/staging/hv/vmbus.c |

exit_idle() should be called after irq_enter(), otherwise it throws: [ 2.513020] [ INFO: suspicious RCU usage. ] [ 2.513076] 3.6.5 #1 Not tainted [ 2.513128] ------------------------------- [ 2.513183] include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! [ 2.513271] [ 2.513271] other info that might help us debug this: [ 2.513271] [ 2.513388] [

exit_idle() should be called after irq_enter(), otherwise it throws: [ 2.513020] [ INFO: suspicious RCU usage. ] [ 2.513076] 3.6.5 #1 Not tainted [ 2.513128] ------------------------------- [ 2.513183] include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle! [ 2.513271] [ 2.513271] other info that might help us debug this: [ 2.513271] [ 2.513388] [

Hey again, Am 2014-08-19 12:26, schrieb Jonas Meurer: > I encounter kernel crashes on an up-to-date Debian/Wheezy Xen domU with > the > stock kernel. The dom0 runs the same linux kernel and > xen/4.1.4-3+deb7u1. the bug is still reproducible with the latest kernel and Xen packages from Debian Wheezy. Unfortunately it seems like a corner case, somehow related to the hardware

Hi, I''m looking at a system hang on a large box: 160 cpus, 2TB. Dom0 is booted with 160 vcpus (don''t ask me why :)), and an HVM guest is started with over 1.5T RAM and 128 vcpus. The system hangs without much activity after couple hours. Xen 4.0.2 and 2.6.32 based 64bit dom0. During hang I discovered: Most of dom0 vcpus are in double_lock_balance spinning on one of the locks:

This apparently was a copy-and-paste oversight. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/arch/x86_64/kernel/head-xen.S +++ b/arch/x86_64/kernel/head-xen.S @@ -86,7 +86,7 @@ NEXT_PAGE(hypercall_page) CFI_REL_OFFSET rcx,0 .skip 2 /* push %r11 */ CFI_ADJUST_CFA_OFFSET 8 - CFI_REL_OFFSET rcx,0 + CFI_REL_OFFSET r11,0 .skip 5 /* mov $#,%eax */ .skip 2 /* syscall */ .skip

Hi, after solving the issue I had with a DVB tuner I tested again suspending and resuming from S3. I am now running Xen 4.2.0 and have applied patches [1] and [2] (any idea why they are still not in mainline?) over a 3.5.3 kernel. I only tried once since I upgraded my Xen, but after resuming I got the following back trace: [ 142.267299] pcieport 0000:00:1c.5: wake-up capability enabled by ACPI

Hello list, I just got this ominous bug on my machine, that has already been seen several times: http://lists.xensource.com/archives/html/xen-devel/2006-01/msg00180.html The machine is very similar, it''s a machine with two dual-core opterons, running one of the latest xen-3.0.3-unstable (20060926 hypervisor, and a vanilla 2.6.18 + xen patch from Fedora from 20060915). This machine was

The XenPVHVM extensions have not been tested much on very old hypervisors. At least Xen 3.4 gets some testing with the pvops kernel. Require at least Xen 3.4 for the PVonHVM extensions. If an older hypervisor is detected the extensions will be disabled and the guest will only see emulated hardware. Signed-off-by: Olaf Hering <olaf@aepfle.de> --- arch/x86/xen/enlighten.c | 27

I''m experimenting with xen + iscsi, and I founded that under heavy stress domU''s can crash entire system, I''ve reproduced this many many times. My system is like this Software: - iSCSI Enterprise Target v0.4.13 - RedHat AS4 update 4 64bit + Xen 3.0.3-0 Kernel 2.6.16.29 + Open iSCSI v2.0.730 (Initiator) - Bonnie++ v1.03a VM: - Debian 3.1r3 + Open iSCSI v2.0.730