similar to: [PATCH] Add I/O hypercalls for i386 paravirt

In OLS 2005, we described the work that we have been doing in VMware with respect a common interface for paravirtualization of Linux. We shared the general vision in Rik's virtualization BoF. This note is an update on our further work on the Virtual Machine Interface, VMI. The patches provided have been tested on 2.6.16-rc6. We are currently recollecting performance information for the new

In OLS 2005, we described the work that we have been doing in VMware with respect a common interface for paravirtualization of Linux. We shared the general vision in Rik's virtualization BoF. This note is an update on our further work on the Virtual Machine Interface, VMI. The patches provided have been tested on 2.6.16-rc6. We are currently recollecting performance information for the new

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for the paravirt-ops backends? I believe VMI is in Andi's tree, plus or minus some bugfixes that are still being whittled in, but Andi, do you think the VMI code is in good shape for merging? It would be nice for everyone to clarify their upstream plans - is the goal still to get Xen and lguest merged for the next kernel

I booted into X11 and have networking working and a kernel compile = running. SMP and PAE should be less than a day away. This completes = the proof of concept, I believe ;) I didn't cc LKML since I didn't want to spam them with graphics. Very = controversial graphics. Hopefully you appreciate the humor. Zach -------------- next part -------------- A non-text attachment was

Hi, As something like VMI is expected to be supported soon by QEMU, I have a small question: does the virtualization API you are defining supports that the guest kernel code can be executed in ring 3 ? In QEMU for example, the guest kernel code can be executed either by the dynamic translator (in this case CS.rpl = 0 and SS.rpl = 0) or by the kqemu kernel module (in this case CS.rpl = 3 and

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

The VMI ROM has a mode where hypercalls can be queued and batched. This turns out to be a significant win during context switch, but must be done at a specific point before side effects to CPU state are visible to subsequent instructions. This is similar to the MMU batching hooks already provided. The same hooks could be used by the Xen backend to implement a context switch multicall. To

> On Tue, Jul 15, 2008 at 10:33 AM, Suresh Siddha > <suresh.b.siddha at intel.com> wrote: > > On Sun, Jul 13, 2008 at 10:19:35PM -0700, Yinghai Lu wrote: > >> > >> fix for pv. > >> > >> Signed-off-by: Yinghai Lu <yhlu.kernel at gmail.com> > >> > >> --- > >> arch/x86/kernel/paravirt.c | 5 ---- > >>

> On Tue, Jul 15, 2008 at 10:33 AM, Suresh Siddha > <suresh.b.siddha at intel.com> wrote: > > On Sun, Jul 13, 2008 at 10:19:35PM -0700, Yinghai Lu wrote: > >> > >> fix for pv. > >> > >> Signed-off-by: Yinghai Lu <yhlu.kernel at gmail.com> > >> > >> --- > >> arch/x86/kernel/paravirt.c | 5 ---- > >>

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

Master definition of VMI interface, including calls, constants, and interface version. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/include/asm-i386/mach-vmi/paravirtualInterface.h =================================================================== --- linux-2.6.16-rc5.orig/include/asm-i386/mach-vmi/paravirtualInterface.h 2006-03-08 10:08:45.000000000 -0800 +++

Found this looping Ubuntu installs with VMI. If unlucky enough to hit a vmalloc sync fault during a lazy mode = operation (from an IRQ handler for a module which was not yet populated = in current page directory, or from inside copy_one_pte, which touches = swap_map, and hit in an unused 4M region), the required PDE update would = never get flushed, causing an infinite page fault loop. This

Found this looping Ubuntu installs with VMI. If unlucky enough to hit a vmalloc sync fault during a lazy mode = operation (from an IRQ handler for a module which was not yet populated = in current page directory, or from inside copy_one_pte, which touches = swap_map, and hit in an unused 4M region), the required PDE update would = never get flushed, causing an infinite page fault loop. This

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

The VMI ROM detection and code patching mechanism is illustrated in setup.c. There ROM is a binary block published by the hypervisor, and and there are certainly implications of this. ROMs certainly have a history of being proprietary, very differently licensed pieces of software, and mostly under non-free licenses. Before jumping to the conclusion that this is a bad thing, let us consider more

At OLS I gave a talk on some of the Xen scalability inhibitors, and one of these was writable page tables. We went over why the feature does not scale, but just as important, we found that the uniprocessor case does not provide any advantage either. These tests were done on x86_64, so I wanted to run the 1-way test on 32 bit to show the same problem. So, I have run with writable PTs and

Fix reboot to work with the VMI. We must support fallback to the standard BIOS reboot mechanism. Turns out that this is required by kexec, and a good idea for native hardware. We simply insert the NOP VMI reboot hook before calling the BIOS reboot. While here, fix SMP reboot issues as well. The problem is the halt() macro in VMI has been defined to be equivalent to safe_halt(), which enables