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

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> It enables it by default if the tools do not explicitly 
> instruct either way.... for old saved guest images...

OK, I see.  I'm glad you caught that.

But does that mean if a guest config file does not explicitly
have a "hpet = 0" line, the default will be on?  If so,
that's different from how I intended.  Perhaps the
code in XendDomainInfo _constructDomain should be modified
to set it to zero if "hpet is None"?  Else, I'll bet
guests created by virt-install will end up with hpet on.

Also it occurs to me it might be a good idea to add a
gdprintk in hvm.c so that whether the hpet is on or not
is visibly logged.

> I can easily add a similar switch for pmtimer.

Yes, from Dave Winchell's post today on another thread, it appears
that there are definitely some Linux versions that will default
to the pmtimer, which currently is not working well either.

I'm happy to submit a patch for pmtimer, but since you are probably
going to have to do the heavy lifting on the acpi asl stuff
anyway, you may as well.  But if you'd rather I give it a try,
let me know.

Thanks,
Dan

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: Thursday, February 14, 2008 12:26 PM
> To: dan.magenheimer@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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