Re: CVS commit: src/lib/libc/arch/powerpc/sys
On Feb 2, 2014, at 2:19 PM, David Holland wrote: > On Sat, Feb 01, 2014 at 08:26:21PM +, Matt Thomas wrote: >> Modified Files: >> src/lib/libc/arch/powerpc/sys: __syscall.S syscall.S >> >> Log Message: >> Since powerpc passes 8 arguments in registers and the syscall number in r0, >> shuffle register argument so the kernel won't need to access the stack to >> retrieve that last argument. >> >> +STRONG_ALIAS(syscall, __syscall) > > Shouldn't that be weak? it wasn't a weak symbol before.
Re: CVS commit: src/external/gpl3/gdb/dist/gdb
In article <20140202223912.gd16...@snowdrop.l8s.co.uk>, David Laight wrote: >On Sun, Feb 02, 2014 at 05:00:38PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun Feb 2 22:00:38 UTC 2014 >> >> Modified Files: >> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c >> >> Log Message: >> Fix threading bug again. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.6 -r1.7 src/external/gpl3/gdb/dist/gdb/inf-ptrace.c >@@ -374,7 +380,7 @@ > XXX __NetBSD__: We used to pass this as the signal > sig = ptid_get_lwp(ptid); >*/ >- ptrace (request, pid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal)); >+ ptrace (request, pid, (PTRACE_TYPE_ARG3)1, sig); > > >You probably want to kill the comment from the last merge. Right. christos
Re: CVS commit: src/lib/libc/arch/powerpc/sys
On Sat, Feb 01, 2014 at 08:26:21PM +, Matt Thomas wrote: > Modified Files: > src/lib/libc/arch/powerpc/sys: __syscall.S syscall.S > > Log Message: > Since powerpc passes 8 arguments in registers and the syscall number in r0, > shuffle register argument so the kernel won't need to access the stack to > retrieve that last argument. > > +STRONG_ALIAS(syscall, __syscall) Shouldn't that be weak? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/external/gpl3/gdb/dist/gdb
On Sun, Feb 02, 2014 at 05:00:38PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Feb 2 22:00:38 UTC 2014 > > Modified Files: > src/external/gpl3/gdb/dist/gdb: inf-ptrace.c > > Log Message: > Fix threading bug again. > > > To generate a diff of this commit: > cvs rdiff -u -r1.6 -r1.7 src/external/gpl3/gdb/dist/gdb/inf-ptrace.c @@ -374,7 +380,7 @@ XXX __NetBSD__: We used to pass this as the signal sig = ptid_get_lwp(ptid); */ - ptrace (request, pid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal)); + ptrace (request, pid, (PTRACE_TYPE_ARG3)1, sig); You probably want to kill the comment from the last merge. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/xen/xen
On Sun, Feb 02, 2014 at 08:24:08PM +, David Laight wrote: > On Sun, Feb 02, 2014 at 08:41:29PM +0100, Manuel Bouyer wrote: > > On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote: > > > Something needs to set the TS (task switched) flag when a new cpu > > > is added. Both amd64 and i386 'bare metal' have direct calls to > > > fpuinit() to do this. > > > > > > If TS isn't set the first FP process that gets migrated to that cpu > > > won't fault on its first FP instruction. If it has just forked it > > > probably won't care, but otherwise it will all go horribly wrong. > > > > This is the clts/stts macros/functions, isn't it ? > > For Xen, this is done with the HYPERVISOR_fpu_taskswitch() hypercall. > > Yes. > > > For the boot CPU it's done in i386_proc0_tss_ldt_init(). > > For other CPUs it will be done when a process is created/migrated > > to this CPU in i386_tls_switch(), because (l != ci->ci_fpcurlwp) > > will be true. > > Yes, probably true. > I'd assumed that the call to fpuinit() served a purpose. It probably does for native. For Xen things are done a bit differently. > > > > > > > It probably doesn't matter for the boot cpu - except that you > > > (effectively) > > > clone 'random' FP registers instead of known 'initially zero' ones. > > > > But these are zeroed on first call to the first npxdna() call, > > because the lwp won't have MDL_USEDFPU set at this time. > > fork() ought to replicate the FP registers of the parent. > I think it saves the fpu state, and then copies it. > On bare metal it could base that descision of the state of the TS flag > (I don't think it does). But for XEN the equivalent isn't readable. I wouldn't expect native or Xen to be different in this case. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/xen/xen
On Sun, Feb 02, 2014 at 08:41:29PM +0100, Manuel Bouyer wrote: > On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote: > > Something needs to set the TS (task switched) flag when a new cpu > > is added. Both amd64 and i386 'bare metal' have direct calls to > > fpuinit() to do this. > > > > If TS isn't set the first FP process that gets migrated to that cpu > > won't fault on its first FP instruction. If it has just forked it > > probably won't care, but otherwise it will all go horribly wrong. > > This is the clts/stts macros/functions, isn't it ? > For Xen, this is done with the HYPERVISOR_fpu_taskswitch() hypercall. Yes. > For the boot CPU it's done in i386_proc0_tss_ldt_init(). > For other CPUs it will be done when a process is created/migrated > to this CPU in i386_tls_switch(), because (l != ci->ci_fpcurlwp) > will be true. Yes, probably true. I'd assumed that the call to fpuinit() served a purpose. > > > > It probably doesn't matter for the boot cpu - except that you (effectively) > > clone 'random' FP registers instead of known 'initially zero' ones. > > But these are zeroed on first call to the first npxdna() call, > because the lwp won't have MDL_USEDFPU set at this time. fork() ought to replicate the FP registers of the parent. I think it saves the fpu state, and then copies it. On bare metal it could base that descision of the state of the TS flag (I don't think it does). But for XEN the equivalent isn't readable. I'm about to commit code that inverts the default and assumes that the fpu is present until fpuinit() detects it isn't. That way it matters much less if it isn't called. (No one runs 496SX) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/xen/xen
On Sun, Feb 02, 2014 at 06:53:55PM +, David Laight wrote: > > It's been a while since I looked at this and I don't remmeber the details, > > but I don't think anything of fpuinit() is neeed for Xen. in netbsd-6 > > npxattach() doens't do anything either for Xen (only set i386_fpu_present to > > 1 and init npxdna_func, which seems to be done at compile time now). > > I think the FPU is initialised by the hypervisor. Or it's done by > > npxdna() on the first FPU use. > > > > With the code as is in HEAD now, all FPU-related atf tests pass on > > a Xen guest with 4 CPUs, so I assume it's working as expected. > > Something needs to set the TS (task switched) flag when a new cpu > is added. Both amd64 and i386 'bare metal' have direct calls to > fpuinit() to do this. > > If TS isn't set the first FP process that gets migrated to that cpu > won't fault on its first FP instruction. If it has just forked it > probably won't care, but otherwise it will all go horribly wrong. This is the clts/stts macros/functions, isn't it ? For Xen, this is done with the HYPERVISOR_fpu_taskswitch() hypercall. For the boot CPU it's done in i386_proc0_tss_ldt_init(). For other CPUs it will be done when a process is created/migrated to this CPU in i386_tls_switch(), because (l != ci->ci_fpcurlwp) will be true. > > It probably doesn't matter for the boot cpu - except that you (effectively) > clone 'random' FP registers instead of known 'initially zero' ones. But these are zeroed on first call to the first npxdna() call, because the lwp won't have MDL_USEDFPU set at this time. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/xen/xen
On Sun, Feb 02, 2014 at 01:27:45PM +0100, Manuel Bouyer wrote: > On Sat, Feb 01, 2014 at 10:49:44PM +, 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. > > It isn't there on amd64, but really it does no harm. > > Without it one process will have an indererminate fp state. > > It's been a while since I looked at this and I don't remmeber the details, > but I don't think anything of fpuinit() is neeed for Xen. in netbsd-6 > npxattach() doens't do anything either for Xen (only set i386_fpu_present to > 1 and init npxdna_func, which seems to be done at compile time now). > I think the FPU is initialised by the hypervisor. Or it's done by > npxdna() on the first FPU use. > > With the code as is in HEAD now, all FPU-related atf tests pass on > a Xen guest with 4 CPUs, so I assume it's working as expected. Something needs to set the TS (task switched) flag when a new cpu is added. Both amd64 and i386 'bare metal' have direct calls to fpuinit() to do this. If TS isn't set the first FP process that gets migrated to that cpu won't fault on its first FP instruction. If it has just forked it probably won't care, but otherwise it will all go horribly wrong. It probably doesn't matter for the boot cpu - except that you (effectively) clone 'random' FP registers instead of known 'initially zero' ones. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/xen/xen
On Sat, Feb 01, 2014 at 10:49:44PM +, 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. > It isn't there on amd64, but really it does no harm. > Without it one process will have an indererminate fp state. It's been a while since I looked at this and I don't remmeber the details, but I don't think anything of fpuinit() is neeed for Xen. in netbsd-6 npxattach() doens't do anything either for Xen (only set i386_fpu_present to 1 and init npxdna_func, which seems to be done at compile time now). I think the FPU is initialised by the hypervisor. Or it's done by npxdna() on the first FPU use. With the code as is in HEAD now, all FPU-related atf tests pass on a Xen guest with 4 CPUs, so I assume it's working as expected. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/sys/arch/xen/xen
On Sat, Feb 01, 2014 at 06:09:04PM -0800, John Nemeth wrote: > } > } 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. Probably best to make fpuinit() xen-save then. David -- David Laight: da...@l8s.co.uk
