From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments Date: Mon, 10 Jan 2011 21:15:06 +0100 Message-ID: <4D2B68CA.3060503@web.de> References: <4D2616D6.4080309@linux.vnet.ibm.com> <4D26D6CF.5070405@web.de> <4D27A16F.9030809@linux.vnet.ibm.com> <4D282489.90506@web.de> <4D2B67F6.5030909@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig69FE03A3A9FCC6FF2F66A96A" Cc: Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, Alexander Graf To: Anthony Liguori Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:44644 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752061Ab1AJUPI (ORCPT ); Mon, 10 Jan 2011 15:15:08 -0500 In-Reply-To: <4D2B67F6.5030909@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig69FE03A3A9FCC6FF2F66A96A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 10.01.2011 21:11, Anthony Liguori wrote: > On 01/08/2011 02:47 AM, Jan Kiszka wrote: >> OK, but I don't want to argue about the ioeventfd API. So let's put th= is >> case aside. :) >> =20 >=20 > I often reply too quickly without explaining myself. Let me use > ioeventfd as an example to highlight why KVMState is a good thing. >=20 > In real life, PIO and MMIO are never directly communicated to the devic= e > from the processor. Instead, they go through a series of other > devices. In the case of something like an ISA device, a PIO first goes= > to the chipset into the PCI complex, it will then go through a > PCI-to-ISA bridge via subtractive decoding, and then forward over the > ISA device where it will be interpreted by some device. >=20 > The path to the chipset may be shared among different processors but it= > may also be unique. The APIC is the best example as there are historic= > APICs that hung directly off of the CPUs such that the same MMIO access= > across different CPUs did not go to the same device. This is why the > APIC emulation in QEMU is so weird because we don't model this behavior= > correctly. >=20 > This means that a PIO operation needs to flow from a CPUState to a > DeviceState. It can then flow through to another DeviceState until it'= s > finally handled. >=20 > The first problem with ioeventfd is that it's a per-VM operation. It > should be per VCPU. >=20 > But even if this were the case, the path that a PIO operation takes > should not be impacted by ioeventfd. IOW, a device shouldn't be > allocating an eventfd() and handing it to a magical KVM call. Instead,= > a device should register a callback for a particular port in the same > way it always does. *As an optimization*, we should have another > interface that says that these values are only valid for this IO port. = > That would let us create eventfds and register things behind the scenes= =2E >=20 > That means we can handle TCG, older KVM kernels, and newer KVM kernels > without any special support in the device model. It also means that th= e > device models never have to worry about KVMState because there's an > entirely different piece of code that's consulting the set of special > ports and then deciding how to handle it. The result is better, more > portable code that doesn't have KVM-isms. >=20 > If passing state around seems to be ugly, it's probably because we're > not abstracting things correctly. Removing the state and making it > implicit is the wrong solution. Fixing the abstraction is the right > solution (or living with the ugliness until someone else is motivated t= o > fix it properly). Look at my other reply, it should answer this. ioeventfd is the wrong example IMHO as one may argue about its relation to VCPUS. Jan --------------enig69FE03A3A9FCC6FF2F66A96A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0raMoACgkQitSsb3rl5xTXCgCfYQ9STHAKHCTZuzfR9O42yyvH UaIAn0O7C1LlYIJJOZnhs/pMnEjuL6nA =qqNm -----END PGP SIGNATURE----- --------------enig69FE03A3A9FCC6FF2F66A96A--