[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo653opkF_ROupSOYoP21LGwm023430Pyj_thbFeDXRq9w@mail.gmail.com>
Date: Fri, 26 Jul 2013 13:38:53 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Rui Wang <ruiv.wang@...il.com>
Cc: Tony Luck <tony.luck@...el.com>, chaohong.guo@...el.com,
Chen Gong <gong.chen@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rui Wang <rui.y.wang@...el.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [RFC 0/3] IO Hook: Method for emulating h/w events
[+cc linux-acpi]
On Fri, Jul 26, 2013 at 12:51 AM, Rui Wang <ruiv.wang@...il.com> wrote:
> Hi Bjorn,
>
> This was originally the method I used to test hotplug on Intel SDV machines
> which are not capable of doing hotplug. I would like to present it here in
> case it interests the community, then it can be made available to a wider
> range of developers who are working on hotplug.
>
> I used it to generate desired ACPI events, PCI interrupts, and more. So
> things like CPU hotplug, IOH hotplug, memory hotplug, PCI native hotplug,
> PCI AER injection can be emulated and tested easily.
>
> The best thing is that, it doesn't require any modification to those drivers
> involved. It works with whatever hardware events that the user can imagine.
> Further development in user-space using scripts may help simplify the usage
> model and add more software-defined logic on hardware.
>
> Because it modifies the heart of all h/w access functions, I used Jump Label
> to reduce the performance penalty to effectively zero.
This is a cool idea.
I don't know if you want to merge this upstream, or if it's just a "I
found this useful; here it is in case it's useful to you" sort of
thing. So the comments below are only relevant if you want to try to
merge it upstream.
I wouldn't really want all the gunk in drivers/pci/access.c. Most of
it isn't related to PCI, and some of it is even x86-specific. It'd be
nicer if you could factor it out so just the generic PCI-related
things go in drivers/pci.
It appears to be implemented only for x86. The MMIO & I/O port parts
are x86-specific, but the PCI config stuff should work on any arch.
I don't know whether it's worth supporting as a module. It seems like
a development aid where building in statically would probably be fine.
If it didn't have to work as a module, you wouldn't have to export
any symbols.
> I tested the performance by repeatedly running lspci, which calls into the
> pci access functions. There's no added overhead observed.
>
> Regards,
> Rui Wang
> Intel Open Source Technology Center
>
> Rui Wang (3):
> IO Hook: core functions and Register Override
> IO Hook: kernel interface to manage the hook
> IO Hook: sysfs interface to emulate h/w events
>
> Documentation/PCI/iohook.txt | 290 +++++++++++++++++
> arch/x86/Kconfig | 7 +
> arch/x86/boot/compressed/Makefile | 1 +
> arch/x86/include/asm/io.h | 58 ++++-
> arch/x86/vdso/Makefile | 2 +
> drivers/misc/Kconfig | 1 +
> drivers/misc/Makefile | 1 +
> drivers/misc/iohook/Kconfig | 5 +
> drivers/misc/iohook/Makefile | 1 +
> drivers/misc/iohook/iohook.c | 503 +++++++++++++++++++++++++++++
> drivers/pci/access.c | 630 +++++++++++++++++++++++++++++++++++++
> include/linux/reg_ovrd.h | 55 ++++
> 12 files changed, 1552 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/PCI/iohook.txt
> create mode 100644 drivers/misc/iohook/Kconfig
> create mode 100644 drivers/misc/iohook/Makefile
> create mode 100644 drivers/misc/iohook/iohook.c
> create mode 100644 include/linux/reg_ovrd.h
>
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists