linux-kernel - Re: [PATCH v3 -tip x86/apic 1/2] PCI/MSI: Allocate as many multiple-MSIs as requested

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:	Thu, 6 Jun 2013 21:51:18 +0200
From:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
To:	Alexander Gordeev <agordeev@...hat.com>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-pci@...r.kernel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Joerg Roedel <joro@...tes.org>,
	Jan Beulich <JBeulich@...e.com>,
	Ingo Molnar <mingo@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v3 -tip x86/apic 1/2] PCI/MSI: Allocate as many
 multiple-MSIs as requested

On Thu, Jun 06, 2013 at 10:30:20AM +0200, Alexander Gordeev wrote:
> Sebastian,
Hi Alexander,

> I re-read my comment few times and I admit it might be confusing. You are
> right - 'multiple' is set by rounding up only. The part '...not necessarily
> the closest power-of-two value...' implied an abstract PCI device rather than
> the described code, but the wording is less than perfect, indeed. 

Good, so it is not just me :)

> In fact, at the moment of writing I kept in mind a follow-up patch that could
> help with aforementioned devices. That would be a new interface:
> 
> 	int pci_enable_msi_block_partial(struct pci_dev *dev,
> 					 unsigned int nvec_use,
> 					 unsigned int nvec_init);
> 
> In this case 'nvec_use' would go to 'msi_desc::nvec_used' and 'nvec_init'
> would translate to 'msi_desc::multiple' in case 'nvec_init' is not zero.
> In case 'nvec_init' is zero, 'msi_desc::multiple' would be initialized
> with the maximum possible value for the device (the way it is done now for
> pci_enable_msi_block_auto() interface). So, for the AHCI device (Bjorn
> mentioned) such a call would conserve on 10 of 16 vectors:
> 
> 	pci_enable_msi_block_partial(pdev, 6, 0);

Ah okay. that makes sense.

> 
> What I am not sure is whether we need to read out the maximum possible
> number of vectors like pci_enable_msi_block_auto() does:
> 
> 	int pci_enable_msi_block_partial(struct pci_dev *dev,
> 					 unsigned int nvec_use,
> 					 unsigned int nvec_init,
> 					 unsigned int *maxvec);
> 
> I can not think of any use of 'maxvec' with this interface, but the second
> variant completes the whole picture about a device...
The user of pci_enable_msi_block_auto() does not know how many it will get
so argument seems essential. Your new function on the other hand says exactly
how many it requires. Anything less should be an error.

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