virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
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__ */
 
 /*

-- 

  parent reply	other threads:[~2007-05-11  0:07 UTC|newest]

Thread overview: 33+ 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 ` [patch 01/28]xen: Allocate and free vmalloc areas Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 02/28]xen: Add nosegneg capability to the vsyscall page notes 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 ` [patch 04/28]xen: Core Xen implementation Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 05/28]xen: Xen virtual mmu Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 06/28]xen: xen event channels Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 07/28]xen: xen time implementation Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 08/28]xen: xen configuration Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 09/28]xen: Complete pagetable pinning for Xen 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 ` [patch 11/28]xen: fix multicall batching Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 12/28]xen: Account for time stolen by Xen Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 13/28]xen: Implement xen_sched_clock Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 14/28]xen: Xen SMP guest support Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 15/28]xen: Add support for preemption Jeremy Fitzhardinge
2007-05-11  0:06 ` [patch 16/28]xen: lazy-mmu operations Jeremy Fitzhardinge
2007-05-11  0:07 ` [patch 17/28]xen: deal with negative stolen time 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 ` [patch 19/28]xen: Add early printk support via hvc console Jeremy Fitzhardinge
2007-05-12 19:08   ` [Xen-devel] " Bastian Blank
2007-05-12 19:57     ` Jeremy Fitzhardinge
2007-05-11  0:07 ` [patch 20/28]xen: Add Xen grant table support 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 ` [patch 22/28]xen: Add Xen virtual block device driver 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 ` [patch 24/28]xen: Add the Xen virtual network device driver Jeremy Fitzhardinge
2007-05-11  0:07 ` [patch 25/28]xen: Xen machine operations 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 [this message]
2007-05-11  0:07 ` [patch 28/28]xen: Attempt to patch inline versions of common operations 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 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).