From: Andre Przywara <andre.przywara@arm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH kvmtool 6/6] arm: Auto-detect guest GIC type
Date: Thu, 31 Jan 2019 18:46:45 +0000 [thread overview]
Message-ID: <20190131184645.23381476@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <20190130182046.GI18558@fuggles.cambridge.arm.com>
On Wed, 30 Jan 2019 18:20:46 +0000
Will Deacon <will.deacon@arm.com> wrote:
> 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?
When we introduced the GICv3 emulation and the kvmtool support,
it was deemed less mature than the GICv2 support. This was one of the
reasons we were happy with GICv2-on-v3 as the default. Now with GICv3
support being stable, we should use the advantages like the system
register interface.
> > - 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
I think v2m will fail only rarely (doesn't rely on any kernel
support), so in practise we will likely never get a "pure" GICv2. But
since we always have the --irqchip option to override this, that's
probably OK.
Will change it to that effect.
Cheers,
Andre.
next prev parent reply other threads:[~2019-01-31 18:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-25 18:07 [PATCH kvmtool 0/6] Various convenience fixes Andre Przywara
2019-01-25 18:07 ` [PATCH kvmtool 1/6] arm: turn pr_info() into pr_debug() messages Andre Przywara
2019-01-25 18:07 ` [PATCH kvmtool 2/6] arm: fdt: add stdout-path to /chosen node Andre Przywara
2019-01-30 18:20 ` Will Deacon
2019-01-31 14:57 ` Andre Przywara
2019-02-01 6:26 ` Will Deacon
2019-02-01 11:03 ` Andre Przywara
2019-01-25 18:07 ` [PATCH kvmtool 3/6] Makefile: support -s switch Andre Przywara
2019-01-30 18:20 ` Will Deacon
2019-01-31 13:48 ` Andre Przywara
2019-01-25 18:07 ` [PATCH kvmtool 4/6] Makefile: Remove echoing of kvmtools version file Andre Przywara
2019-01-30 18:20 ` Will Deacon
2019-01-31 18:36 ` Andre Przywara
2019-01-25 18:08 ` [PATCH kvmtool 5/6] arm: pmu: Improve PMU error reporting Andre Przywara
2019-01-25 18:08 ` [PATCH kvmtool 6/6] arm: Auto-detect guest GIC type Andre Przywara
2019-01-30 18:20 ` Will Deacon
2019-01-31 18:46 ` Andre Przywara [this message]
2019-01-30 18:20 ` [PATCH kvmtool 0/6] Various convenience fixes Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190131184645.23381476@donnerap.cambridge.arm.com \
--to=andre.przywara@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox