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 <jan.kis...@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? >>> 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? Jan
signature.asc
Description: OpenPGP digital signature
