similar to: [PATCH 0/5] General cleanups for i386 from paravirt-ops work

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

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

In general, I/O in a virtual guest is subject to performance problems. = The I/O can not be completed physically, but must be virtualized. This = means trapping and decoding port I/O instructions from the guest OS. = Not only is the trap for a #GP heavyweight, both in the processor and = the hypervisor (which usually has a complex #GP path), but this forces = the hypervisor to decode the

In general, I/O in a virtual guest is subject to performance problems. = The I/O can not be completed physically, but must be virtualized. This = means trapping and decoding port I/O instructions from the guest OS. = Not only is the trap for a #GP heavyweight, both in the processor and = the hypervisor (which usually has a complex #GP path), but this forces = the hypervisor to decode the

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?

A clever set of manipulations allows us to fix binary modules with paravirt-ops by just not exporting paravirt_ops at all and using the new patching code. What do you think? Experimental patches here... only partially tested, but booting and appear to be a working prototype. Thanks, Zach

A clever set of manipulations allows us to fix binary modules with paravirt-ops by just not exporting paravirt_ops at all and using the new patching code. What do you think? Experimental patches here... only partially tested, but booting and appear to be a working prototype. Thanks, Zach

The custom_sched_clock hook is broken. The result from sched_clock needs to be in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose, because TSC is poorly defined in a virtual environment, and mostly represents real world time instead of scheduled process time (which can be interrupted without notice when a virtual machine is descheduled). To make the scheduler

The custom_sched_clock hook is broken. The result from sched_clock needs to be in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose, because TSC is poorly defined in a virtual environment, and mostly represents real world time instead of scheduled process time (which can be interrupted without notice when a virtual machine is descheduled). To make the scheduler

Not respecting udelay causes problems with any virtual hardware that is passed through to real hardware. This can be noticed by any device that interacts with the real world in real time - like AP startup, which takes real time. Or keyboard LEDs, which should blink in real-time. Or floppy drives, but only when passed through to a real floppy controller on OSes which can't sufficiently

Not respecting udelay causes problems with any virtual hardware that is passed through to real hardware. This can be noticed by any device that interacts with the real world in real time - like AP startup, which takes real time. Or keyboard LEDs, which should blink in real-time. Or floppy drives, but only when passed through to a real floppy controller on OSes which can't sufficiently

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

Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code. Please apply. If there are objections to certain pieces, they can be reworked, but they are pretty much all needed for correctness. We are hoping to get these in the next 2.6.21-rc release. We had quite a few difficulties debugging after the integration of the hrtimers code, which is why this took so long. Andrew, add

Andi, Linus, we have some critical bugfixes for the VMI paravirt-ops code. Please apply. If there are objections to certain pieces, they can be reworked, but they are pretty much all needed for correctness. We are hoping to get these in the next 2.6.21-rc release. We had quite a few difficulties debugging after the integration of the hrtimers code, which is why this took so long. Andrew, add

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