From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH] vfio: open VFIO container at startup rather than during init Date: Wed, 18 Jun 2014 08:57:15 +0000 Message-ID: References: <4bf447650cc99e316e6427e3a1c134dd417af4ec.1402996488.git.anatoly.burakov@intel.com> <5481188.YHqy5HFYGY@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Thomas Monjalon Return-path: In-Reply-To: <5481188.YHqy5HFYGY@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Thomas, > Subject: Re: [dpdk-dev] [PATCH] vfio: open VFIO container at startup rath= er > than during init >=20 > > Signed-off-by: Anatoly Burakov >=20 > Please Anatoly, could you provide a text explaining what was broken and > why you fixed it this way? What was broken was if, for some reason, VFIO is loaded but the user can't = initialize it (an example would be wrong permissions, or unsupported IOMMU = type, which is what Bruce seems to be having... which shouldn't happen as f= ar as I know, but there's nothing I can do on DPDK's side to fix this as th= is is the kernel reporting wrong kind of IOMMU type), DPDK would fail to lo= ad. The fix makes DPDK simply not try VFIO support at all if the container = cannot be opened for some reason. Best regards, Anatoly Burakov DPDK SW Engineer