[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.