From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH kvmtool 6/6] arm: Auto-detect guest GIC type Date: Wed, 30 Jan 2019 18:20:46 +0000 Message-ID: <20190130182046.GI18558@fuggles.cambridge.arm.com> References: <20190125180801.209910-1-andre.przywara@arm.com> <20190125180801.209910-7-andre.przywara@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org To: Andre Przywara Return-path: Content-Disposition: inline In-Reply-To: <20190125180801.209910-7-andre.przywara@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org On Fri, Jan 25, 2019 at 06:08:01PM +0000, Andre Przywara wrote: > At the moment kvmtool always tries to instantiate a virtual GICv2 for > the guest, and fails with some scary error message if that doesn't work. > The user has then to manually specify "--irqchip=gicv3", which is not > really obvious. > With the advent of more GICv3-only machines, let's try to be more > clever and implement some auto-detection of the GIC type needed: > - We try GICv3 first. On GICv3-only hosts this will be the only working > option, so we don't loose anything. On GICv2-backwards compatible GICv3 > machines GICv3 is probably the better choice these days. Could you elaborate on "probably the better choice" please? > - If that fails, we try GICv2. > - If that fails, we ran out out options and bail out. > > We deduce the choice between "ITS vs. pure GICv3" and "GICv2m vs. GICv2" by > the presence of PCI devices, they would be the only MSI users anyway. This feels really flakey. Why don't we just try, in order: v3 + ITS v3 v2m v2 regardless of the VM configuration? Will