From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] new hvm platform vhpet enable parameter Date: Thu, 14 Feb 2008 11:18:49 -0700 Message-ID: <20080214111849125.00000001516@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Thanks, sorry I missed it. Glad I didn't have to deal with that ACPI asl stuff! What a mess! A question: You added a snippet in arch/x86/hvm/hvm.c that sets the HPET_ENABLED parameter on. I don't have a machine running xen-unstable at the moment so I can't verify, but this appears to be turning the virtual hpet on by default. Was this intended? > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Thursday, February 14, 2008 10:52 AM > To: dan.magenheimer@oracle.com; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH] new hvm platform vhpet = > enable parameter > = > = > It has been taken. Xen-unstable:17017. > = > -- Keir > = > = > On 14/2/08 16:52, "Dan Magenheimer" = > wrote: > = > > I see this patch hasn't been taken yet. Is there something > > else I need to do or are you not in agreement that the > > acpi part is cosmetic? > > > > Thanks, > > Dan > > > >> -----Original Message----- > >> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com] > >> Sent: Thursday, February 07, 2008 1:54 PM > >> To: 'Keir Fraser'; 'xen-devel@lists.xensource.com' > >> Subject: RE: [Xen-devel] [PATCH] new hvm platform vhpet > >> enable parameter > >> > >> > >>> Yes, tools/firmware/hvmloader/acpi/dsdt.asl. The right way to > >>> do this will > >>> be to gate it on a flag set up in memory by hvmloader (we > >>> already do this > >>> e.g., for com1 and com2 -- see construct_bios_info_table() in > >>> build.c in the > >>> same directory). That might be a bit tricky as it probably > >>> needs a bit of > >>> ASL hacking, which has a little learning curve. I can take a > >>> look maybe next > >>> week. > >> > >> OK, here's the updated patch: > >> 1) hpet instead of vhpet > >> 2) against 3.2-testing tip > >> > >> This will work without the acpi changes so could be checked in > >> independently. Though it may be a bit misleading for the > >> guest to print out that it found an hpet in acpi and then > >> be unable to use it, the acpi part is largely cosmetic > >> and (as you point out) a bit tricky so better left for > >> your capable hands. > >> > >> Thanks, > >> Dan > >> > > > = > = >