Stefano Stabellini
2010-May-10 14:20 UTC
[Xen-devel] [PATCH 05/11] xen pci platform device driver
Add the xen pci platform device driver that is responsible
for initializing the grant table and xenbus in PV on HVM mode.
Few changes to xenbus and grant table are necessary to allow the delayed
initialization in HVM mode.
Grant table needs few additional modifications to work in HVM mode.
When running on HVM the event channel upcall is never called while in
progress because it is a normal Linux irq handler, therefore we cannot
be sure that evtchn_upcall_pending is 0 when returning.
For this reason if evtchn_upcall_pending is set by Xen we need to loop
again on the event channels set pending otherwise we might loose some
event channel deliveries.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
drivers/xen/Kconfig | 11 ++-
drivers/xen/Makefile | 3 +-
drivers/xen/events.c | 5 +-
drivers/xen/grant-table.c | 70 +++++++++-
drivers/xen/platform-pci.c | 236 ++++++++++++++++++++++++++++++++++
drivers/xen/xenbus/xenbus_probe.c | 20 ++-
include/xen/grant_table.h | 1 +
include/xen/interface/grant_table.h | 1 +
include/xen/interface/platform_pci.h | 45 +++++++
include/xen/platform_pci.h | 41 ++++++
include/xen/xenbus.h | 1 +
11 files changed, 417 insertions(+), 17 deletions(-)
create mode 100644 drivers/xen/platform-pci.c
create mode 100644 include/xen/interface/platform_pci.h
create mode 100644 include/xen/platform_pci.h
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index cab100a..3e02457 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -60,4 +60,13 @@ config XEN_SYS_HYPERVISOR
Create entries under /sys/hypervisor describing the Xen
hypervisor environment. When running native or in another
virtual environment, /sys/hypervisor will still be present,
- but will have no xen contents.
\ No newline at end of file
+ but will have no xen contents.
+
+config XEN_PLATFORM_PCI
+ tristate "xen platform pci device driver"
+ depends on XEN
+ help
+ Driver for the Xen PCI Platform device: it is responsible for
+ initializing xenbus and grant_table when running in a Xen HVM
+ domain. As a consequence this driver is required to run any Xen PV
+ frontend on Xen HVM.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 7c28434..2a502d2 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_XEN_XENCOMM) += xencomm.o
obj-$(CONFIG_XEN_BALLOON) += balloon.o
obj-$(CONFIG_XEN_DEV_EVTCHN) += evtchn.o
obj-$(CONFIG_XENFS) += xenfs/
-obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o
\ No newline at end of file
+obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o
+obj-$(CONFIG_XEN_PLATFORM_PCI) += platform-pci.o
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index cd609f4..197ccbc 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -662,7 +662,7 @@ void __xen_evtchn_do_upcall(struct pt_regs *regs)
count = __get_cpu_var(xed_nesting_count);
__get_cpu_var(xed_nesting_count) = 0;
- } while(count != 1);
+ } while(count != 1 || vcpu_info->evtchn_upcall_pending);
out:
@@ -722,7 +722,8 @@ static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu)
struct evtchn_bind_vcpu bind_vcpu;
int evtchn = evtchn_from_irq(irq);
- if (!VALID_EVTCHN(evtchn))
+ if (!VALID_EVTCHN(evtchn) ||
+ (xen_hvm_domain() && !xen_have_vector_callback))
return -1;
/* Send future instances of this interrupt to other vcpu. */
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7d8f531..3b43013 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -36,10 +36,13 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
+#include <linux/io.h>
#include <xen/interface/xen.h>
#include <xen/page.h>
#include <xen/grant_table.h>
+#include <xen/platform_pci.h>
+#include <xen/interface/memory.h>
#include <asm/xen/hypercall.h>
#include <asm/pgtable.h>
@@ -57,6 +60,7 @@ static unsigned int boot_max_nr_grant_frames;
static int gnttab_free_count;
static grant_ref_t gnttab_free_head;
static DEFINE_SPINLOCK(gnttab_list_lock);
+static unsigned long hvm_pv_resume_frames;
static struct grant_entry *shared;
@@ -447,6 +451,30 @@ static int gnttab_map(unsigned int start_idx, unsigned int
end_idx)
unsigned int nr_gframes = end_idx + 1;
int rc;
+ if (xen_hvm_domain()) {
+ struct xen_add_to_physmap xatp;
+ unsigned int i = end_idx;
+ rc = 0;
+ /*
+ * Loop backwards, so that the first hypercall has the largest
+ * index, ensuring that the table will grow only once.
+ */
+ do {
+ xatp.domid = DOMID_SELF;
+ xatp.idx = i;
+ xatp.space = XENMAPSPACE_grant_table;
+ xatp.gpfn = (hvm_pv_resume_frames >> PAGE_SHIFT) + i;
+ rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+ if (rc != 0) {
+ printk(KERN_WARNING
+ "grant table add_to_physmap failed, err=%d\n", rc);
+ break;
+ }
+ } while (i-- > start_idx);
+
+ return rc;
+ }
+
frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
if (!frames)
return -ENOMEM;
@@ -474,9 +502,28 @@ static int gnttab_map(unsigned int start_idx, unsigned int
end_idx)
int gnttab_resume(void)
{
- if (max_nr_grant_frames() < nr_grant_frames)
+ unsigned int max_nr_gframes;
+
+ max_nr_gframes = max_nr_grant_frames();
+ if (max_nr_gframes < nr_grant_frames)
return -ENOSYS;
- return gnttab_map(0, nr_grant_frames - 1);
+
+ if (xen_pv_domain())
+ return gnttab_map(0, nr_grant_frames - 1);
+
+ if (!hvm_pv_resume_frames) {
+ hvm_pv_resume_frames = alloc_xen_mmio(PAGE_SIZE * max_nr_gframes);
+ shared = ioremap(hvm_pv_resume_frames, PAGE_SIZE * max_nr_gframes);
+ if (shared == NULL) {
+ printk(KERN_WARNING
+ "Fail to ioremap gnttab share frames\n");
+ return -ENOMEM;
+ }
+ }
+
+ gnttab_map(0, nr_grant_frames - 1);
+
+ return 0;
}
int gnttab_suspend(void)
@@ -503,15 +550,12 @@ static int gnttab_expand(unsigned int req_entries)
return rc;
}
-static int __devinit gnttab_init(void)
+int gnttab_init(void)
{
int i;
unsigned int max_nr_glist_frames, nr_glist_frames;
unsigned int nr_init_grefs;
- if (!xen_domain())
- return -ENODEV;
-
nr_grant_frames = 1;
boot_max_nr_grant_frames = __max_nr_grant_frames();
@@ -555,4 +599,16 @@ static int __devinit gnttab_init(void)
return -ENOMEM;
}
-core_initcall(gnttab_init);
+static int __devinit __gnttab_init(void)
+{
+ /* Delay grant-table initialization in the PV on HVM case */
+ if (xen_hvm_domain())
+ return 0;
+
+ if (!xen_pv_domain())
+ return -ENODEV;
+
+ return gnttab_init();
+}
+
+core_initcall(__gnttab_init);
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
new file mode 100644
index 0000000..3370e1a
--- /dev/null
+++ b/drivers/xen/platform-pci.c
@@ -0,0 +1,236 @@
+/******************************************************************************
+ * platform-pci.c
+ *
+ * Xen platform PCI device driver
+ * Copyright (c) 2005, Intel Corporation.
+ * Copyright (c) 2007, XenSource Inc.
+ * Copyright (c) 2010, Citrix
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <asm/io.h>
+
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+
+#include <xen/grant_table.h>
+#include <xen/platform_pci.h>
+#include <xen/interface/platform_pci.h>
+#include <xen/xenbus.h>
+#include <xen/events.h>
+#include <xen/hvm.h>
+
+#define DRV_NAME "xen-platform-pci"
+
+MODULE_AUTHOR("ssmith@xensource.com and
stefano.stabellini@eu.citrix.com");
+MODULE_DESCRIPTION("Xen platform PCI device");
+MODULE_LICENSE("GPL");
+
+static unsigned long platform_mmio;
+static unsigned long platform_mmio_alloc;
+static unsigned long platform_mmiolen;
+
+unsigned long alloc_xen_mmio(unsigned long len)
+{
+ unsigned long addr;
+
+ addr = platform_mmio + platform_mmio_alloc;
+ platform_mmio_alloc += len;
+ BUG_ON(platform_mmio_alloc > platform_mmiolen);
+
+ return addr;
+}
+
+static uint64_t get_callback_via(struct pci_dev *pdev)
+{
+ u8 pin;
+ int irq;
+
+ irq = pdev->irq;
+ if (irq < 16)
+ return irq; /* ISA IRQ */
+
+ pin = pdev->pin;
+
+ /* We don''t know the GSI. Specify the PCI INTx line instead. */
+ return ((uint64_t)0x01 << 56) | /* PCI INTx identifier */
+ ((uint64_t)pci_domain_nr(pdev->bus) << 32) |
+ ((uint64_t)pdev->bus->number << 16) |
+ ((uint64_t)(pdev->devfn & 0xff) << 8) |
+ ((uint64_t)(pin - 1) & 3);
+}
+
+static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id)
+{
+ xen_hvm_evtchn_do_upcall(get_irq_regs());
+ return IRQ_HANDLED;
+}
+
+static int xen_allocate_irq(struct pci_dev *pdev)
+{
+ return request_irq(pdev->irq, do_hvm_evtchn_intr,
+ IRQF_DISABLED | IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+ "xen-platform-pci", pdev);
+}
+
+static int __devinit platform_pci_init(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ int i, ret;
+ long ioaddr, iolen;
+ long mmio_addr, mmio_len;
+ uint64_t callback_via;
+
+ i = pci_enable_device(pdev);
+ if (i)
+ return i;
+
+ ioaddr = pci_resource_start(pdev, 0);
+ iolen = pci_resource_len(pdev, 0);
+
+ mmio_addr = pci_resource_start(pdev, 1);
+ mmio_len = pci_resource_len(pdev, 1);
+
+ if (mmio_addr == 0 || ioaddr == 0) {
+ dev_err(&pdev->dev, "no resources found\n");
+ ret = -ENOENT;
+ }
+
+ if (request_mem_region(mmio_addr, mmio_len, DRV_NAME) == NULL) {
+ dev_err(&pdev->dev, "MEM I/O resource 0x%lx @ 0x%lx busy\n",
+ mmio_addr, mmio_len);
+ ret = -EBUSY;
+ }
+
+ if (request_region(ioaddr, iolen, DRV_NAME) == NULL) {
+ dev_err(&pdev->dev, "I/O resource 0x%lx @ 0x%lx busy\n",
+ iolen, ioaddr);
+ ret = -EBUSY;
+ goto out;
+ }
+
+ platform_mmio = mmio_addr;
+ platform_mmiolen = mmio_len;
+
+ if (!xen_have_vector_callback) {
+ ret = xen_allocate_irq(pdev);
+ if (ret) {
+ printk(KERN_WARNING "request_irq failed err=%d\n", ret);
+ goto out;
+ }
+ callback_via = get_callback_via(pdev);
+ ret = xen_set_callback_via(callback_via);
+ if (ret) {
+ printk(KERN_WARNING
+ "Unable to set the evtchn callback err=%d\n", ret);
+ goto out;
+ }
+ }
+
+ alloc_xen_mmio_hook = alloc_xen_mmio;
+ platform_pci_resume_hook = platform_pci_resume;
+ platform_pci_disable_irq_hook = platform_pci_disable_irq;
+ platform_pci_enable_irq_hook = platform_pci_enable_irq;
+
+ ret = gnttab_init();
+ if (ret)
+ goto out;
+ ret = xenbus_probe_init();
+ if (ret)
+ goto out;
+
+out:
+ if (ret) {
+ release_mem_region(mmio_addr, mmio_len);
+ release_region(ioaddr, iolen);
+ pci_disable_device(pdev);
+ }
+
+ return ret;
+}
+
+#define XEN_PLATFORM_VENDOR_ID 0x5853
+#define XEN_PLATFORM_DEVICE_ID 0x0001
+static struct pci_device_id platform_pci_tbl[] __devinitdata = {
+ {XEN_PLATFORM_VENDOR_ID, XEN_PLATFORM_DEVICE_ID,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {0,}
+};
+
+MODULE_DEVICE_TABLE(pci, platform_pci_tbl);
+
+static struct pci_driver platform_driver = {
+ name: DRV_NAME,
+ probe : platform_pci_init,
+ id_table : platform_pci_tbl,
+};
+
+static int check_platform_magic(void)
+{
+ short magic;
+ char protocol, *err;
+
+ magic = inw(XEN_IOPORT_MAGIC);
+
+ if (magic != XEN_IOPORT_MAGIC_VAL) {
+ err = "unrecognised magic value";
+ goto no_dev;
+ }
+
+ protocol = inb(XEN_IOPORT_PROTOVER);
+
+ printk(KERN_DEBUG DRV_NAME "I/O protocol version %d\n", protocol);
+
+ switch (protocol) {
+ case 1:
+ outw(XEN_IOPORT_LINUX_PRODNUM, XEN_IOPORT_PRODNUM);
+ outl(XEN_IOPORT_LINUX_DRVVER, XEN_IOPORT_DRVVER);
+ if (inw(XEN_IOPORT_MAGIC) != XEN_IOPORT_MAGIC_VAL) {
+ printk(KERN_ERR DRV_NAME "blacklisted by host\n");
+ return -ENODEV;
+ }
+ break;
+ default:
+ err = "unknown I/O protocol version";
+ goto no_dev;
+ }
+
+ return 0;
+
+ no_dev:
+ printk(KERN_WARNING DRV_NAME "failed backend handshake: %s\n",
err);
+ return -ENODEV;
+}
+
+static int __init platform_pci_module_init(void)
+{
+ int rc;
+
+ rc = check_platform_magic();
+ if (rc < 0)
+ return rc;
+
+ rc = pci_register_driver(&platform_driver);
+ if (rc) {
+ printk(KERN_INFO DRV_NAME
+ ": No platform pci device model found\n");
+ return rc;
+ }
+ return 0;
+}
+
+module_init(platform_pci_module_init);
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 0fa7ccf..9057f8d 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -779,16 +779,24 @@ void xenbus_probe(struct work_struct *unused)
blocking_notifier_call_chain(&xenstore_chain, 0, NULL);
}
-static int __init xenbus_probe_init(void)
+static int __init __xenbus_probe_init(void)
+{
+ /* Delay initialization in the PV on HVM case */
+ if (xen_hvm_domain())
+ return 0;
+
+ if (!xen_pv_domain())
+ return -ENODEV;
+
+ return xenbus_probe_init();
+}
+
+int xenbus_probe_init(void)
{
int err = 0;
DPRINTK("");
- err = -ENODEV;
- if (!xen_domain())
- goto out_error;
-
/* Register ourselves with the kernel bus subsystem */
err = bus_register(&xenbus_frontend.bus);
if (err)
@@ -847,7 +855,7 @@ static int __init xenbus_probe_init(void)
return err;
}
-postcore_initcall(xenbus_probe_init);
+postcore_initcall(__xenbus_probe_init);
MODULE_LICENSE("GPL");
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index a40f1cd..811cda5 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -51,6 +51,7 @@ struct gnttab_free_callback {
u16 count;
};
+int gnttab_init(void);
int gnttab_suspend(void);
int gnttab_resume(void);
diff --git a/include/xen/interface/grant_table.h
b/include/xen/interface/grant_table.h
index 39da93c..39e5717 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -28,6 +28,7 @@
#ifndef __XEN_PUBLIC_GRANT_TABLE_H__
#define __XEN_PUBLIC_GRANT_TABLE_H__
+#include <xen/interface/xen.h>
/***********************************
* GRANT TABLE REPRESENTATION
diff --git a/include/xen/interface/platform_pci.h
b/include/xen/interface/platform_pci.h
new file mode 100644
index 0000000..bc230cd
--- /dev/null
+++ b/include/xen/interface/platform_pci.h
@@ -0,0 +1,45 @@
+/******************************************************************************
+ * platform_pci.h
+ *
+ * Interface for granting foreign access to page frames, and receiving
+ * page-ownership transfers.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the
"Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_PLATFORM_PCI_H__
+#define __XEN_PUBLIC_PLATFORM_PCI_H__
+
+#define XEN_IOPORT_BASE 0x10
+
+#define XEN_IOPORT_PLATFLAGS (XEN_IOPORT_BASE + 0) /* 1 byte access (R/W) */
+#define XEN_IOPORT_MAGIC (XEN_IOPORT_BASE + 0) /* 2 byte access (R) */
+#define XEN_IOPORT_UNPLUG (XEN_IOPORT_BASE + 0) /* 2 byte access (W) */
+#define XEN_IOPORT_DRVVER (XEN_IOPORT_BASE + 0) /* 4 byte access (W) */
+
+#define XEN_IOPORT_SYSLOG (XEN_IOPORT_BASE + 2) /* 1 byte access (W) */
+#define XEN_IOPORT_PROTOVER (XEN_IOPORT_BASE + 2) /* 1 byte access (R) */
+#define XEN_IOPORT_PRODNUM (XEN_IOPORT_BASE + 2) /* 2 byte access (W) */
+
+#define UNPLUG_ALL_IDE_DISKS 1
+#define UNPLUG_ALL_NICS 2
+#define UNPLUG_AUX_IDE_DISKS 4
+#define UNPLUG_ALL 7
+
+#endif /* __XEN_PUBLIC_PLATFORM_PCI_H__ */
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
new file mode 100644
index 0000000..59a120c
--- /dev/null
+++ b/include/xen/platform_pci.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * platform-pci.h
+ *
+ * Xen platform PCI device driver
+ * Copyright (c) 2004, Intel Corporation. <xiaofeng.ling@intel.com>
+ * Copyright (c) 2007, XenSource Inc.
+ * Copyright (c) 2010, Citrix
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#ifndef _XEN_PLATFORM_PCI_H
+#define _XEN_PLATFORM_PCI_H
+
+#include <linux/version.h>
+
+#define XEN_IOPORT_MAGIC_VAL 0x49d2
+#define XEN_IOPORT_LINUX_PRODNUM 0xffff
+#define XEN_IOPORT_LINUX_DRVVER ((LINUX_VERSION_CODE << 8) + 0x0)
+
+#ifdef CONFIG_XEN_PLATFORM_PCI
+unsigned long alloc_xen_mmio(unsigned long len);
+#else
+static inline unsigned long alloc_xen_mmio(unsigned long len)
+{
+ return ~0UL;
+}
+#endif
+
+#endif /* _XEN_PLATFORM_PCI_H */
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index b9763ba..7fa0c22 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -173,6 +173,7 @@ void unregister_xenbus_watch(struct xenbus_watch *watch);
void xs_suspend(void);
void xs_resume(void);
void xs_suspend_cancel(void);
+int xenbus_probe_init(void);
/* Used by xenbus_dev to borrow kernel''s store connection. */
void *xenbus_dev_request_and_reply(struct xsd_sockmsg *msg);
--
1.5.4.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-May-10 15:48 UTC
Re: [Xen-devel] [PATCH 05/11] xen pci platform device driver
On Mon, May 10, 2010 at 03:20:41PM +0100, Stefano Stabellini wrote:> Add the xen pci platform device driver that is responsible > for initializing the grant table and xenbus in PV on HVM mode. > Few changes to xenbus and grant table are necessary to allow the delayed > initialization in HVM mode. > Grant table needs few additional modifications to work in HVM mode. > > When running on HVM the event channel upcall is never called while in > progress because it is a normal Linux irq handler, therefore we cannot > be sure that evtchn_upcall_pending is 0 when returning. > For this reason if evtchn_upcall_pending is set by Xen we need to loop > again on the event channels set pending otherwise we might loose some > event channel deliveries. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > Signed-off-by: Sheng Yang <sheng@linux.intel.com> > --- > drivers/xen/Kconfig | 11 ++- > drivers/xen/Makefile | 3 +- > drivers/xen/events.c | 5 +- > drivers/xen/grant-table.c | 70 +++++++++- > drivers/xen/platform-pci.c | 236 ++++++++++++++++++++++++++++++++++ > drivers/xen/xenbus/xenbus_probe.c | 20 ++- > include/xen/grant_table.h | 1 + > include/xen/interface/grant_table.h | 1 + > include/xen/interface/platform_pci.h | 45 +++++++ > include/xen/platform_pci.h | 41 ++++++ > include/xen/xenbus.h | 1 + > 11 files changed, 417 insertions(+), 17 deletions(-) > create mode 100644 drivers/xen/platform-pci.c > create mode 100644 include/xen/interface/platform_pci.h > create mode 100644 include/xen/platform_pci.h > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index cab100a..3e02457 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -60,4 +60,13 @@ config XEN_SYS_HYPERVISOR > Create entries under /sys/hypervisor describing the Xen > hypervisor environment. When running native or in another > virtual environment, /sys/hypervisor will still be present, > - but will have no xen contents. > \ No newline at end of file > + but will have no xen contents. > + > +config XEN_PLATFORM_PCI > + tristate "xen platform pci device driver" > + depends on XENWasn''t there some XENBUS frontend depency needed here? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-May-10 20:40 UTC
Re: [Xen-devel] [PATCH 05/11] xen pci platform device driver
On 05/10/2010 07:20 AM, Stefano Stabellini wrote:> Add the xen pci platform device driver that is responsible > for initializing the grant table and xenbus in PV on HVM mode. > Few changes to xenbus and grant table are necessary to allow the delayed > initialization in HVM mode. > Grant table needs few additional modifications to work in HVM mode. > > When running on HVM the event channel upcall is never called while in > progress because it is a normal Linux irq handler, therefore we cannot > be sure that evtchn_upcall_pending is 0 when returning. >Won''t the event (and the interrupt it raises) still be pending when the handler returns?> For this reason if evtchn_upcall_pending is set by Xen we need to loop > again on the event channels set pending otherwise we might loose some > event channel deliveries. >See below...> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > Signed-off-by: Sheng Yang <sheng@linux.intel.com> > --- > drivers/xen/Kconfig | 11 ++- > drivers/xen/Makefile | 3 +- > drivers/xen/events.c | 5 +- > drivers/xen/grant-table.c | 70 +++++++++- > drivers/xen/platform-pci.c | 236 ++++++++++++++++++++++++++++++++++ > drivers/xen/xenbus/xenbus_probe.c | 20 ++- > include/xen/grant_table.h | 1 + > include/xen/interface/grant_table.h | 1 + > include/xen/interface/platform_pci.h | 45 +++++++ > include/xen/platform_pci.h | 41 ++++++ > include/xen/xenbus.h | 1 + > 11 files changed, 417 insertions(+), 17 deletions(-) > create mode 100644 drivers/xen/platform-pci.c > create mode 100644 include/xen/interface/platform_pci.h > create mode 100644 include/xen/platform_pci.h > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index cab100a..3e02457 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -60,4 +60,13 @@ config XEN_SYS_HYPERVISOR > Create entries under /sys/hypervisor describing the Xen > hypervisor environment. When running native or in another > virtual environment, /sys/hypervisor will still be present, > - but will have no xen contents. > \ No newline at end of file > + but will have no xen contents. > + > +config XEN_PLATFORM_PCI > + tristate "xen platform pci device driver" > + depends on XEN > + help > + Driver for the Xen PCI Platform device: it is responsible for > + initializing xenbus and grant_table when running in a Xen HVM > + domain. As a consequence this driver is required to run any Xen PV > + frontend on Xen HVM. > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > index 7c28434..2a502d2 100644 > --- a/drivers/xen/Makefile > +++ b/drivers/xen/Makefile > @@ -9,4 +9,5 @@ obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > obj-$(CONFIG_XEN_BALLOON) += balloon.o > obj-$(CONFIG_XEN_DEV_EVTCHN) += evtchn.o > obj-$(CONFIG_XENFS) += xenfs/ > -obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > \ No newline at end of file > +obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > +obj-$(CONFIG_XEN_PLATFORM_PCI) += platform-pci.o > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > index cd609f4..197ccbc 100644 > --- a/drivers/xen/events.c > +++ b/drivers/xen/events.c > @@ -662,7 +662,7 @@ void __xen_evtchn_do_upcall(struct pt_regs *regs) > > count = __get_cpu_var(xed_nesting_count); > __get_cpu_var(xed_nesting_count) = 0; > - } while(count != 1); > + } while(count != 1 || vcpu_info->evtchn_upcall_pending); >So the intention here is to pick up newly posted events while the event processing loop is running? But if this is necessary it won''t work, because it is still racy. For example, what happens if a new event is posted right here, just after the loop has exited? Will it get ignored? Or if it does need to be processed, why is the test in the loop necessary? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-May-11 11:26 UTC
Re: [Xen-devel] [PATCH 05/11] xen pci platform device driver
On Mon, 10 May 2010, Konrad Rzeszutek Wilk wrote:> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index cab100a..3e02457 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -60,4 +60,13 @@ config XEN_SYS_HYPERVISOR > > Create entries under /sys/hypervisor describing the Xen > > hypervisor environment. When running native or in another > > virtual environment, /sys/hypervisor will still be present, > > - but will have no xen contents. > > \ No newline at end of file > > + but will have no xen contents. > > + > > +config XEN_PLATFORM_PCI > > + tristate "xen platform pci device driver" > > + depends on XEN > > Wasn''t there some XENBUS frontend depency needed here? >On 2.6.32 there is no XENBUS module, all the xenbus stuff is compiled in when CONFIG_XEN is selected (see the hooks and function pointers I had to add in patch 8 to allow XEN_PLATFORM_PCI to be compiled as a module). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-May-11 11:53 UTC
Re: [Xen-devel] [PATCH 05/11] xen pci platform device driver
On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:> On 05/10/2010 07:20 AM, Stefano Stabellini wrote: > > Add the xen pci platform device driver that is responsible > > for initializing the grant table and xenbus in PV on HVM mode. > > Few changes to xenbus and grant table are necessary to allow the delayed > > initialization in HVM mode. > > Grant table needs few additional modifications to work in HVM mode. > > > > When running on HVM the event channel upcall is never called while in > > progress because it is a normal Linux irq handler, therefore we cannot > > be sure that evtchn_upcall_pending is 0 when returning. > > > > Won''t the event (and the interrupt it raises) still be pending when the > handler returns? >Reading handle_fasteoi_irq it doesn''t seem like it.> > For this reason if evtchn_upcall_pending is set by Xen we need to loop > > again on the event channels set pending otherwise we might loose some > > event channel deliveries. > > > > See below... > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > Signed-off-by: Sheng Yang <sheng@linux.intel.com> > > --- > > drivers/xen/Kconfig | 11 ++- > > drivers/xen/Makefile | 3 +- > > drivers/xen/events.c | 5 +- > > drivers/xen/grant-table.c | 70 +++++++++- > > drivers/xen/platform-pci.c | 236 ++++++++++++++++++++++++++++++++++ > > drivers/xen/xenbus/xenbus_probe.c | 20 ++- > > include/xen/grant_table.h | 1 + > > include/xen/interface/grant_table.h | 1 + > > include/xen/interface/platform_pci.h | 45 +++++++ > > include/xen/platform_pci.h | 41 ++++++ > > include/xen/xenbus.h | 1 + > > 11 files changed, 417 insertions(+), 17 deletions(-) > > create mode 100644 drivers/xen/platform-pci.c > > create mode 100644 include/xen/interface/platform_pci.h > > create mode 100644 include/xen/platform_pci.h > > > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index cab100a..3e02457 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -60,4 +60,13 @@ config XEN_SYS_HYPERVISOR > > Create entries under /sys/hypervisor describing the Xen > > hypervisor environment. When running native or in another > > virtual environment, /sys/hypervisor will still be present, > > - but will have no xen contents. > > \ No newline at end of file > > + but will have no xen contents. > > + > > +config XEN_PLATFORM_PCI > > + tristate "xen platform pci device driver" > > + depends on XEN > > + help > > + Driver for the Xen PCI Platform device: it is responsible for > > + initializing xenbus and grant_table when running in a Xen HVM > > + domain. As a consequence this driver is required to run any Xen PV > > + frontend on Xen HVM. > > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile > > index 7c28434..2a502d2 100644 > > --- a/drivers/xen/Makefile > > +++ b/drivers/xen/Makefile > > @@ -9,4 +9,5 @@ obj-$(CONFIG_XEN_XENCOMM) += xencomm.o > > obj-$(CONFIG_XEN_BALLOON) += balloon.o > > obj-$(CONFIG_XEN_DEV_EVTCHN) += evtchn.o > > obj-$(CONFIG_XENFS) += xenfs/ > > -obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > > \ No newline at end of file > > +obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o > > +obj-$(CONFIG_XEN_PLATFORM_PCI) += platform-pci.o > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c > > index cd609f4..197ccbc 100644 > > --- a/drivers/xen/events.c > > +++ b/drivers/xen/events.c > > @@ -662,7 +662,7 @@ void __xen_evtchn_do_upcall(struct pt_regs *regs) > > > > count = __get_cpu_var(xed_nesting_count); > > __get_cpu_var(xed_nesting_count) = 0; > > - } while(count != 1); > > + } while(count != 1 || vcpu_info->evtchn_upcall_pending); > > > > So the intention here is to pick up newly posted events while the event > processing loop is running? But if this is necessary it won''t work, > because it is still racy. For example, what happens if a new event is > posted right here, just after the loop has exited? Will it get > ignored? Or if it does need to be processed, why is the test in the > loop necessary? >Your example is not going to cause any trouble because in that case Xen will also send an interrupt to the guest that is going to have local irq disable at the time. When the first interrupt handling routing is finished, local irq will be enabled and the second interrupt will be served, therefore no event channels will be lost. The problem that I am trying to solve is making sure that when evtchn_upcall_pending is set by Xen and an interrupt is sent by Xen to the guest, we (the guest) handle the event channel. In particular the problem was that during event channel handling we re-enable irqs so a second irq may be served but the second handler wouldn''t go as far as resetting evtchn_upcall_pending because as soon as it realizes that another one is in progress the fasteoi handler will exits. Therefore we have to reset evtchn_upcall_pending and handle the event channel directly in the first handler. Since this only happens when we re-enable irqs we can make sure that we''ll be able to handle the new event channel in the same loop. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel