Greg Troxel | 1 Dec 2005 17:30
Picon

ok to remove DDB_ONPANIC=1 from XEN{0,U}?

After splitting GENERIC.local/INSTALL.local, I'm going over my configs
and putting what I want (IPSEC, stf(4)) in GENERIC.local.   I found
that I also had disabled DDB_ONPANIC, and think this doesn't belong in
XEN's GENERIC equivalent since it is unsuitable for production.  Any
objections to committing the following?

Index: XEN0
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/conf/XEN0,v
retrieving revision 1.22
diff -u -r1.22 XEN0
--- XEN0	25 Nov 2005 16:41:31 -0000	1.22
+++ XEN0	1 Dec 2005 16:28:06 -0000
 <at>  <at>  -56,7 +56,7  <at>  <at> 
 options 	DEBUG		# expensive debugging checks/support 
 options 	KMEMSTATS	# kernel memory statistics (vmstat -m)
 options 	DDB		# in-kernel debugger
-options 	DDB_ONPANIC=1	# see also sysctl(8): `ddb.onpanic'
+#options 	DDB_ONPANIC=1	# see also sysctl(8): `ddb.onpanic'
 options 	DDB_HISTORY_SIZE=512	# enable history editing in DDB
 #options 	KGDB		# remote debugger
 #options 	KGDB_DEVNAME="\"com\"",KGDB_DEVADDR=0x2f8,KGDB_DEVRATE=57600
Index: XENU
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/conf/XENU,v
retrieving revision 1.13
diff -u -r1.13 XENU
--- XENU	25 Nov 2005 16:41:31 -0000	1.13
+++ XENU	1 Dec 2005 16:28:06 -0000
 <at>  <at>  -53,7 +53,7  <at>  <at> 
(Continue reading)

Jonathan A. Kollasch | 1 Dec 2005 18:41
Gravatar

Re: ok to remove DDB_ONPANIC=1 from XEN{0,U}?

On Thu, Dec 01, 2005 at 11:30:28AM -0500, Greg Troxel wrote:
> After splitting GENERIC.local/INSTALL.local, I'm going over my configs
> and putting what I want (IPSEC, stf(4)) in GENERIC.local.   I found
> that I also had disabled DDB_ONPANIC, and think this doesn't belong in
> XEN's GENERIC equivalent since it is unsuitable for production.  Any
> objections to committing the following?

While it may be unsuitable for production, there is precedence for
having DDB_ONPANIC set in GENERIC. All archs I know about (alpha, i386,
macppc) have it set by default. Not having it set makes postmortem
debugging nearly impossible. IMHO this should be unset by sysctl after
boot if desired.

	Jonathan Kollasch
Greg Troxel | 1 Dec 2005 19:15
Picon

Re: ok to remove DDB_ONPANIC=1 from XEN{0,U}?

"Jonathan A. Kollasch" <jakllsch <at> kollasch.net> writes:

> On Thu, Dec 01, 2005 at 11:30:28AM -0500, Greg Troxel wrote to port-xen:
> > After splitting GENERIC.local/INSTALL.local, I'm going over my configs
> > and putting what I want (IPSEC, stf(4)) in GENERIC.local.   I found
> > that I also had disabled DDB_ONPANIC, and think this doesn't belong in
> > XEN's GENERIC equivalent since it is unsuitable for production.  Any
> > objections to committing the following?
> 
> While it may be unsuitable for production, there is precedence for
> having DDB_ONPANIC set in GENERIC. All archs I know about (alpha, i386,
> macppc) have it set by default. Not having it set makes postmortem
> debugging nearly impossible. IMHO this should be unset by sysctl after
> boot if desired.

Thanks for pointing that out - I was confused.  Having "options DDB"
leads to ddb-on-panic unless one has

  options	DDB_ONPANIC=0

because src/sys/ddb/ddb_variables.c has

/*
 * If this is non-zero, the DDB will be entered when the system
 * panics.  Initialize it so that it's patchable.
 */
#ifndef DDB_ONPANIC
#define DDB_ONPANIC	1
#endif
int		db_onpanic = DDB_ONPANIC;
(Continue reading)

John R. Shannon | 1 Dec 2005 20:45
Favicon

Shared Crypto Device

Is it possible to share a crypto accelerator such as ubsec amoung domainU's? 
If so, how is this specified?

--

-- 
John R. Shannon, CISSP
Sr. Software Scientist
Science Applications International Corporation
john.r.shannon <at> saic.com
john.r.shannon <at> us.army.mil
john <at> johnrshannon.com

Jason Thorpe | 1 Dec 2005 21:50

Re: Shared Crypto Device


On Dec 1, 2005, at 11:45 AM, John R. Shannon wrote:

> Is it possible to share a crypto accelerator such as ubsec amoung  
> domainU's?
> If so, how is this specified?

I don't think there's a way to do that.  Perhaps its time to extend  
Xen to give it an OpenCrypto virtual device and a xencrypt driver for  
client OSs.

-- thorpej

Manuel Bouyer | 1 Dec 2005 21:33

Re: Shared Crypto Device

On Thu, Dec 01, 2005 at 12:45:49PM -0700, John R. Shannon wrote:
> Is it possible to share a crypto accelerator such as ubsec amoung domainU's? 
> If so, how is this specified?

No, I don't think it is possible. The dom0 should have the device and
provide a service to domU though the hypervisor, but as far as I know
there's no interface defined for this.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--

Hernani Marques Madeira | 1 Dec 2005 23:26

Using XEN0-kernel with acpi/cardbus support

Hello.

There was already a similar post:
http://mail-index.netbsd.org/port-xen/2005/05/09/0000.html

However, I don't want to export acpi/cardbus devices to any guest
system, I only want to use them for domain0; isn't that possible?

--

-- 
hernani

John R. Shannon | 2 Dec 2005 20:21
Favicon

Entropy Source

What device should I use for an entropy source?

postfix/smtp[2523]: warning: no entropy for TLS key generation: 
disabling TLS support

--

-- 
John R. Shannon, CISSP
Sr. Software Scientist
Science Applications International Corporation
john <at> johnrshannon.com
john.r.shannon <at> us.army.mil
john.r.shannon <at> saic.com
shannonjr <at> NetBSD.org

Juan RP | 2 Dec 2005 20:34

Re: Entropy Source

On Fri, 02 Dec 2005 12:21:15 -0700
"John R. Shannon" <john <at> johnrshannon.com> wrote:

> What device should I use for an entropy source?
> 
> postfix/smtp[2523]: warning: no entropy for TLS key generation: 
> disabling TLS support

I think it's /dev/urandom.

Thor Lancelot Simon | 2 Dec 2005 20:46

Re: Entropy Source

On Fri, Dec 02, 2005 at 12:21:15PM -0700, John R. Shannon wrote:
> What device should I use for an entropy source?

Did you build a kernel without pseudo-device random?  Don't do that.  We
should probably make it impossible to do that.  It breaks many much less
obvious things.

We should find a way to have domain 0 hand the client domains a chunk of
entropy at startup time.

Thor


Gmane