similar to: What do we need to do to hit 2.6.19?

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

Hello, This series of patches integrates msr.h header. What it really does, is a series of steps to allow us to get rid of duplicate code between i386 and x86_64 versions With this done, achieving paravirt for x86_64 gets really easy, just a couple of extra code. The first patch was already sent a while ago, but was not yet pushed to any tree , to my knowledge. So it is sent again. Also,

Hello, This series of patches integrates msr.h header. What it really does, is a series of steps to allow us to get rid of duplicate code between i386 and x86_64 versions With this done, achieving paravirt for x86_64 gets really easy, just a couple of extra code. The first patch was already sent a while ago, but was not yet pushed to any tree , to my knowledge. So it is sent again. Also,

This version over last version: (1) Gets rid of the no_paravirt.h header and leaves native ops in place (with some reshuffling to keep then under one #ifdef). (2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug. (3) Puts __ex_table entry in paravirt iret. Another followup patch implements binary patching... Rusty. === Create a paravirt.h header for all the critical operations which

This version over last version: (1) Gets rid of the no_paravirt.h header and leaves native ops in place (with some reshuffling to keep then under one #ifdef). (2) Fixes the "X crashes with CONFIG_PARAVIRT=y" bug. (3) Puts __ex_table entry in paravirt iret. Another followup patch implements binary patching... Rusty. === Create a paravirt.h header for all the critical operations which

When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on the {rd,wr}msr instructions. This makes serious issues (either on the guest kernel, or on the host) be silently ignored, and is different from the native MSR code (which does not ignore the exceptions). As paravirt.h already includes linux/bug.h, I don't see what was the original issue preventing BUG_ON from being used.

When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on the {rd,wr}msr instructions. This makes serious issues (either on the guest kernel, or on the host) be silently ignored, and is different from the native MSR code (which does not ignore the exceptions). As paravirt.h already includes linux/bug.h, I don't see what was the original issue preventing BUG_ON from being used.

OK, this is the revised paravirt.h (Andi has seen this before), then the second is the binary patching stuff. More things get added to the paravirt struct in future patches, but this basic stuff hasn't changed for some time. ==== This patch does the dumbest possible replacement of paravirtualized instructions: calls through a "paravirt_ops" structure. Currently these are function

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to

I have finally gotten off the pot and finished writing up my new CPUID/MSR driver, which contains support for registers that need arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an x86-64 register image (16 64-bit register fields); this allows 32-bit userspace to access the full 64-bit image if the kernel is 64 bits. Anyway, this presumably requires new paravirtualization

I have finally gotten off the pot and finished writing up my new CPUID/MSR driver, which contains support for registers that need arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an x86-64 register image (16 64-bit register fields); this allows 32-bit userspace to access the full 64-bit image if the kernel is 64 bits. Anyway, this presumably requires new paravirtualization

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?

On Mon, Jul 28, 2014 at 12:18:10PM -0700, H. Peter Anvin wrote: > On 07/28/2014 12:04 PM, Eduardo Habkost wrote: > > When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on > > the {rd,wr}msr instructions. This makes serious issues (either on the > > guest kernel, or on the host) be silently ignored, and is different from > > the native MSR code (which does

On Mon, Jul 28, 2014 at 12:18:10PM -0700, H. Peter Anvin wrote: > On 07/28/2014 12:04 PM, Eduardo Habkost wrote: > > When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on > > the {rd,wr}msr instructions. This makes serious issues (either on the > > guest kernel, or on the host) be silently ignored, and is different from > > the native MSR code (which does

Can''t seem to fully boot a domU on either EM64T or Opteron with x86_64 xen-unstable. Both systems'' report this from xen: (XEN) (file=traps.c, line=872) Non-priv domain attempted WRMSR(00000000c0000100. (XEN) (file=traps.c, line=872) Non-priv domain attempted WRMSR(00000000c0000102. (XEN) (file=traps.c, line=880) Non-priv domain attempted RDMSR(00000000c0000080. They boot

nic@wuwei:/usr/src/xen/xen-unstable.hg$ sudo xm create breezy -c Using config file "/etc/xen/breezy". Started domain breezy Linux version 2.6.12-xenU (nic@wuwei) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #3 SMP Thu Oct 13 14:56:20 NZDT 2005 kernel direct mapping tables upto 10000000 @ 568000-5ea000 Built 1 zonelists Kernel command line: root=/dev/sda1 ro 4 lockd.udpport=32768