similar to: [PATCH v4] x86/xen: Use __pa_symbol instead of __pa on C visible symbols

Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c

Hi Xen developers, We are hitting a DomU Linux kernel panic and we''d like to find a solution for it. We are porting our virtual appliance to Amazon''s AWS. Our kernel is 2.6.27.57. We know it is old but we have to stay with it for now. The problem is when the kernel (64-bit) boots up in EC2 ( a large instance with 7.5 GB memory), the kernel crashes when hitting the BUG in

what does it mean? i never seen that before xen4 on debian squeeze 2.6.32-5-xen-amd64 [22077.208077] BUG: soft lockup - CPU#7 stuck for 61s! [udisks-dm-expor:11772] [22077.208139] Modules linked in: ext4 jbd2 crc16 xfs exportfs xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_physdev bridge stp ip6table_filter ip6_tables iptable_filter ip_tables x_tables xen_evtchn xenfs fuse

Hello, From time to time I get this error and the lvcreate process becomes with D state and can not be killed? Any ideas why this happens? I use Debian Lenny with xen-4.0.1 [229995.580419] kernel BUG at /root/xen-4.0.1/linux-2.6-pvops.git/arch/x86/xen/mmu.c:1885! [229995.580624] invalid opcode: 0000 [#1] SMP [229995.580749] last sysfs file: /sys/devices/virtual/block/dm-49/removable

Hello, I''m using Debian Lenny with Xen 4.0.1 with standard 2.6.32.25 kernel In my new server after some period of running I got 100% usage of udev process and I can''t stop it. I upgraded to the newest libc and udev but the problem is here again. Here dmesg and pastebin http://pastebin.com/JNJPFSHz [1] [229995.580221] ------------[ cut here

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hi, we''re using Xen 3.3.0 on Debian Etch with 2.6.18.8 kernel from xen.org on dom0. We have problems starting Intrepid domU (using Intrepid''s kernel 2.6.27-7-server) if we give more than 4GB of memory to this domain. Using memory = ''4096'' works perfectly, but changing it to ''4097'' already gives an error. Can anyone put some light on this?

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-mm.patch) Memory management for paravirt_ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/mm/fault.c =================================================================== --- clean-start.orig/arch/x86_64/mm/fault.c +++

plain text document attachment (xx-paravirt-mm.patch) Memory management for paravirt_ops. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/mm/fault.c =================================================================== --- clean-start.orig/arch/x86_64/mm/fault.c +++

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

When operating on an unpinned pagetable (ie, one under construction or destruction), it isn''t necessary to use a hypercall to update a pud/pmd entry. Jan Beulich observed that a similar optimisation avoided many thousands of hypercalls while doing a kernel build. One tricky part is that early in the kernel boot there''s no page structure, so we can''t check to see if the

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Hi Linus, This is a huge set of several partly interrelated (and concurrently developed) changes, which is why the branch history is messier than one would like. The *really* big items are two humonguous patchsets mostly developed by Yinghai Lu at my request, which completely revamps the way we create initial page tables. In particular, rather than estimating how much memory we will need for

Xen: 3.2.1-rc5 64bit Dom0: 2.6.18.8 (at cs 524) 32-pae DomU: 2.6.26-rc8 32-pae root at newark13:~# xm create -f /linodes/xencaker/xen.conf -c Using config file "/linodes/xencaker/xen.conf". Started domain xencaker root at newark13:~# root at newark13:~# xm dmesg ... (XEN) traps.c:413:d332 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000] (XEN)

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

With the only bit in CR0 permitted to be changed by PV guests being TS, optimize the handling towards that: Keep a cached value in a per-CPU variable, and issue HYPERVISOR_fpu_taskswitch hypercalls for updates in all but the unusual case should something in the system still try to modify another bit (the attempt of which would then be logged by the hypervisor). This removes the need to have the