[Simh] cpu idle with NetBSD
Mark Pizzolato - Info Comm
Mark at infocomm.com
Tue Apr 10 20:30:58 EDT 2012
Hi Chris,
There were issues like this on prior versions of simh. (V3.8-1 and earlier), which you are running.
The latest (about to be released) version is v3.9-0-rc2 which has significant improvements to the idle implementation, including a solution to the issue you found. My earlier comments were specifically referring to that new idle implementation for the VAX.
The release candidate which is close to release is available at https://github.com/markpizz/simh/zipball/v3.9-0-rc1
Save what that URL returns as a zip file and unpack it and build a vax simulator with networking support using:
unzip -a zipfilename.zip
cd markpizz*
make vax
The key issue with recent versions of NetBSD is that earlier versions of the OS had the vax specific idle routine within an assembler module called subr.S . The simh idle logic detects the code which is implemented for idle in subr.S. Meanwhie, newer versions of NetBSD don't carry this assembler code anymore and a much more complicated sequence of things going on, essentially all from compiled modules (from a little examination of the code I've done). The structure of the idle management has been adjusted to accommodate the features we have on modern system... (Everything Multi-Core, HyperThreading, etc.) with some low level tasks delegated to the idle loop as well (page zeroing). There is one platform specific callout to "cpu_idle(). cpu_idle() is defined in usr/src/sys/arch/vax/include/cpu.h. It is defined to be a macro: "#define cpu_idle() do {} while (/*CONSCOND*/0)" A normal compiler wouldn't generate any code for this macro. If the macro instead was defined to be "#define cpu_idle() do {splx(splx(7))} while (/*CONSCOND*/0)"
I have sent a message to the NetBSD vax mailing list with the above suggested change to the base source code. Maybe it will get adopted. OpenBSD has similar, but different code but I'll make the same suggestion there as well. Maybe this will end up built into these OS builds....
I come back to the question of why folks would want to run the new version of NetBSD on a simulated VAX when they can run a native one for their host platform which will be the same OS and be more naturally behaved. If the point is merely to test to see if the OS still works, that's great, but then you boot it test a few things and then turn it off. Great idle support isn't needed since it won't be running continuously.
- Mark
From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Christopher Redmon
Sent: Monday, April 09, 2012 4:15 PM
To: simh at trailing-edge.com
Subject: Re: [Simh] cpu idle with NetBSD
I am seeing some issues with cpu idling on NetBSD 5.1.2 amd64 platform as well.
It doesn't appear to be the guest OS, but the idle loop calibration in simh itself.
When setting the "set cpu idle" command, it returns idle not supported. After
probing some into the code, it appears the sim_os_ms_sleep_init, non posix
source version is being used, and it is calculating a time greater than
SIM_IDLE_MAX.
% uname -a NetBSD fx 5.1.2 NetBSD 5.1.2 (GENERIC) #0: Thu Feb 2 12:12:28 UTC 2012 builds at b7.netbsd.org:/home/builds/ab/netbsd-5-1-2-RELEASE/amd64/201202021012Z-obj/home/builds/ab/netbsd-5-1-2-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64
% simh-pdp11
PDP-11 simulator V3.8-1
sim> set cpu idle
Command not allowed
sim>
Chris
On Mon, Apr 9, 2012 at 3:02 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com<mailto:Mark at infocomm.com>> wrote:
On Monday, April 09, 2012 at 10:44 AM, Arpadffy Zoltan wrote:
> Hello Mark,
>
> Thank you for the detailed description.
>
> Running x86/amd64 version of NetBSD is not an option in my case (in fact I do
> already) because the only way of the lifting forward the vax architecture
> specific development is to run NetBSD on vax.
The existing issue (with detecting idle), exists due to some of the prior 'lifting' efforts which changed how the VAX specific code was doing things while idle.
> Definitely, the right way to go is to find that specific reasonable set of
> conditions which uniquely describe the guest NetBSD idling under simh.
> I'll do my best.
If you're actually influencing the content of the VAX specific code for NetBSD, then you could probably create a specific signature.... For example, there probably is a relatively low IPL which is not used by NetBSD. Let's say that is IPL4. You could have a routine:
Vax_idle()
{
Int oldipl = getipl();
Setipl(unused_ipl);
Setipl(oldipl);
}
The mere use of the setipl to the known to be unused IPL would be a sufficient condition which you could add in the code and could then be detected in the simulator, but would still run fine on real hardware as well.
- Mark
> ________________________________________
> From: Mark Pizzolato - Info Comm [Mark at infocomm.com<mailto:Mark at infocomm.com>]
> Sent: Monday, April 09, 2012 6:12 PM
> To: Arpadffy Zoltan; simh at trailing-edge.com<mailto:simh at trailing-edge.com>
> Subject: RE: cpu idle with NetBSD
>
> On Sunday, April 08, 2012 at 9:00 AM, Arpadffy Zoltan wrote:
> > Hello,
> >
> > I have recently installed a NetBSD version 5.1.2 and realized that it
> > takes 100% of the CPU.
> >
> > I have tried with
> > set cpu idle=NETBSD
> >
> > as well as with the
> > set cpu idle=ALL
> >
> > ...without any success.
> > Could anybody help me; what I am doing wrong?
>
> Hi Zoltan,
>
> The only thing you are doing wrong is trying to run a recent version of
> NetBSD on a VAX. Why are you doing that? Why not run an x86/x64 the
> recent version of NetBSD under VirtualBox or other x86 hypervisor?
>
> The challenge for idle detection for any particular operating system is to
> determine a set of conditions which uniquely exist only when the OS is in the
> idle state. For example, for older VMS Versions, the Idle loop was:
>
> $1: br{b,w} $1 ; While the CPU was at IPL 0.
>
> More recent VMS Versions have an idle loop which does a BBS instruction at
> IPL 3 on the interrupt stack, with the BBS branch taken. This is the only case
> where the BBS instruction is used at IPL 3 on the interrupt stack in VMS, so
> that condition causes simh to idle.
> Older versions of Ultrix, as well as the older versions of OpenBSD, NetBSD,
> and FreeBSD have a common idle detection condition which is common due
> to the fact that they all have common BSD roots. The condition which
> describes the OS idle here is a TSTL instruction which is running at IPL 0 from a
> low addresses in system space (8000000-80003FFF) which is a 6 byte TSTL
> instruction. Later versions of Ultrix had different conditions (BITL instruction,
> 8 bytes long, running on interrupt stack, at IPL 24, in system space between
> 8000000-80005ffff).
> These conditions uniquely describe the respective guest OS idling state.
> They have been determined by a combination of examining the instructions
> which are executing when the OS isn't doing anything useful (leveraging the
> simh VAX set cpu history command), and then verified by looking at the OS
> source for the relevant code.
> This was easy enough to do with the older 'legacy' (non changing) guest
> OSes. Meanwhile, the *BSD OSes are a moving target since they're still being
> developed. They have each diverged in different ways from their older BSD
> roots and due to their idling redesigns to work better on newer hardware
> (Multi-Core and power efficient). I was unable to detect a useful pattern
> which uniquely described the guest OS idle condition in the current VAX
> code.
>
> My recommendation to run the x86/amd64 version of NetBSD comes down
> to the fact that the x86 platform specific parts of NetBSD will try to put the
> CPU into a low power state when the NetBSD OS is idling. Taking this
> approach will also get you a much quicker NetBSD OS environment since the
> x86 instructions will be running mostly directly by the host processor instead
> of having the simh simulation overhead.
>
> Alternative, Feel free to see if you can come up with a reasonable set of
> conditions which uniquely describe the guest NetBSD idling under simh. If
> you do we'll consider adding it to the VAX idling conditions.
>
> Good Luck,
>
> - Mark
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
> http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120410/86dbbf62/attachment-0002.html>
More information about the Simh
mailing list