From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 5/5] HPET interaction with in-kernel PIT (v6) Date: Sun, 14 Jun 2009 11:26:57 +0200 Message-ID: <4A34C261.5000908@web.de> References: <1244771206-19872-1-git-send-email-eak@us.ibm.com> <1244771206-19872-5-git-send-email-eak@us.ibm.com> <4A34BA88.7060204@redhat.com> <4A34BE92.6010302@web.de> <4A34C060.8000100@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D8F3E50817A9F003945992B" Cc: Beth Kon , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:32811 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753783AbZFNJ1K (ORCPT ); Sun, 14 Jun 2009 05:27:10 -0400 In-Reply-To: <4A34C060.8000100@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D8F3E50817A9F003945992B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >>>> =20 >>>> struct kvm_pit_state { >>>> struct kvm_pit_channel_state channels[3]; >>>> + u8 hpet_legacy_mode; >>>> }; >>>> =20 >>> This changes the ABI, breaking older binaries running on newer kernel= s, >>> or newer binaries running on older kernels. >>> =20 >> >> As we have KVM_CREATE_PIT2 now, which includes struct kvm_pit_config >> with a lot of unused flags, it should be straightforward to negotiate >> the kvm_pit_state format between kernel and user space: kernel >> advertises support for the new one via capability, user space requests= >> it via a bit in kvm_pit_state.flags. >> =20 >=20 > We still need a new ioctl. The structure size is embedded in the ioctl= > number, so any additions automatically cause version mismatches. >=20 > I sent patches some time ago to have the kernel automatically adjust fo= r > this, but they weren't well received. Unfortunate. But on the one hand, nothing technically prevents defining the IOCTL base on existing kvm_pit_state, but passing down extended kvm_pit_state2 if that negotiation took place. On the other hand, we are not yet running out of IOCTL numbers... However, I guess kvm_pit_state2 will also need some flags field and a bit tail room for potential future extensions. Jan --------------enig0D8F3E50817A9F003945992B 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko0wmwACgkQniDOoMHTA+n6sgCcDdL/ieSR3sQI90q0nXycVXuL /u8An3Dbt2lOhY5Y2Gb9Hjzkc3FyIWU9 =jEk5 -----END PGP SIGNATURE----- --------------enig0D8F3E50817A9F003945992B--