From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@suse.de>
Cc: Xen-devel <xen-devel@lists.xensource.com>,
lkml <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@sous-sol.org>,
virtualization@lists.osdl.org,
Andrew Morton <akpm@linux-foundation.org>,
Keir Fraser <keir@xensource.com>
Subject: [patch 27/28]xen: Place vcpu_info structure into per-cpu memory, if possible
Date: Thu, 10 May 2007 17:07:10 -0700 [thread overview]
Message-ID: <20070511001209.902851000@goop.org> (raw)
In-Reply-To: 20070511000643.025196000@goop.org
[-- Attachment #1: xen-place-vcpu.patch --]
[-- Type: text/plain, Size: 7434 bytes --]
An experimental patch for Xen allows guests to place their vcpu_info
structs anywhere. We try to use this to place the vcpu_info into the
PDA, which allows direct access.
If this works, then switch to using direct access operations for
irq_enable, disable, save_fl and restore_fl.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Keir Fraser <keir@xensource.com>
---
arch/i386/xen/enlighten.c | 121 +++++++++++++++++++++++++++++++++++++++++-
arch/i386/xen/setup.c | 8 --
include/xen/interface/vcpu.h | 13 ++++
3 files changed, 133 insertions(+), 9 deletions(-)
===================================================================
--- a/arch/i386/xen/enlighten.c
+++ b/arch/i386/xen/enlighten.c
@@ -61,9 +61,55 @@ struct start_info *xen_start_info;
struct start_info *xen_start_info;
EXPORT_SYMBOL_GPL(xen_start_info);
+static /* __initdata */ struct shared_info dummy_shared_info;
+
+/*
+ * Point at some empty memory to start with. We map the real shared_info
+ * page as soon as fixmap is up and running.
+ */
+struct shared_info *HYPERVISOR_shared_info = (void *)&dummy_shared_info;
+
+/* tristate - -1: not tested, 0: not available, 1: available */
+static int have_vcpu_info_placement = -1;
+
void xen_vcpu_setup(int cpu)
{
+ struct vcpu_register_vcpu_info info;
+ int err;
+ struct vcpu_info *vcpup;
+
per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
+
+ if (!have_vcpu_info_placement)
+ return; /* already tested, not available */
+
+ vcpup = &per_cpu(xen_vcpu_info, cpu);
+
+ printk("setting up vcpu for %d: xen_vcpu_info=%p\n",
+ cpu, vcpup);
+
+ info.mfn = virt_to_mfn(vcpup);
+ info.offset = offset_in_page(vcpup);
+
+ printk("trying to map vcpu_info %d at %p, mfn %x, offset %d\n",
+ cpu, vcpup, info.mfn, info.offset);
+
+ /* Check to see if the hypervisor will put the vcpu_info
+ structure where we want it, which allows direct access via
+ a percpu-variable. */
+ err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+
+ BUG_ON(err != 0 && err != -ENOSYS);
+ BUG_ON(err && have_vcpu_info_placement==1); /* all or nothing */
+
+ have_vcpu_info_placement = 0;
+
+ if (err == 0) {
+ have_vcpu_info_placement = 1;
+ per_cpu(xen_vcpu, cpu) = vcpup;
+ printk("cpu %d using vcpu_info at %p\n",
+ cpu, vcpup);
+ }
}
static void __init xen_banner(void)
@@ -123,6 +169,20 @@ static unsigned long xen_save_fl(void)
return (-flags) & X86_EFLAGS_IF;
}
+static unsigned long xen_save_fl_direct(void)
+{
+ unsigned long flags;
+
+ /* flag has opposite sense of mask */
+ flags = !x86_read_percpu(xen_vcpu_info.evtchn_upcall_mask);
+
+ /* convert to IF type flag
+ -0 -> 0x00000000
+ -1 -> 0xffffffff
+ */
+ return (-flags) & X86_EFLAGS_IF;
+}
+
static void xen_restore_fl(unsigned long flags)
{
struct vcpu_info *vcpu;
@@ -149,6 +209,25 @@ static void xen_restore_fl(unsigned long
}
}
+static void xen_restore_fl_direct(unsigned long flags)
+{
+ /* convert from IF type flag */
+ flags = !(flags & X86_EFLAGS_IF);
+
+ /* This is an atomic update, so no need to worry about
+ preemption. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, flags);
+
+ /* If we get preempted here, then any pending event will be
+ handled anyway. */
+
+ if (flags == 0) {
+ barrier(); /* unmask then check (avoid races) */
+ if (unlikely(x86_read_percpu(xen_vcpu_info.evtchn_upcall_pending)))
+ force_evtchn_callback();
+ }
+}
+
static void xen_irq_disable(void)
{
/* There's a one instruction preempt window here. We need to
@@ -157,6 +236,12 @@ static void xen_irq_disable(void)
preempt_disable();
x86_read_percpu(xen_vcpu)->evtchn_upcall_mask = 1;
preempt_enable_no_resched();
+}
+
+static void xen_irq_disable_direct(void)
+{
+ /* Atomic update, so preemption not a concern. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, 1);
}
static void xen_irq_enable(void)
@@ -176,6 +261,19 @@ static void xen_irq_enable(void)
barrier(); /* unmask then check (avoid races) */
if (unlikely(vcpu->evtchn_upcall_pending))
+ force_evtchn_callback();
+}
+
+static void xen_irq_enable_direct(void)
+{
+ /* Atomic update, so preemption not a concern. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, 0);
+
+ /* Doesn't matter if we get preempted here, because any
+ pending event will get dealt with anyway. */
+
+ barrier(); /* unmask then check (avoid races) */
+ if (unlikely(x86_read_percpu(xen_vcpu_info.evtchn_upcall_pending)))
force_evtchn_callback();
}
@@ -538,9 +636,19 @@ static void xen_flush_tlb_others(const c
xen_mc_issue(PARAVIRT_LAZY_MMU);
}
+static void xen_write_cr2(unsigned long cr2)
+{
+ x86_read_percpu(xen_vcpu)->arch.cr2 = cr2;
+}
+
static unsigned long xen_read_cr2(void)
{
return x86_read_percpu(xen_vcpu)->arch.cr2;
+}
+
+static unsigned long xen_read_cr2_direct(void)
+{
+ return x86_read_percpu(xen_vcpu_info.arch.cr2);
}
static void xen_write_cr4(unsigned long cr4)
@@ -775,7 +883,7 @@ static const struct paravirt_ops xen_par
.write_cr0 = native_write_cr0,
.read_cr2 = xen_read_cr2,
- .write_cr2 = native_write_cr2,
+ .write_cr2 = xen_write_cr2,
.read_cr3 = xen_read_cr3,
.write_cr3 = xen_write_cr3,
@@ -963,6 +1071,17 @@ static asmlinkage void __init xen_start_
x86_write_percpu(xen_cr3, __pa(pgd));
xen_vcpu_setup(0);
+ /* xen_vcpu_setup managed to place the vcpu_info within the
+ pda, so make use of it */
+ BUG_ON(have_vcpu_info_placement == -1);
+ if (have_vcpu_info_placement) {
+ paravirt_ops.save_fl = xen_save_fl_direct;
+ paravirt_ops.restore_fl = xen_restore_fl_direct;
+ paravirt_ops.irq_disable = xen_irq_disable_direct;
+ paravirt_ops.irq_enable = xen_irq_enable_direct;
+ paravirt_ops.read_cr2 = xen_read_cr2_direct;
+ }
+
paravirt_ops.kernel_rpl = 1;
if (xen_feature(XENFEAT_supervisor_mode_kernel))
paravirt_ops.kernel_rpl = 0;
===================================================================
--- a/arch/i386/xen/setup.c
+++ b/arch/i386/xen/setup.c
@@ -22,14 +22,6 @@
/* These are code, but not functions. Defined in entry.S */
extern const char xen_hypervisor_callback[];
extern const char xen_failsafe_callback[];
-
-static __initdata struct shared_info init_shared;
-
-/*
- * Point at some empty memory to start with. We map the real shared_info
- * page as soon as fixmap is up and running.
- */
-struct shared_info *HYPERVISOR_shared_info = &init_shared;
unsigned long *phys_to_machine_mapping;
EXPORT_SYMBOL(phys_to_machine_mapping);
===================================================================
--- a/include/xen/interface/vcpu.h
+++ b/include/xen/interface/vcpu.h
@@ -151,6 +151,19 @@ struct vcpu_set_singleshot_timer {
#define _VCPU_SSHOTTMR_future (0)
#define VCPU_SSHOTTMR_future (1U << _VCPU_SSHOTTMR_future)
+/*
+ * Register a memory location in the guest address space for the
+ * vcpu_info structure. This allows the guest to place the vcpu_info
+ * structure in a convenient place, such as in a per-cpu data area.
+ * The pointer need not be page aligned, but the structure must not
+ * cross a page boundary.
+ */
+#define VCPUOP_register_vcpu_info 10 /* arg == struct vcpu_info */
+struct vcpu_register_vcpu_info {
+ uint32_t mfn; /* mfn of page to place vcpu_info */
+ uint32_t offset; /* offset within page */
+};
+
#endif /* __XEN_PUBLIC_VCPU_H__ */
/*
--
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
virtualization@lists.osdl.org,
lkml <linux-kernel@vger.kernel.org>,
Chris Wright <chrisw@sous-sol.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Keir Fraser <keir@xensource.com>
Subject: [patch 27/28]xen: Place vcpu_info structure into per-cpu memory, if possible
Date: Thu, 10 May 2007 17:07:10 -0700 [thread overview]
Message-ID: <20070511001209.902851000@goop.org> (raw)
In-Reply-To: 20070511000643.025196000@goop.org
[-- Attachment #1: xen-place-vcpu.patch --]
[-- Type: text/plain, Size: 7435 bytes --]
An experimental patch for Xen allows guests to place their vcpu_info
structs anywhere. We try to use this to place the vcpu_info into the
PDA, which allows direct access.
If this works, then switch to using direct access operations for
irq_enable, disable, save_fl and restore_fl.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Keir Fraser <keir@xensource.com>
---
arch/i386/xen/enlighten.c | 121 +++++++++++++++++++++++++++++++++++++++++-
arch/i386/xen/setup.c | 8 --
include/xen/interface/vcpu.h | 13 ++++
3 files changed, 133 insertions(+), 9 deletions(-)
===================================================================
--- a/arch/i386/xen/enlighten.c
+++ b/arch/i386/xen/enlighten.c
@@ -61,9 +61,55 @@ struct start_info *xen_start_info;
struct start_info *xen_start_info;
EXPORT_SYMBOL_GPL(xen_start_info);
+static /* __initdata */ struct shared_info dummy_shared_info;
+
+/*
+ * Point at some empty memory to start with. We map the real shared_info
+ * page as soon as fixmap is up and running.
+ */
+struct shared_info *HYPERVISOR_shared_info = (void *)&dummy_shared_info;
+
+/* tristate - -1: not tested, 0: not available, 1: available */
+static int have_vcpu_info_placement = -1;
+
void xen_vcpu_setup(int cpu)
{
+ struct vcpu_register_vcpu_info info;
+ int err;
+ struct vcpu_info *vcpup;
+
per_cpu(xen_vcpu, cpu) = &HYPERVISOR_shared_info->vcpu_info[cpu];
+
+ if (!have_vcpu_info_placement)
+ return; /* already tested, not available */
+
+ vcpup = &per_cpu(xen_vcpu_info, cpu);
+
+ printk("setting up vcpu for %d: xen_vcpu_info=%p\n",
+ cpu, vcpup);
+
+ info.mfn = virt_to_mfn(vcpup);
+ info.offset = offset_in_page(vcpup);
+
+ printk("trying to map vcpu_info %d at %p, mfn %x, offset %d\n",
+ cpu, vcpup, info.mfn, info.offset);
+
+ /* Check to see if the hypervisor will put the vcpu_info
+ structure where we want it, which allows direct access via
+ a percpu-variable. */
+ err = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, cpu, &info);
+
+ BUG_ON(err != 0 && err != -ENOSYS);
+ BUG_ON(err && have_vcpu_info_placement==1); /* all or nothing */
+
+ have_vcpu_info_placement = 0;
+
+ if (err == 0) {
+ have_vcpu_info_placement = 1;
+ per_cpu(xen_vcpu, cpu) = vcpup;
+ printk("cpu %d using vcpu_info at %p\n",
+ cpu, vcpup);
+ }
}
static void __init xen_banner(void)
@@ -123,6 +169,20 @@ static unsigned long xen_save_fl(void)
return (-flags) & X86_EFLAGS_IF;
}
+static unsigned long xen_save_fl_direct(void)
+{
+ unsigned long flags;
+
+ /* flag has opposite sense of mask */
+ flags = !x86_read_percpu(xen_vcpu_info.evtchn_upcall_mask);
+
+ /* convert to IF type flag
+ -0 -> 0x00000000
+ -1 -> 0xffffffff
+ */
+ return (-flags) & X86_EFLAGS_IF;
+}
+
static void xen_restore_fl(unsigned long flags)
{
struct vcpu_info *vcpu;
@@ -149,6 +209,25 @@ static void xen_restore_fl(unsigned long
}
}
+static void xen_restore_fl_direct(unsigned long flags)
+{
+ /* convert from IF type flag */
+ flags = !(flags & X86_EFLAGS_IF);
+
+ /* This is an atomic update, so no need to worry about
+ preemption. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, flags);
+
+ /* If we get preempted here, then any pending event will be
+ handled anyway. */
+
+ if (flags == 0) {
+ barrier(); /* unmask then check (avoid races) */
+ if (unlikely(x86_read_percpu(xen_vcpu_info.evtchn_upcall_pending)))
+ force_evtchn_callback();
+ }
+}
+
static void xen_irq_disable(void)
{
/* There's a one instruction preempt window here. We need to
@@ -157,6 +236,12 @@ static void xen_irq_disable(void)
preempt_disable();
x86_read_percpu(xen_vcpu)->evtchn_upcall_mask = 1;
preempt_enable_no_resched();
+}
+
+static void xen_irq_disable_direct(void)
+{
+ /* Atomic update, so preemption not a concern. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, 1);
}
static void xen_irq_enable(void)
@@ -176,6 +261,19 @@ static void xen_irq_enable(void)
barrier(); /* unmask then check (avoid races) */
if (unlikely(vcpu->evtchn_upcall_pending))
+ force_evtchn_callback();
+}
+
+static void xen_irq_enable_direct(void)
+{
+ /* Atomic update, so preemption not a concern. */
+ x86_write_percpu(xen_vcpu_info.evtchn_upcall_mask, 0);
+
+ /* Doesn't matter if we get preempted here, because any
+ pending event will get dealt with anyway. */
+
+ barrier(); /* unmask then check (avoid races) */
+ if (unlikely(x86_read_percpu(xen_vcpu_info.evtchn_upcall_pending)))
force_evtchn_callback();
}
@@ -538,9 +636,19 @@ static void xen_flush_tlb_others(const c
xen_mc_issue(PARAVIRT_LAZY_MMU);
}
+static void xen_write_cr2(unsigned long cr2)
+{
+ x86_read_percpu(xen_vcpu)->arch.cr2 = cr2;
+}
+
static unsigned long xen_read_cr2(void)
{
return x86_read_percpu(xen_vcpu)->arch.cr2;
+}
+
+static unsigned long xen_read_cr2_direct(void)
+{
+ return x86_read_percpu(xen_vcpu_info.arch.cr2);
}
static void xen_write_cr4(unsigned long cr4)
@@ -775,7 +883,7 @@ static const struct paravirt_ops xen_par
.write_cr0 = native_write_cr0,
.read_cr2 = xen_read_cr2,
- .write_cr2 = native_write_cr2,
+ .write_cr2 = xen_write_cr2,
.read_cr3 = xen_read_cr3,
.write_cr3 = xen_write_cr3,
@@ -963,6 +1071,17 @@ static asmlinkage void __init xen_start_
x86_write_percpu(xen_cr3, __pa(pgd));
xen_vcpu_setup(0);
+ /* xen_vcpu_setup managed to place the vcpu_info within the
+ pda, so make use of it */
+ BUG_ON(have_vcpu_info_placement == -1);
+ if (have_vcpu_info_placement) {
+ paravirt_ops.save_fl = xen_save_fl_direct;
+ paravirt_ops.restore_fl = xen_restore_fl_direct;
+ paravirt_ops.irq_disable = xen_irq_disable_direct;
+ paravirt_ops.irq_enable = xen_irq_enable_direct;
+ paravirt_ops.read_cr2 = xen_read_cr2_direct;
+ }
+
paravirt_ops.kernel_rpl = 1;
if (xen_feature(XENFEAT_supervisor_mode_kernel))
paravirt_ops.kernel_rpl = 0;
===================================================================
--- a/arch/i386/xen/setup.c
+++ b/arch/i386/xen/setup.c
@@ -22,14 +22,6 @@
/* These are code, but not functions. Defined in entry.S */
extern const char xen_hypervisor_callback[];
extern const char xen_failsafe_callback[];
-
-static __initdata struct shared_info init_shared;
-
-/*
- * Point at some empty memory to start with. We map the real shared_info
- * page as soon as fixmap is up and running.
- */
-struct shared_info *HYPERVISOR_shared_info = &init_shared;
unsigned long *phys_to_machine_mapping;
EXPORT_SYMBOL(phys_to_machine_mapping);
===================================================================
--- a/include/xen/interface/vcpu.h
+++ b/include/xen/interface/vcpu.h
@@ -151,6 +151,19 @@ struct vcpu_set_singleshot_timer {
#define _VCPU_SSHOTTMR_future (0)
#define VCPU_SSHOTTMR_future (1U << _VCPU_SSHOTTMR_future)
+/*
+ * Register a memory location in the guest address space for the
+ * vcpu_info structure. This allows the guest to place the vcpu_info
+ * structure in a convenient place, such as in a per-cpu data area.
+ * The pointer need not be page aligned, but the structure must not
+ * cross a page boundary.
+ */
+#define VCPUOP_register_vcpu_info 10 /* arg == struct vcpu_info */
+struct vcpu_register_vcpu_info {
+ uint32_t mfn; /* mfn of page to place vcpu_info */
+ uint32_t offset; /* offset within page */
+};
+
#endif /* __XEN_PUBLIC_VCPU_H__ */
/*
--
next prev parent reply other threads:[~2007-05-11 0:07 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-11 0:06 [patch 00/28]xen: Xen implementation for paravirt_ops Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 01/28]xen: Allocate and free vmalloc areas Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 02/28]xen: Add nosegneg capability to the vsyscall page notes Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 20:07 ` Roland McGrath
2007-05-11 20:25 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 03/28]xen: Add Xen interface header files Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 04/28]xen: Core Xen implementation Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 05/28]xen: Xen virtual mmu Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 06/28]xen: xen event channels Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 07/28]xen: xen time implementation Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 08/28]xen: xen configuration Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 09/28]xen: Complete pagetable pinning for Xen Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 10/28]xen: ignore RW mapping of RO pages in pagetable_init Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 11/28]xen: fix multicall batching Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 12/28]xen: Account for time stolen by Xen Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 13/28]xen: Implement xen_sched_clock Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 14/28]xen: Xen SMP guest support Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 15/28]xen: Add support for preemption Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:06 ` [patch 16/28]xen: lazy-mmu operations Jeremy Fitzhardinge
2007-05-11 0:06 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 17/28]xen: deal with negative stolen time Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 18/28]xen: Use the hvc console infrastructure for Xen console Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 19/28]xen: Add early printk support via hvc console Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-12 19:08 ` [Xen-devel] " Bastian Blank
2007-05-12 19:57 ` Jeremy Fitzhardinge
2007-05-12 19:57 ` [Xen-devel] " Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 20/28]xen: Add Xen grant table support Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 21/28]xen: Add the Xenbus sysfs and virtual device hotplug driver Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 22/28]xen: Add Xen virtual block device driver Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 23/28]xen: rename xen netif_ structures to xen_netif_ Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 24/28]xen: Add the Xen virtual network device driver Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 25/28]xen: Xen machine operations Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 26/28]xen: handle external requests for shutdown, reboot and sysrq Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge [this message]
2007-05-11 0:07 ` [patch 27/28]xen: Place vcpu_info structure into per-cpu memory, if possible Jeremy Fitzhardinge
2007-05-11 0:07 ` [patch 28/28]xen: Attempt to patch inline versions of common operations Jeremy Fitzhardinge
2007-05-11 0:07 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070511001209.902851000@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=keir@xensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.osdl.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.