virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andrew Morton <akpm@linux-foundation.org>, Andi Kleen <ak@suse.de>
Cc: Xen-devel <xen-devel@lists.xensource.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@sous-sol.org>,
	virtualization@lists.osdl.org, Keir Fraser <keir@xensource.com>
Subject: [patch 32/33] xen: Place vcpu_info structure into per-cpu memory, if possible
Date: Tue, 22 May 2007 15:10:13 +0100	[thread overview]
Message-ID: <20070522141253.724096312@goop.org> (raw)
In-Reply-To: 20070522140941.802382212@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__ */
 
 /*

-- 

  parent reply	other threads:[~2007-05-22 14:10 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-22 14:09 [patch 00/33] xen: Xen paravirt_ops implementation Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 01/33] xen: paravirt: add an "mm" argument to alloc_pt Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 02/33] xen: paravirt: add a hook for once the allocator is ready Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 03/33] xen: paravirt: increase IRQ limit Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 04/33] xen: paravirt: unstatic leave_mm Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 05/33] xen: paravirt: unstatic smp_store_cpu_info Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 06/33] xen: paravirt: make siblingmap functions visible Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 07/33] xen: paravirt: export __supported_pte_mask Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 08/33] xen: Allocate and free vmalloc areas Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 09/33] xen: Add nosegneg capability to the vsyscall page notes Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 10/33] xen: Add Xen interface header files Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 11/33] xen: Core Xen implementation Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 12/33] xen: Xen virtual mmu Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 13/33] xen: xen event channels Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 14/33] xen: xen time implementation Jeremy Fitzhardinge
2007-06-06  8:39   ` Jan Beulich
2007-06-06  8:54     ` [Xen-devel] " Keir Fraser
2007-06-06  8:54     ` Keir Fraser
     [not found]     ` <C28C34EB.101FE%keir@xensource.com>
2007-06-06  9:30       ` Jan Beulich
2007-06-06  9:56         ` [Xen-devel] " Keir Fraser
2007-06-06  9:56         ` Keir Fraser
     [not found]         ` <C28C4362.1021C%keir@xensource.com>
2007-06-06 11:00           ` Jan Beulich
2007-06-06 11:52             ` [Xen-devel] " Keir Fraser
2007-06-06 11:52             ` Keir Fraser
2007-06-06 10:05     ` Jeremy Fitzhardinge
2007-06-06 10:20       ` Jan Beulich
2007-06-06 10:26       ` Andi Kleen
2007-06-06 14:15         ` [Xen-devel] " Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 15/33] xen: xen configuration Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 16/33] xen: xen: add pinned page flag Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 17/33] xen: Complete pagetable pinning for Xen Jeremy Fitzhardinge
2007-05-22 14:09 ` [patch 18/33] xen: xen: ignore RW mapping of RO pages in pagetable_init Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 19/33] xen: Account for time stolen by Xen Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 20/33] xen: Implement xen_sched_clock Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 21/33] xen: Xen SMP guest support Jeremy Fitzhardinge
2007-06-06  7:34   ` Jan Beulich
2007-06-06  8:33     ` [Xen-devel] " Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 22/33] xen: Add support for preemption Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 23/33] xen: xen: lazy-mmu operations Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 24/33] xen: xen: hack to prevent bad segment register reload Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 25/33] xen: Use the hvc console infrastructure for Xen console Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 26/33] xen: Add Xen grant table support Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 27/33] xen: Add the Xenbus sysfs and virtual device hotplug driver Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 28/33] xen: Add Xen virtual block device driver Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 29/33] xen: Add the Xen virtual network " Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 30/33] xen: Xen machine operations Jeremy Fitzhardinge
2007-05-22 14:10 ` [patch 31/33] xen: xen: handle external requests for shutdown, reboot and sysrq Jeremy Fitzhardinge
2007-05-22 14:10 ` Jeremy Fitzhardinge [this message]
2007-05-22 14:10 ` [patch 33/33] xen: Attempt to patch inline versions of common operations Jeremy Fitzhardinge
2007-05-22 14:57 ` [patch 00/33] xen: Xen paravirt_ops implementation Andi Kleen
2007-05-22 15:06   ` 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=20070522141253.724096312@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=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).