Re: [Xen-devel] [PATCH] new hvm platform vhpet enable parameter

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

It enables it by default if the tools do not explicitly instruct either way.
In practice the tools will always explicitly instruct Xen for any new guest,
since xm picks default == 0. But it is important for old saved guest images
which will have no value for 'hpet': in this case we *must* enable the hpet
by default as the guest has probably already probed it.

I'm a bit undecided whether the tools should pick default of on or off. I
guess the default doesn't matter all that much, and it's better off by
default if it's not working that well.

I can easily add a similar switch for pmtimer.

 -- Keir

On 14/2/08 18:18, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 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@xxxxxxxxxxxx]
>> Sent: Thursday, February 14, 2008 10:52 AM
>> To: dan.magenheimer@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
>> 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"
>> <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxx]
>>>> Sent: Thursday, February 07, 2008 1:54 PM
>>>> To: 'Keir Fraser'; 'xen-devel@xxxxxxxxxxxxxxxxxxx'
>>>> 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
>>>> 
>>> 
>> 
>> 
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel