From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36177 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPAwJ-0004yG-4X for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:59:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPAwI-0002ac-0T for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:59:10 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:42109) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPAwH-0002a1-Lu for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:59:09 -0400 Message-ID: <4C19E3D5.9030406@web.de> Date: Thu, 17 Jun 2010 10:59:01 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter References: <4C189A59.3040300@web.de> <20100616093516.GD21797@redhat.com> <20100616153607.GG523@redhat.com> <4C18F538.1090709@web.de> <20100617054857.GH523@redhat.com> <4C19CC1F.9040209@web.de> <20100617080758.GK523@redhat.com> <4C19DD17.3000408@web.de> <20100617083616.GL523@redhat.com> <4C19DFFA.6000603@web.de> <20100617084639.GA31985@redhat.com> In-Reply-To: <20100617084639.GA31985@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD864EFBD6BC941DE0C76ABD5" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD864EFBD6BC941DE0C76ABD5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Thu, Jun 17, 2010 at 10:42:34AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Thu, Jun 17, 2010 at 10:30:15AM +0200, Jan Kiszka wrote: >>>>> Sorry, I lost you here. What "works for IO-based fw-cfg, but not fo= r >>>>> MMIO-based". >>>> Undefined IO ports return -1, undefined (/wrt read access) MMIO 0. S= o >>>> you need to select a key that is different from both. >>>> >>> But can we rely on it? Is this defined somewhere or if it happens to = be >>> the case in current qemu for x86 arch. >> For x86 with its port-based access, we are on the safe side as (pre-pn= p) >> device probing used to work this way. Can't tell for the other archs >> that support fw-cfg. >> >>>>> Can you write pseudo logic of how you think it >>>>> all should work? >>>> The firmware should do this: >>>> >>>> write(CTL_BASE, FW_CFG_ID); >>>> if (read(CTL_BASE) !=3D FW_CFG_ID) >>>> deal_with_old_qemu(); >>>> else >>>> check_for_supported_keys(); >>>> >>> Ah, I thought about read() returning 0/1, not key itself, so any key = that >>> always existed would do. >> Yes, read-back would mean returning FWCfgState::cur_entry. And that wi= ll >> be -1 when selected an invalid one. >> > Heh, actually I have better idea. Why not advance FW_CFG_ID to version = 2. If that is supposed to be a version number - yeah, good idea. Jan --------------enigD864EFBD6BC941DE0C76ABD5 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 iEYEARECAAYFAkwZ49gACgkQitSsb3rl5xS51ACgm+9bUM2ue3wLY5IFkc2/t2pV hK8An192IAOxuf5rEnKB2U2BuI0s0BNx =87hX -----END PGP SIGNATURE----- --------------enigD864EFBD6BC941DE0C76ABD5--