From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45610 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPA8q-00006u-8W for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:08:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPA8n-0007Tw-RF for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:08:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31796) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPA8n-0007TL-KZ for qemu-devel@nongnu.org; Thu, 17 Jun 2010 04:08:01 -0400 Date: Thu, 17 Jun 2010 11:07:58 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter Message-ID: <20100617080758.GK523@redhat.com> References: <4C188272.9010201@web.de> <20100616075259.GA21797@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C19CC1F.9040209@web.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On Thu, Jun 17, 2010 at 09:17:51AM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Jun 16, 2010 at 06:00:56PM +0200, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Wed, Jun 16, 2010 at 12:35:16PM +0300, Gleb Natapov wrote: > >>>> On Wed, Jun 16, 2010 at 11:33:13AM +0200, Jan Kiszka wrote: > >>>>> Gleb Natapov wrote: > >>>>>> On Wed, Jun 16, 2010 at 09:57:35AM +0200, Jan Kiszka wrote: > >>>>>>> Gleb Natapov wrote: > >>>>>>>> On Wed, Jun 16, 2010 at 09:51:14AM +0200, Jan Kiszka wrote: > >>>>>>>>> Gleb Natapov wrote: > >>>>>>>>>> On Wed, Jun 16, 2010 at 09:03:01AM +0200, Jan Kiszka wrote: > >>>>>>>>>>> Gleb Natapov wrote: > >>>>>>>>>>>> On Wed, Jun 16, 2010 at 12:40:28AM +0200, Jan Kiszka wrote: > >>>>>>>>>>>>> From: Jan Kiszka > >>>>>>>>>>>>> > >>>>>>>>>>>>> There is no need starting with the special value for hpet_cfg.count. > >>>>>>>>>>>>> Either Seabios is aware of the new firmware interface and properly > >>>>>>>>>>>>> interprets the counter or it simply ignores it anyway. > >>>>>>>>>>>>> > >>>>>>>>>>>> I want seabios to be able to distinguish between old qemu and new one. > >>>>>>>>>>> I see now. But isn't it a good chance to introduce a proper generic > >>>>>>>>>>> interface for exploring supported fw-cfg keys? > >>>>>>>>>>> > >>>>>>>>>> Having such interface would be nice. Pity we haven't introduced it from > >>>>>>>>>> the start. If we do it now seabios will have to find out somehow that > >>>>>>>>>> qemu support such interface. Chicken and egg ;) > >>>>>>>>> That is easy: Add a key the describes the highest supported key value > >>>>>>>>> (looks like this is monotonously increasing). Older qemu versions will > >>>>>>>>> return 0. > >>>>>>>>> > >>>>>>>> That will not support holes in key space, and our key space is already > >>>>>>>> sparse. > >>>>>>> Then add a service to obtain a bitmap of supported keys. If that bitmap > >>>>>>> is empty... > >>>>>>> > >>>>>> Bitmap will be 2k long. We can add read capability to control port. To > >>>>>> check if key is present you select it (write its value to control port) > >>>>>> and then read control port back. If values is non-zero the key is valid. > >>>>>> But how to detect qemu that does not support that? > >>>>> Isn't there some key that was always there and will always be? > >>>>> > >>>> FW_CFG_SIGNATURE > >>>> > >>> So any ideas? Or did I misunderstood your hint? ;) > >> I thought you found the answer yourself: > >> > >> Seabios could select FW_CFG_SIGNATURE and then perform a read-back on > >> the control register. Older QEMUs will return -1, versions that support > >> the read-back 0. Problem solved, no? > >> > > AFAIK QEMU returns 0 if io read was done from non-used port or mmio > > address, but can we rely on this? If we can then problem solved, if > > we can't then no. > > It works for IO-based fw-cfg, but not for MMIO-based. So the firmware > should probably pick a non-zero key for this check, e.g. FW_CFG_ID. > Sorry, I lost you here. What "works for IO-based fw-cfg, but not for MMIO-based". Can you write pseudo logic of how you think it all should work? -- Gleb.