| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home