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]
Date:	Tue, 15 Sep 2015 23:32:52 +0000
From:	Jake Oshins <jakeo@...rosoft.com>
To:	Marc Zyngier <marc.zyngier@....com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	KY Srinivasan <kys@...rosoft.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"olaf@...fle.de" <olaf@...fle.de>,
	"apw@...onical.com" <apw@...onical.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Jiang Liu <jiang.liu@...ux.intel.com>
Subject: RE: [PATCH v2 00/12] New paravirtual PCI front-end for Hyper-V VMs

> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier@....com]
> Sent: Tuesday, September 15, 2015 2:57 AM
> To: Jake Oshins <jakeo@...rosoft.com>; gregkh@...uxfoundation.org; KY
> Srinivasan <kys@...rosoft.com>; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; olaf@...fle.de; apw@...onical.com;
> vkuznets@...hat.com; linux-pci@...r.kernel.org; bhelgaas@...gle.com;
> tglx@...utronix.de; Jiang Liu <jiang.liu@...ux.intel.com>
> Subject: Re: [PATCH v2 00/12] New paravirtual PCI front-end for Hyper-V
> VMs
> 


> >
> > Is there a way to do that with the infrastructure that you're
> > introducing?
> 
> The ACPI/GSI stuff is a red herring, and is completely unrelated to the
> problem you're trying to solve. What I think is of interest to you is
> contained in the first three patches.
> 
> In your 4th patch, you have the following code:
> 
> +	pci_domain = pci_domain_nr(bus);
> +	d = irq_find_matching_host(NULL, DOMAIN_BUS_PCI_MSI,
> &pci_domain);
> 
> which really feels like you're trying to create a namespace that is
> parallel to the one defined by the device_node parameter. What I'm
> trying to do is to be able to replace the device_node by something more
> generic (at the moment, you can either pass a device_node or some token
> that the irqdomain subsystem generates for you - see patch #7 for an
> example).
> 
> You could pass this token to pci_msi_create_irq_domain (which obviously
> needs some repainting not to take a device_node), store it in your bus
> structure, and perform the lookup based on this value. Or store the
> actual domain there, whatever.
> 
> What I want to do is really to make this device_node pointer for systems
> that do not have a DT node to pass there, which is exactly your case (by
> the look of it, the bus number is your identifier of choice, but I
> suspect a pointer to an internal structure would be better suited).
> 
> 	M.
> --

Got it.  I'll rebase on your changes and send this series again, using the strategy that you outline here.  I may wait a little while until your patches make it into linux-next.

Thanks again,
Jake Oshins

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ