From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQcaT-0002nL-TL for qemu-devel@nongnu.org; Tue, 02 Feb 2016 10:09:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQcaQ-0000ac-IH for qemu-devel@nongnu.org; Tue, 02 Feb 2016 10:09:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQcaQ-0000aX-Ab for qemu-devel@nongnu.org; Tue, 02 Feb 2016 10:09:46 -0500 Message-ID: <1454425781.7688.7.camel@redhat.com> From: Andrea Bolognani Date: Tue, 02 Feb 2016 16:09:41 +0100 In-Reply-To: <20160202125926.GE3688@hawk.localdomain> References: <20160105134720.GA2393@cbox> <1452016711.16471.6.camel@redhat.com> <1452018414.16471.8.camel@redhat.com> <20160106113402.GA13870@cbox> <1452084567.4759.6.camel@redhat.com> <20160122144432.GJ14825@redhat.com> <20160202114933.GA11792@cbox> <20160202121010.GH18461@redhat.com> <20160202125926.GE3688@hawk.localdomain> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [libvirt] ARM KVM GICv3 Support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones , "Daniel P. Berrange" Cc: Peter Maydell , Eric Auger , Libvirt , Andre Przywara , qemu-devel@nongnu.org, Marc Zyngier , Christoffer Dall On Tue, 2016-02-02 at 13:59 +0100, Andrew Jones wrote: > > > > Our introspection support in QOM only allows us to say that a property > > > > is a particular type (int / enum / str / whatever). We don't have= any > > > > way to expose info about what subset of possible values for a type are > > > > permitted. So I don't see any near term way to inform apps that the > > > > gic property accepts values x, y and but not z. >=C2=A0 > This actually doesn't matter for the v2 vs. v3 case. The gic-version property > doesn't exist at all for v2-only QEMU. Although maybe the gic-version p= roperty > should be reworked. Instead of gic-version=3D, we could create > one boolean property per version supported, i.e. gicv2, gicv3, gicv4... Hold on, so "gic-version=3D3" means "support all GIC versions up to 3", not "support GIC version 3 only"? I thought the latter. > > >=C2=A0=C2=A0=C2=A02) Just implement something in libvirt that checks= what the kernel > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0supports directly via the well-d= efined KVM interface and chooses > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the highest supported version pe= r default. [...] > I'm not familiar enough with libvirt, nor the use of QMP, to really arg= ue > one way or another, but I find it a bit strange that we'd prefer libvir= t > to query two entities over one. And, why should the libvirt installed o= n > a particular host prefer gicv3 as the default, just because KVM support= s > it, even when QEMU does not? The default will fail every time until QEM= U > is upgraded, which may not be necessary/desired. Shouldn't the default be "host", to mean "whatever the host supports", rather than a specific version based either on host or QEMU probing? That should work for every QEMU version, right? > Finally, I thought we > were trying to get away from relying on QEMU's error messages to make a= ny > sort of decisions. We wouldn't be looking at the error message and base our decision on that, we would just display it to the user if QEMU fails to run. That already happens for a bunch of other situations, so I don't think it's really a problem, especially because libvirt can't possibly be expected to catch every possible QEMU failure and sugar-coat it before reporting it to the user. > I don't know what else libvirt queries directly from KVM, but IMO, it > should be a long-term goal to stop doing it, not add to more. Besides > libvirt then properly selecting defaults that both KVM and QEMU support= , > it would allow /dev/kvm to have QEMU-only selinux labels applied. One thing that comes to mind is the number of threads per subcores on ppc64 hosts, and I don't think that's the kind of information QEMU would provide via QMP. In the short term we definitely need libvirt to be able to pass "gic-version=3Dhost" to QEMU, and I'm working on a patch that enables that feature. As I've already voiced in this thread, my feeling is that the probing should happen in one place only (QEMU) and libvirt should merely query that information and report it back to the user, to avoid any possible disagreement. On the other hand, Dan has plenty more experience and also knowledge that spans the whole stack, so in general I trust his opinion :) One other way to handle this would be to simply report the GIC versions *libvirt* supports, and let the user pick either the default ("host", which should work anywhere) or a specific version, which might or might not actually be accepted by QEMU. I think there are other places in libvirt where this approach is used, even though is probably not the most user friendly... Cheers. --=C2=A0 Andrea Bolognani Software Engineer - Virtualization Team