Re: CVS commit: src/distrib/common
matt@ wrote:
> > matt@ wrote:
> >
> >> Module Name: src
> >> Committed By: matt
> >> Date: Sat Feb 1 21:05:54 UTC 2014
> >>
> >> Modified Files:
> >>src/distrib/common: Makefile.crunch
> >>
> >> Log Message:
> >> Pass DBG to crunchgen so it can get into the created mk file.
> >
> > I think it should be set by each Makefile via CRUNCHGEN_FLAGS
> > (several mips ports already have it), not in the common Makefile.
>
> Most ramdisk Makefiles have a DBG= which is ignored.
> CRUNCHGEN_FLAGS is unobvious.
Most, but not all.
The point is that your changes disallow each Makefile overwriting
default settings. At least it should be set via
CRUNCHGEN_FLAGS?= -d "${DBG}"
in the common Makefile.crunch.
Or properly remove all redundant CRUNCHGEN_FLAGS which specify -d
from existing Makefiles if you really don't like it.
---
Izumi Tsutsui
Re: CVS commit: src/sys/arch/xen/xen
On Feb 1, 10:49pm, David Laight wrote: } On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote: } > Module Name:src } > Committed By: bouyer } > Date: Sat Feb 1 20:07:07 UTC 2014 } > } > Modified Files: } > src/sys/arch/xen/xen: hypervisor.c } > } > Log Message: } > Revert previous: calling fpuinit() leads to a panic, as a domU is not } > allowed to manipulate cr0 directly. Xen doesn't need this, the fpu is } > handled by the hypervisor. } } I probably remember seeing that panic as well. } } XEN might need the bits of fpuinit() that don't play with cr0. } In particular a fninit and setting TS. } Although I'm not 100% sure the TS is needed on a single cpu system. Xen domU is SMP capable. NetBSD dom0 currently aren't, but hopefully it is in the works. } It isn't there on amd64, but really it does no harm. } Without it one process will have an indererminate fp state. } } I can't say I've actuallly looked a xen. } Presumably we somewhere compile the hypervisor as part of a kernel? The hypervisor comes from the Xen Project. See pkgsrc/sysutils/xenkernel* . }-- End of excerpt from David Laight
Re: CVS commit: src/sys/arch/xen/xen
On 2/1/14, 2:49 PM, David Laight wrote: On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote: I can't say I've actuallly looked a xen. Presumably we somewhere compile the hypervisor as part of a kernel? The hypervisor is in pkgsrc - sysutils/xenkernel42 (and the accompanying xentools42). It's not NetBSD-based. +j
Re: CVS commit: src/distrib/common
On Feb 1, 2014, at 2:16 PM, Izumi Tsutsui wrote: > matt@ wrote: > >> Module Name: src >> Committed By:matt >> Date:Sat Feb 1 21:05:54 UTC 2014 >> >> Modified Files: >> src/distrib/common: Makefile.crunch >> >> Log Message: >> Pass DBG to crunchgen so it can get into the created mk file. > > I think it should be set by each Makefile via CRUNCHGEN_FLAGS > (several mips ports already have it), not in the common Makefile. Most ramdisk Makefiles have a DBG= which is ignored. CRUNCHGEN_FLAGS is unobvious.
Re: CVS commit: src/sys/arch/xen/xen
On Sat, Feb 01, 2014 at 08:07:07PM +, Manuel Bouyer wrote: > Module Name: src > Committed By: bouyer > Date: Sat Feb 1 20:07:07 UTC 2014 > > Modified Files: > src/sys/arch/xen/xen: hypervisor.c > > Log Message: > Revert previous: calling fpuinit() leads to a panic, as a domU is not > allowed to manipulate cr0 directly. Xen doesn't need this, the fpu is > handled by the hypervisor. I probably remember seeing that panic as well. XEN might need the bits of fpuinit() that don't play with cr0. In particular a fninit and setting TS. Although I'm not 100% sure the TS is needed on a single cpu system. It isn't there on amd64, but really it does no harm. Without it one process will have an indererminate fp state. I can't say I've actuallly looked a xen. Presumably we somewhere compile the hypervisor as part of a kernel? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/distrib/common
matt@ wrote: > Module Name: src > Committed By: matt > Date: Sat Feb 1 21:05:54 UTC 2014 > > Modified Files: > src/distrib/common: Makefile.crunch > > Log Message: > Pass DBG to crunchgen so it can get into the created mk file. I think it should be set by each Makefile via CRUNCHGEN_FLAGS (several mips ports already have it), not in the common Makefile. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/xen/xen
On Sat, Feb 01, 2014 at 05:48:04PM +, David Laight wrote: > Module Name: src > Committed By: dsl > Date: Sat Feb 1 17:48:04 UTC 2014 > > Modified Files: > src/sys/arch/xen/xen: hypervisor.c > > Log Message: > Add a direct call to fpuinit(). > I'm not sure this is architecturally the best place, but I think it > is where npxattach() used to get called. > Might fix FP support in domu Actually this broke it: xencons0 at hypervisor0: Xen Virtual Console Driver panic: XXX lcr0 not supported fpuinit() should *not* be called for Xen (and it was not before). This is handled by the hypervisor. I didn't notice i386_fpu_present was set to 1 in fpuinit() (I don't know how I missed it), so setting i386_fpu_present to 1 unconditionally for Xen is probably the right thing to do. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
