similar to: When will xen-compatibilty be standard in Linux kernels?

Folks, OLS is fast approaching. There is a session on virtualization at the Kernel Summit, with Keir and Zach invited, which will probably last an hour(?). There is also a Xen BoF currently scheduled (Thursday, 7/20, 7:00PM) which will cover Xen specific issues. And there are approximately 3 or 4 paper presentations on related subjects. None of the above are going to allow for adequate time to

Hi, XEN has a console that works in text mode ("xm console", e.g. via SSH). However with a German keyboard I''m having trouble to get out of the console again. Usually I login to Dom0 from another terminal, and then kill the xenconsole process. However I''d wish there was an easier way to get out. Maybe add a configurable escape key like for SSH? Regards, Ulrich

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

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

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

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we: 1. replace get_scheduled_cycles with sched_clock 2. hoist cycles_2_ns

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

* Greg KH (greg@kroah.com) wrote: > > Who said that? Please smack them on the head with a broom. We are all > > actively working on implementing Rusty's paravirt-ops proposal. It > > makes the API vs ABI discussion moot, as it allow for both. > > So everyone is still skirting the issue, oh great :) No, we are working closely together on Rusty's paravirt ops

* Greg KH (greg@kroah.com) wrote: > > Who said that? Please smack them on the head with a broom. We are all > > actively working on implementing Rusty's paravirt-ops proposal. It > > makes the API vs ABI discussion moot, as it allow for both. > > So everyone is still skirting the issue, oh great :) No, we are working closely together on Rusty's paravirt ops

Convert VMI timer to use clock events, making it properly able to use the NO_HZ infrastructure. On UP systems, with no local APIC, we just continue to route these events through the PIT. On systems with a local APIC, or SMP, we provide a single source interrupt chip which creates the local timer IRQ. It actually gets delivered by the APIC hardware, but we don't want to use the same local

Convert VMI timer to use clock events, making it properly able to use the NO_HZ infrastructure. On UP systems, with no local APIC, we just continue to route these events through the PIT. On systems with a local APIC, or SMP, we provide a single source interrupt chip which creates the local timer IRQ. It actually gets delivered by the APIC hardware, but we don't want to use the same local

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch

Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch