Gleb Natapov wrote: > 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 <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? >>>> >>> 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".
Undefined IO ports return -1, undefined (/wrt read access) MMIO 0. So
you need to select a key that is different from both.
> Can you write pseudo logic of how you think it
> all should work?
The firmware should do this:
write(CTL_BASE, FW_CFG_ID);
if (read(CTL_BASE) != FW_CFG_ID)
deal_with_old_qemu();
else
check_for_supported_keys();
Jan
signature.asc
Description: OpenPGP digital signature
