From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50946 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOuex-0000CM-Ch for qemu-devel@nongnu.org; Wed, 16 Jun 2010 11:36:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOuev-0002SJ-Pe for qemu-devel@nongnu.org; Wed, 16 Jun 2010 11:36:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62268) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOuev-0002SB-HA for qemu-devel@nongnu.org; Wed, 16 Jun 2010 11:36:09 -0400 Date: Wed, 16 Jun 2010 18:36:07 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter Message-ID: <20100616153607.GG523@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> <20100616093516.GD21797@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100616093516.GD21797@redhat.com> 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 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? ;) -- Gleb.