Re: kern/39114: sys/arch/x86/x86/patch.c needs a minor #ifdef for PARALLELS (VT extensions problem)

[Jason Thorpe <thorpej%shagadelic.org@localhost>]

On Jul 8, 2008, at 3:40 AM, Jared D. McNeill wrote:

> The following reply was made to PR kern/39114; it has been noted by  
> GNATS.
>
> From: "Jared D. McNeill" <jmcneill%invisible.ca@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
> netbsd-bugs%netbsd.org@localhost
> Subject: Re: kern/39114: sys/arch/x86/x86/patch.c needs a minor  
> #ifdef for
> PARALLELS (VT extensions problem)
> Date: Tue, 08 Jul 2008 02:35:44 -0400
>
> ggm%pobox.com@localhost wrote:
> > > Number:         39114
> > > Category:       kern
> > > Synopsis:       sys/arch/x86/x86/patch.c needs a minor #ifdef for  
> > > PARALLELS (VT extensions problem)
> > > Confidential:   no
> > > Severity:       non-critical
> > > Priority:       low
> > > Responsible:    kern-bug-people
> > > State:          open
> > > Class:          sw-bug
> > > Submitter-Id:   net
> > > Arrival-Date:   Tue Jul 08 02:05:00 +0000 2008
> > > Originator:     George Michaelson
> > > Release:        current
> > > Organization:
> > > Environment:
> > NetBSD snoid 4.99.69 NetBSD 4.99.69 (GENERIC) #3: Mon Jul  7  
> > 20:34:51 EST 2008  ggm@snoid:/usr/obj/sys/arch/i386/compile/GENERIC  
> > i386
> > > Description:
> > Parallels on Mac has support for 'VT extensions' but when they hit  
> > a NetBSD current kernel, some code in patch.c causes a hang during  
> > boot.
> >
> > You can disable the VT extensions, but thats a PITA. There is an  
> > existing #if !defined(GPROF) on the code which causes the problem,  
> > but having to enable GPROF to get a working kernel also has  
> > downsides.
> >
> > If this patch is acceptable, or something close to it, then a  
> > single new Option/define in any kernel Makefile which sets - 
> > DPARALLELS will fix the problem.
>
> Hi George --
>
> Newer Parallels versions should give reasonable data in DMI tables.  
> Can
> you look into modifying your patch to automatically detect and disable
> this section of code based on that information rather than adding
> another compile-time option? See the pmf(4) man page for information  
> on
> retrieving DMI information from the driver.

I'd say it's flat-out wrong to make this change at all, unless you're  
specifically testing for buggy versions of Parallels when you apply  
the work-around.

This issue needs to be reported to Parallels so that they can fix it.   
The work-around can lead to a significant performance penalty.


> Cheers,
> Jared

-- thorpej