From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57474 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPAgM-0007Nk-Ox for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:42:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPAgL-0007lR-72 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:42:42 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:50268) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPAgK-0007l9-PE for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:42:41 -0400 Message-ID: <4C19DFFA.6000603@web.de> Date: Thu, 17 Jun 2010 10:42:34 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter References: <4C1883EF.10109@web.de> <20100616090658.GC21797@redhat.com> <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> In-Reply-To: <20100617083616.GL523@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD7B77ED6976E9F0682C80E5" 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) --------------enigBD7B77ED6976E9F0682C80E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 for >>> MMIO-based". >> Undefined IO ports return -1, undefined (/wrt read access) MMIO 0. So >> 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-pnp) device probing used to work this way. Can't tell for the other archs that support fw-cfg. >=20 >>> 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 th= at > always existed would do. Yes, read-back would mean returning FWCfgState::cur_entry. And that will be -1 when selected an invalid one. Jan --------------enigBD7B77ED6976E9F0682C80E5 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 iEYEARECAAYFAkwZ3/4ACgkQitSsb3rl5xSdvgCbBIAeuaFA4FU+fNCNs/laXZjM U88An2ZaLRE42lXoDWQNScPwC5sszZX1 =Zrs0 -----END PGP SIGNATURE----- --------------enigBD7B77ED6976E9F0682C80E5--