From owner-freebsd-virtualization@freebsd.org Thu Aug 9 16:24:12 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2766F106BD46 for ; Thu, 9 Aug 2018 16:24:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D30507C658 for ; Thu, 9 Aug 2018 16:24:11 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 18D6310B429; Thu, 9 Aug 2018 12:24:11 -0400 (EDT) Subject: Re: Passthrough not working with OpenBSD nor NetBSD To: Farid Joubbi References: Cc: freebsd-virtualization@freebsd.org From: John Baldwin Message-ID: Date: Thu, 9 Aug 2018 09:24:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 09 Aug 2018 12:24:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 16:24:12 -0000 On 8/8/18 11:08 AM, Farid Joubbi wrote: > That's what I also thought, but it's not anything I can force it to do, is it? Isn't it supposed to detect the MSI interrupt compatibility automatically? Apparently Open/Net always try to setup INTx before trying MSI even if they won't use INTx per the commit log in revision 280725. We could perhaps try to provide a "fake" INTx interrupt that doesn't work, but I'll have to think about how to implement that. -- John Baldwin