From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: HPET configuration in Seabios
Date: Mon, 29 Aug 2011 13:12:26 +0200
Message-ID: <4E5B741A.3090501@siemens.com>
References: <4B17C12B.4020300@linux.vnet.ibm.com> <4B17CC5F.20101@redhat.com>
	<CA+tHM2HH437Y4KLmGO+59wvR-TMSacGnxgt5QB8w5LDtJ+p3Xw@mail.gmail.com>
	<4E59F15E.6000201@redhat.com>
	<F2AA4282-91FD-493A-9337-AB4922C2925A@suse.de>
	<4E5AA849.5090400@web.de> <20110828221437.GA27777@morn.localdomain>
	<4E5B2450.3050209@redhat.com> <4E5B691C.9050507@siemens.com>
	<4E5B7168.5070306@redhat.com> <4E5B7262.4010902@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Andrew Theurer <habanero@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	seabios <seabios@seabios.org>, ya su <suya94335@gmail.com>,
	Alexander Graf <agraf@suse.de>, QEMU Developers <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>
To: Avi Kivity <avi@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <4E5B7262.4010902@siemens.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: </archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On 2011-08-29 13:05, Jan Kiszka wrote:
> On 2011-08-29 13:00, Avi Kivity wrote:
>> On 08/29/2011 01:25 PM, Jan Kiszka wrote:
>>>>
>>>>  Can't seabios just poke at the hpet itself and see if it exists or not?
>>>>
>>>
>>> Would be hard for the BIOS to guess the locations of the blocks unless
>>> we define the addresses used by QEMU as something like base + hpet_no *
>>> block_size in all cases.
>>>
>>
>> Currently we have a fixed address.  We could do:
>>
>>   if available in fw_cfg:
>>       use that (may indicate no hpet)
>>   elif fixed address works:
>>       use that
>>   else
>>       no hpet
> 
> Currently, we also only have a single HPET block, but that's just
> because of some QEMU limitations that will vanish sooner or later. Then
> nothing will prevent multiple "-device hpet,base=XXX".

That said, some HPET probing (without any fw_cfg) may be a short-term
workaround to fix Seabios until we defined The solution for
communicating HPET block configurations.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux