qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] pass info about hpets to seabios.


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
Date: Sun, 13 Jun 2010 19:41:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Gleb Natapov wrote:
> On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> Currently HPET ACPI table is created regardless of whether qemu actually
>>> created hpet device. This may confuse some guests that don't check that
>>> hpet is functional before using it. Solve this by passing info about
>>> hpets in qemu to seabios via fw config interface. Additional benefit is
>>> that seabios no longer uses hard coded hpet configuration. Proposed
>>> interface supports up to 256 hpets. This is the number defined by hpet 
>>> spec.
>> Nice, this lays the ground for adding hpets via -device.
>>
>> (But I think I read there can only be 8 hpets with a total sum of 256
>> timers.)
>>
> Ah, correct. I thought to myself 256 hpets should be to much :)
> 
>>> Signed-off-by: Gleb Natapov <address@hidden>
>>> diff --git a/hw/hpet.c b/hw/hpet.c
>>> index 93fc399..f2a4514 100644
>>> --- a/hw/hpet.c
>>> +++ b/hw/hpet.c
>>> @@ -73,6 +73,8 @@ typedef struct HPETState {
>>>      uint64_t hpet_counter;      /* main counter */
>>>  } HPETState;
>>>  
>>> +struct hpet_fw_config hpet_cfg = {.valid = 1};
>>> +
>>>  static uint32_t hpet_in_legacy_mode(HPETState *s)
>>>  {
>>>      return s->config & HPET_CFG_LEGACY;
>>> @@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
>>>           */
>>>          hpet_pit_enable();
>>>      }
>>> +    hpet_cfg.count = 1;
>>> +    hpet_cfg.hpet.event_timer_block_id = (uint32_t)s->capability;
>> The number of timers, thus the content of capability can change on
>> vmload. So you need to update hpet_cfg there as well.
>>
> How it can change? User is required to run the same command line on src
> and dst, no?

Generally, yes. But there is no technical need to match the hpet props
so far, they are included in the vmstate (implicitly).

> 
>> And I think we can move the capability setup into init. But this is not
>> directly related to this patch, would just avoid adding this hunk to
>> hpet_reset.
> I actually did that initially and tried to init hpet_cfg there too, but
> then noticed that mmio[0].addr below is not initialized at init time yet.

Indeed.

You may try sysbus_init_mmio_cb instead for a callback to be invoked
once the address was set. That handler could also be called on vmload.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]