similar to: Paravirt-ops VMI / Xen / lrustyvisor merge status

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?

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted hypervisors will be. I have been working on a fix for this which works for older glibcs that panic when the new relocatable VDSO is used. However, I believe at this time that the fix is going to be too radical to consider at this stage in the release of 2.6.21. We don't expect this config option to be turned on by

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 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

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 there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

So there is a logic error that would prevent us from ever using NOP = relocations, thus stopping any unnecessary callouts into a VMI ROM. It = doesn't affect us so much, but could conceivably affect open source = implementations of a VMI ROM in the future. It is not absolutely = critical, but it would be extremely nice to get it fixed in 2.6.21 so = there are no broken older kernels

Add a way to disable the timer IRQ routing check via a boot option. The VMI timer code uses this to avoid triggering the pester Mingo code, which probes for some very unusual and broken motherboard routings. It fires 100% of the time when using a paravirtual delay mechanism instead of using a realtime delay, since there is no elapsed real time, and the 4 timer IRQs have not yet been delivered.

Add a way to disable the timer IRQ routing check via a boot option. The VMI timer code uses this to avoid triggering the pester Mingo code, which probes for some very unusual and broken motherboard routings. It fires 100% of the time when using a paravirtual delay mechanism instead of using a realtime delay, since there is no elapsed real time, and the 4 timer IRQs have not yet been delivered.

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

> 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 ---- > >>

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

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