From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MTEqz-0002H4-Nj
	for qemu-devel@nongnu.org; Tue, 21 Jul 2009 08:53:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MTEqv-0002GS-3q
	for qemu-devel@nongnu.org; Tue, 21 Jul 2009 08:53:57 -0400
Received: from [199.232.76.173] (port=49630 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MTEqu-0002GP-Tq
	for qemu-devel@nongnu.org; Tue, 21 Jul 2009 08:53:52 -0400
Received: from citadel.icyb.net.ua ([212.40.38.140]:2232)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avg@icyb.net.ua>) id 1MTEqt-0004wN-7o
	for qemu-devel@nongnu.org; Tue, 21 Jul 2009 08:53:52 -0400
Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua
	[212.40.38.101])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA21163
	for <qemu-devel@nongnu.org>; Tue, 21 Jul 2009 15:53:47 +0300 (EEST)
	(envelope-from avg@icyb.net.ua)
Message-ID: <4A65BA5A.5000608@icyb.net.ua>
Date: Tue, 21 Jul 2009 15:53:46 +0300
From: Andriy Gapon <avg@icyb.net.ua>
MIME-Version: 1.0
References: <4A65B4BD.5040601@icyb.net.ua>
In-Reply-To: <4A65B4BD.5040601@icyb.net.ua>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: hpet emulation problems
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org


I obtained qemu code and looked through hw/hpet.c, below are some observations.


on 21/07/2009 15:29 Andriy Gapon said the following:
> I observe the following problems with qemu-emulated HPET:
> 
> 1. setting lower 32bits of a 64-bit register clears the higher 32 bits;
> At least this happens with TIMn_CONF register - I set some bits at offset 0x100
> and all bits at 0x104 become cleared. The problem is aggravated by the fact that
> those bits are supposed to be RO - they specify interrupt routing capabilities.

This probably happens because of the following.
New value is set using a filter function, e.g.:
timer->config = hpet_fixup_reg(new_val, old_val,
                               HPET_TN_CFG_WRITE_MASK);
But old_val was set to:
old_val = hpet_ram_readl(opaque, addr);

Apparently hpet_ram_readl returns value in the lower 32 bits and thus higher 32
bits are lost.
timer->config is a 64-bit variable that is supposed to hold all bits of TIMn_CONF
(judging from hpet_ram_readl).

> 2. Setting interrupt type to level-triggered has no effect in the sense that
> interrupt status bits are not set in GINTR_STA when interrupts are generated.

>>From the code I see that level-triggered interrupts are not supposed to be
supported at all:
if (new_val & HPET_TIMER_TYPE_LEVEL) {
    printf("qemu: level-triggered hpet not supported\n");
    exit (-1);
}

The code is quite harsh in calling exit(), but it is incorrect too.
This how HPET_TIMER_TYPE_LEVEL is defined:
#define HPET_TIMER_TYPE_LEVEL 1
#define HPET_TIMER_TYPE_EDGE 0

But Interrupt Type is bit #1 in TIMn_CONF, bit #0 is reserved and is typically
zero. The check should be:
if (new_val & (HPET_TIMER_TYPE_LEVEL << 1))
or something like that.

But maybe level-triggered HPET interrupts could be supported after all.

-- 
Andriy Gapon