similar to: numbered patches in the paravirtops patch series

Rusty Russell wrote: > Chris: [RFC PATCH 12/33] Change __FIXADDR_TOP to leave room for the hypervisor. > - Replace with dynamic (Geerd) patch, put in paravirt_ops structure. > I'm looking at this, and I'm not sure that there needs to be a void (*set_fixmap_top)(unsigned long top) entry in paravirt ops. It seems to me that the hypervisor's init code can call the

>I probably shouldn''t have been operating machinery yesterday. >The crash is probably because I committed the e820 memory rearranging >stuff into the wrong branch, but something may have broken us from >tip/master as well. >   J Kernel was already broken at 2/28/09 --- On Sat, 2/28/09, Marc - A. Dahlhaus <mad@wol.de> wrote: From: Marc - A. Dahlhaus

I've updated the patches at http://ozlabs.org/~rusty/paravirt/?mf=33ba6c4fce13;path=/ to carve out the basic shape of how I see all this fitting together. These patches implement an initial set of Xen paravirt ops, as well as adapting head.S to set up a Xen-specific entrypoint. The head.S code does absolutely minimal setup, and then calls xen_start_kernel(). This installs the Xen

The kernel patch queue used by the Xen Cloud Platform domain 0 has been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the

The kernel patch queue used by the Xen Cloud Platform domain 0 has been published at: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg This kernel has been the recipient of extensive testing and performance optimization and is actively maintained with the latest stable drivers. There is ongoing work to merge patches which are not currently upstream into the paravirtops tree or to remove the

Hey all, I was watching some logs on a domU today and i suddenly noticed that the timestamps were off by something on the order of 47 seconds. I was surprised because *I don''t* run independent wall clocks. I checked some other domUs and the "drift" was also very close to that of the first domU. I also checked another dom0, Here the domUs were "only" out of sync by

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

Use newly added for_each_console for iterating consoles. Signed-off-by: Jiri Slaby <jslaby at suse.cz> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.osdl.org Cc: xen-devel at lists.xensource.com Cc: linux-fbdev at vger.kernel.org --- drivers/video/xen-fbfront.c | 2 +- 1 files changed, 1 insertions(+),

Use newly added for_each_console for iterating consoles. Signed-off-by: Jiri Slaby <jslaby at suse.cz> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.osdl.org Cc: xen-devel at lists.xensource.com Cc: linux-fbdev at vger.kernel.org --- drivers/video/xen-fbfront.c | 2 +- 1 files changed, 1 insertions(+),

Use newly added for_each_console for iterating consoles. Signed-off-by: Jiri Slaby <jslaby at suse.cz> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.osdl.org Cc: xen-devel at lists.xensource.com Cc: linux-fbdev at vger.kernel.org --- drivers/video/xen-fbfront.c | 2 +- 1 files changed, 1 insertions(+),

In your sequences in asm/paravirt.h, you explicitly save the caller-save regs: static inline void raw_local_irq_restore(unsigned long f) { __asm__ __volatile__(paravirt_alt("pushl %%ecx; pushl %%edx\n\t" "pushl %1; call *%0\n\t" "popl %1; popl %%edx; popl %%ecx", PARAVIRT_RESTORE_FLAGS) : : "m" (paravirt_ops.restore_fl),

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

Looks to me like the first series of patches should be OK to post now. I propose that: 001-apply-to-page-range.patch 001a-reboot-use-struct.patch 002-sync-bitops.patch 003-remove-ring0-assumptions.patch 004-abstract-asm.patch 005-cpuid-cleanup.patch unfix-fixmap.patch fixmap-bootparam.patch remove-read-hazard-from-cow.patch pte-clear-not-present.patch

Adding an STP state seems like a bad idea. Aren't br->stp_enabled and (dev->flags & IFF_UP) sufficient to determine whether check_link() should reenable a port? > -----Original Message----- > From: bridge-bounces@lists.osdl.org > [mailto:bridge-bounces@lists.osdl.org] On Behalf Of Mark Ruijter > Sent: Tuesday, July 20, 2004 7:25 AM > To: Stephen Hemminger > Cc:

Hi Rusty, I had a look over your 011-paravirt-head.S.patch. I'm struggling to come up with a list of any benefits over having separate entrypoints for each hypervisor. Multiple entry pros: * allows maximum startup flexibility for any given hypervisor * for Xen at least, it's pretty simple * the "what hypervisor am I under" question is answered trivially cons:

Hi, I'm not sure if this is apprriate or not, but here goes anyway. The patch below updates MAINTAIER address Individuals (Only Andrew :): osdl.org -> linux-foundation.org Lists: osdl.org -> lists.osdl.org I assume the latter will change at some stage, but at least with this change the osdl/linux-foundation lists are consistent. Signed-off-by: Simon Horman

Some concern was expressed over the lguest review status, so I shall send the patches out again for people to review, to test, to make observations about the author's personal appearance, etc. I'll plan on sending these patches off to Linus in a week's time, assuming all goes well. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body