[Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter

[Gleb Natapov <gleb@redhat.com>]

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 <jan.kiszka@siemens.com>
> >>>>>>
> >>>>>> 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?

--
			Gleb.