From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH] vfio: support iommu group zero Date: Wed, 9 Dec 2015 13:58:01 -0800 Message-ID: <20151209135801.17965487@xeon-e3> References: <1449683756-13381-1-git-send-email-stephen@networkplumber.org> <2562631.e9AmeysRzG@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Avi Kivity , Alex Williamson To: Thomas Monjalon Return-path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id 223C43787 for ; Wed, 9 Dec 2015 22:57:53 +0100 (CET) Received: by pabur14 with SMTP id ur14so36102540pab.0 for ; Wed, 09 Dec 2015 13:57:52 -0800 (PST) In-Reply-To: <2562631.e9AmeysRzG@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 09 Dec 2015 22:12:33 +0100 Thomas Monjalon wrote: > 2015-12-09 09:55, Stephen Hemminger: > > The current implementation of VFIO will not with the new no-IOMMU mode > > in 4.4 kernel. The original code assumed that IOMMU group zero would > > never be used. Group numbers are assigned starting at zero, and up > > until now the group numbers came from the hardware which is likely > > to use group 0 for system devices that are not used with DPDK. > > > > The fix is to allow 0 as a valid group and rearrange code > > to split the return value from the group value. > > > > Signed-off-by: Stephen Hemminger > > --- > > Why was this ignored? It was originally sent on 26 Oct 15 back > > when IOMMU discussion was lively. > > There was no review of this patch. > The patch has been marked as deferred recently when it was too late > to do such feature changes in DPDK code: > http://dpdk.org/dev/patchwork/patch/8035/ This is why as a fallback the MAINTAINER has to review the patch or direct a sub-maintainer to do it. I think almost 2 months is plenty of time for review. Another alternative policy is to have a "default yes" policy such that if there are no objections or discussion things that are submitted early just go in (that is what ZeroMQ does). http://rfc.zeromq.org/spec:22 * Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days). * Maintainers SHALL NOT make value judgments on correct patches. * Maintainers SHALL merge correct patches from other Contributors rapidly. * Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively. * Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches. * Maintainers MAY commit changes to non-source documentation directly to the project.