lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sun, 28 Jul 2013 00:54:20 +0800
From:	rui wang <ruiv.wang@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.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

>
> 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.
>

Thanks. If you think it's a cool idea, then I would like to see it
merged 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.
>

Sure. I'll keep only the PCI-related things in drivers/pci and move
other things out.

> 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 had only x86 in mind. But yes it should be made platform neutral.
I'll split it into neutral and arch-specific parts, so that other
archs can be supported easily.

> 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.
>

Yes building it statically in the kernel would be cleaner and easier
to use. I'll roll out a new version for you to review.

Thanks
Rui

>> 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