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 bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
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 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
On Feb 1, 2014, at 2:16 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp 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=value which is ignored. CRUNCHGEN_FLAGS is unobvious.
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
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=value 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
