From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60838 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOp1k-0002eK-LM for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:35:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOp1j-0006os-DD for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:35:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23934) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOp1j-0006oh-5d for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:35:19 -0400 Date: Wed, 16 Jun 2010 12:35:16 +0300 From: Gleb Natapov Message-ID: <20100616093516.GD21797@redhat.com> References: <4C18015C.1070306@web.de> <20100616044047.GF13238@redhat.com> <4C187725.2000902@web.de> <20100616073318.GZ21797@redhat.com> <4C188272.9010201@web.de> <20100616075259.GA21797@redhat.com> <4C1883EF.10109@web.de> <20100616090658.GC21797@redhat.com> <4C189A59.3040300@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C189A59.3040300@web.de> Subject: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel 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 -- Gleb.