linux-kernel - Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming memory address space

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150302033349.GA31395@kroah.com>
Date:	Sun, 1 Mar 2015 19:33:49 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Jake Oshins <jakeo@...rosoft.com>
Cc:	rafael.j.wysocki@...el.com, kys@...rosoft.com,
	linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
	olaf@...fle.de, apw@...onical.com, vkuznets@...hat.com
Subject: Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming
 memory address space

On Tue, Feb 17, 2015 at 11:41:49AM -0800, Jake Oshins wrote:
> This patch adds some wrapper functions in the pnp layer.  The intent is
> to allow memory address space claims by devices which are descendants
> (a child or grandchild of) a device which is already part of the pnp
> layer.  This allows a device to make a resource claim that doesn't
> conflict with its "aunts" and "uncles."
> 
> This is useful in a Hyper-V VM because some paravirtual "devices" need
> memory-mapped I/O space, and their aunts and uncles can be PCI devices.
> Furthermore, the hypervisor expresses the possible memory address
> combinations for the devices in the VM through the ACPI namespace.
> The paravirtual devices need to suballocate from the ACPI nodes, and
> they need to avoid conflicting with choices that the Linux PCI code
> makes about the PCI devices in the VM.
> 
> It might seem like this should be done in the platform layer rather
> than the pnp layer, but the platform layer assumes that the
> configuration of the devices in the machine are static, or at least
> expressed by firmware in a static fashion.  The nature of a Hyper-V
> VM is that new devices can be added while the machine is running,
> and the potential configurations for them are expressed as part of
> the paravirtual communications channel.  This much more naturally
> aligns with the pnp layer.
> 
> Signed-off-by: Jake Oshins <jakeo@...rosoft.com>
> ---
>  drivers/pnp/Makefile     |   2 +-
>  drivers/pnp/base.h       |   2 +
>  drivers/pnp/core.c       |   1 +
>  drivers/pnp/descendant.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pnp.h      |  23 ++++++++++
>  5 files changed, 144 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/pnp/descendant.c

At first glance, this looks ok.  Does it change the sysfs layout of
hyperv devices?

also, I'd like KY to sign-off on it, verifying that he at least tested
the series and it works for him.

thanks,

greg k-h
--
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/