From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTJtf-0001o4-VV for qemu-devel@nongnu.org; Tue, 21 Jul 2009 14:17:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTJta-0001nb-Ed for qemu-devel@nongnu.org; Tue, 21 Jul 2009 14:17:02 -0400 Received: from [199.232.76.173] (port=48725 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTJta-0001nY-9x for qemu-devel@nongnu.org; Tue, 21 Jul 2009 14:16:58 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:47763) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTJtZ-0001OD-TQ for qemu-devel@nongnu.org; Tue, 21 Jul 2009 14:16:58 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6LI9cVE011066 for ; Tue, 21 Jul 2009 14:09:38 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6LIGm89227114 for ; Tue, 21 Jul 2009 14:16:48 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6LIGmMu021739 for ; Tue, 21 Jul 2009 14:16:48 -0400 Message-ID: <4A660611.6040801@us.ibm.com> Date: Tue, 21 Jul 2009 14:16:49 -0400 From: Beth Kon MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: hpet emulation problems References: <4A65B4BD.5040601@icyb.net.ua> <4A65BA5A.5000608@icyb.net.ua> In-Reply-To: <4A65BA5A.5000608@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andriy Gapon Cc: qemu-devel@nongnu.org Andriy Gapon wrote: > 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. > Thanks for catching these bugs! I'll submit corrections shortly. As far as supporting level-triggered interrupts, all the guests I tested used edge-triggered interrupts, so this is what I implemented as a first pass. I don't think there is any reason not to implement level-triggered, though I am not planning to work on that at this point.