From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UJAoe-0003eL-NB for qemu-devel@nongnu.org; Fri, 22 Mar 2013 18:52:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UJAob-0002nK-RF for qemu-devel@nongnu.org; Fri, 22 Mar 2013 18:52:04 -0400 Date: Fri, 22 Mar 2013 17:51:46 -0500 From: Scott Wood In-Reply-To: <447D2065-E881-4936-867F-5F21D89EC141@suse.de> (from agraf@suse.de on Thu Mar 21 18:45:31 2013) Message-ID: <1363992706.24790.16@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC ppc-next PATCH 6/6] kvm/openpic: in-kernel mpic support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "" , "" On 03/21/2013 06:45:31 PM, Alexander Graf wrote: >=20 > On 21.03.2013, at 22:59, Scott Wood wrote: >=20 > > On 03/21/2013 04:29:02 PM, Alexander Graf wrote: > >> Am 21.03.2013 um 21:50 schrieb Scott Wood =20 > : > >> > On 03/21/2013 03:41:19 AM, Alexander Graf wrote: > >> >> Can't all the stuff above here just simply go into the qdev =20 > init function? > >> > > >> > Not if you want platform code to be able to fall back to a QEMU =20 > mpic if an in-kernel mpic is unavailable. > >> Do we want that? We used to have a default like that in qemu-kvm =20 > back in the day. That was very confusing, as people started to report =20 > that their VMs turned out to be really slow. > >> I think we should not have fallback code. It makes things easier =20 > and more obvious. The default should just depend on the host's =20 > capabilities. > > > > I don't follow. What is the difference between "falling back" and =20 > "depending on the host's capabilities"? Either we can create an =20 > in-kernel MPIC or we can't. We could use KVM_CREATE_DEVICE_TEST to =20 > see if the device type is supported separately from actually creating =20 > it, but I don't see what that would accomplish other than adding more =20 > code. > We usually have settled on a tri-state way to change QEMU behavior =20 > for most machine options: >=20 > -machine is not specified -> best possible behavior in the =20 > current system > -machine =3Don -> turn the option on, fail if that doesn't work > -machine =3Doff -> turn the option off always >=20 > So for the in-kernel irqchip, we should follow the same model. If the =20 > -machine option is not passed in, we should try to allocate an =20 > in-kernel irqchip if possible. That's fine, I just misunderstood what the semantics were supposed to =20 be. > If the kernel advertises that it can do an in-kernel irqchip, but in =20 > fact it can't, I would consider that simply a bug we shouldn't worry =20 > about. I'm not worried about it. I just don't see any benefit to deferring =20 the creation of the device at that point, and we can't do the test any =20 earlier because we won't know what type of irqchip to inquire about. > >> > That is exactly what I was trying to avoid by introducing =20 > kvm_irqchip_wanted. We're no longer testing some vague generic =20 > irqchip capability, but the presence of a specific type of device =20 > (and version thereof). How would the code that sets =20 > kvm_irqchip_wanted know what to test for? > >> Then move the default code into the board file and check for the =20 > in-kernel mpic cap. > > > > I'm not quite sure what you mean by "the default code" -- if you =20 > mean the part that makes the decision whether to fall back or error =20 > out, that's already in board code. >=20 > No, currently that lives mostly in kvm-all.c. By "currently" I mean in the current state of this patch, not how it's =20 currently done for x86. It's e500.c code that checks whether a "kvm =20 openpic" was created. If it wasn't -- due to the kernel not supporting =20 it, or due to the user not wanting it -- it creates a normal openpic =20 device. This would change to error out if a kvm mpic was explicitly requested =20 but unable to be created. > I'm talking about the code that checks =20 > qemu_opt_get_bool("kernel_irqchip") and decides what to do based on =20 > that. The only thing that it "decides what to do" for MPIC is record the =20 preference for board code's consumption, and I agreed that there's no =20 point leaving that there if it's more complicated than a simple bool. -Scott=