Minimum x86_64 needed for VMS 9.X?

[John E. Malmberg]

Is there a test that we can do from Linux or Windows to tell us if our
existing hardware is good enough to run the future VMS 9.x community
licensed edition?

Most of my x86_64 systems are several years old.

Just because a system can run VirtualBox or KVM may not be the minimum
needed for VMS 9.x.

VirtualBox and KVM can pass through CPU features to their guests, but
may not be able to emulate CPU features that are not present on the
native hardware that may be needed by the guest operating system.

So looking ahead to see if I will need to get newer hardware and what
the minimum hardware I would need to run the future VMS 9.X community
licensed edition for building GNV in a VM.

Regards,
-John

[Robert A. Brooks]

On 5/21/2020 9:27 AM, John E. Malmberg wrote:
> Is there a test that we can do from Linux or Windows to tell us if
> our existing hardware is good enough to run the future VMS 9.x
> community licensed edition?

The Proliant Gen 9 and Gen 10 are the supported systems.

I don't have the detail about what CPU features are specifically required.

--

-- Rob

[Stephen Hoffman]

Can't you see

This is a land of confusion

Now this is the world we live in

And these are the CPUs we're given

Yes, for now, these three or five or whatever server models, and this
and that VM and version, will suffice. But the permutations here are
going to explode... Quickly.

Various of the Intel Gen 10 CPUs are seemingly re-named Gen 9 CPUs
internally, and I doubt that the Intel and the server vendor naming
confusion will recede by the time we OpenVMS folks are all faced with
Intel-Gen-whatever and HPE-ProLiant-whatever is concurrently available
with VSI OpenVMS x86-64 V9.2 and subsequent releases.

This likely best leads to a VSI QUALIFY-like tool, akin to the old
VAX-11/782 workload-testing tool. Is this server even going to work,
or is it missing (for instance) PCID support, or some other giblet?
Basically, the same checks that the OpenVMS bootstrap itself will
probably necessarily be performing, though pulled out into a
separately-accessible component.


ps and entirely FWIW: for those considering or using Oracle VirtualBox,
be aware of the Oracle Extension Pack licensing details if you choose
to install those: https://www.virtualbox.org/wiki/Licensing_FAQ



--
Pure Personal Opinion | HoffmanLabs LLC

[Bob Gezelter]

Hoff,

I second your motion concerning QUALIFY. A quick image which verifies CPU viability would be useful. A signed binary for Windows and for Linux would work nicely to allow a quick check that a CPU is not disqualified.

- Bob Gezelter, http://www.rlgsc.com

[Jan-Erik Söderholm]

I'm sure I have misunderstood something, but I thought that if OpenVMS runs
on VirtualBox, it will run on anything where VirtualBox runs.

But then, if Win10 on my laptop reports "Intel Core i7-6500U CPU", how
do I know if it is a Gen9/Gen10 CPU or not?

[Arne Vajhøj]

On 5/21/2020 6:19 PM, Jan-Erik Söderholm wrote:
> Den 2020-05-21 kl. 20:59, skrev Bob Gezelter:
>> On Thursday, May 21, 2020 at 1:01:03 PM UTC-4, Stephen Hoffman wrote:
>>> On 2020-05-21 14:58:51 +0000, Robert A. Brooks said:
>>>> On 5/21/2020 9:27 AM, John E. Malmberg wrote:
>>>>> Is there a test that we can do from Linux or Windows to tell us if
>>>>> our existing hardware is good enough to run the future VMS 9.x
>>>>> community licensed edition?
>>>>
>>>> The Proliant Gen 9 and Gen 10 are the supported systems.
>>>>
>>>> I don't have the detail about what CPU features are specifically
>>>> required.

>>> This is a land of confusion
>>>
>>> Now this is the world we live in
>>>
>>> And these are the CPUs we're given
>>>
>>> Yes, for now, these three or five or whatever server models, and this
>>> and that VM and version, will suffice. But the permutations here are
>>> going to explode... Quickly.
>>>
>>> Various of the Intel Gen 10 CPUs are seemingly re-named Gen 9 CPUs
>>> internally, and I doubt that the Intel and the server vendor naming
>>> confusion will recede by the time we OpenVMS folks are all faced with
>>> Intel-Gen-whatever and HPE-ProLiant-whatever is concurrently available
>>> with VSI OpenVMS x86-64 V9.2 and subsequent releases.

I think this is adding to the confusion.

Are there any relation between Proliant Gen X and Intel Core Xth Gen??

> I'm sure I have misunderstood something, but I thought that if OpenVMS runs
> on VirtualBox, it will run on anything where VirtualBox runs.
>
> But then, if Win10 on my laptop reports "Intel Core i7-6500U CPU", how
> do I know if it is a Gen9/Gen10 CPU or not?

It is 6th Gen per
https://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors

But I don't think that matters.

Arne

[Jan-Erik Söderholm]

"Don't think that matters", does that imply that, even if Gen9/10 is
the needed(/supported for "bare metal" VMS, if you run in VisualBox
you can run on anything that VisualBox runs on?

[Arne Vajhøj]

> "Don't think that matters", does that imply that, even if Gen9/10 is
> the needed(/supported for "bare metal" VMS, if you run in VisualBox
> you can run on anything that VisualBox runs on?

What VMS will run on in VirtualBox is a question for VSI. Brooks
already said that he did not have a list of required CPU features.

What I am saying is that I don't think the fact that VSI is
certifying VMS for HPE Proliant Gen9 and Gen10 servers has
any importance for whether a desktop PC or laptop running
Intel Core 6th or 9th or 10th gen will work.

Arne

[Michael Moroney]

> On 5/21/2020 9:27 AM, John E. Malmberg wrote:

> Is there a test that we can do from Linux or Windows to tell us if
> our existing hardware is good enough to run the future VMS 9.x
> community licensed edition?

Supported or "works"?

Rob answered "supported", at least current plans.

As to "works" it will boot (on Virtualbox) on certain older
hardware, at least for now.

VMS needs certain x86-64 instructions and features.

I have an older Dell laptop running Windoze 7 and Virtualbox.
I sometimes load x86 VMS on it although I usually use a Mac.
I don't know what "gen" it is but it is Intel Core i5-2410M.
VMS complains upon boot that "ASNs aren't supported, performance
may suffer" but runs. Another ancient Windows 7 system wouldn't
boot, when I asked one of the early boot guys he said that was
expected, it didn't have a required instruction (forget which).

I don't know if VMs or directly on the hardware matters.

[John H. Reinhardt]

I think people should note that the "Gen 9" and "Gen 10" Robert mentions are generations of the HPE Proliant server, not necessarily generations of the Intel processor within.

--
John H. Reinhardt

[Robert A. Brooks]

Thanks for pointing that out; I thought that was understood.

As long as the hypervisor presents a virtualized CPU that has the minimum
required support for VMS, it'll work.

Yeah, that's vague, but I'm not working in that space, so I have not paid
attention to the details.

--
-- Rob

[VAXman-]

Can I purchase one of those without the Billy-tax?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Andrew Commons]

One would hope that it is not dependent on esoteric instructions. If it is going to succeed it needs to be able to run on hardware that is in place today and not get derailed by hardware deployed in the future.

[John H. Reinhardt]

On 5/21/2020 6:45 PM, VAX...@SendSpamHere.ORG wrote:
> In article <ra64vj$dt9$1...@dont-email.me>, "Robert A. Brooks" <FIRST...@vmssoftware.com> writes:
>> On 5/21/2020 9:27 AM, John E. Malmberg wrote:
>>> Is there a test that we can do from Linux or Windows to tell us if
>>> our existing hardware is good enough to run the future VMS 9.x
>>> community licensed edition?
>>
>> The Proliant Gen 9 and Gen 10 are the supported systems.
>>
>> I don't have the detail about what CPU features are specifically required.
>
> Can I purchase one of those without the Billy-tax?
>

If you're comfortable working with Ebay vendors there is a plethora of HP Proliant kit available that will work with Linux, VMware ESXI, KVM, OracleBox and never a cent will head to Redmond.

The Gen 9 is EOL at HP fairly recently, so prices are still all over the place, from the $2000 to lower. The Gen 10 is current so finding low cost units for sale is harder.

Here's the most recent Gen 9 Quickspec from HP for a DL360 which is a 1U x86-64 server. <https://h20195.www2.hpe.com/v2/getdocument.aspx?docname=c04375623#>

This is the Quickspecs for a Gen9 Proliant DL380. A 2U server, the main board is basically the same as the DL360, just in ah thicker chassis that can hold more PCIe cards and may be a tad quieter since the airflow is though a thicker box and not quite as rushed as in a 1U DL360.
<https://h20195.www2.hpe.com/v2/getdocument.aspx?docname=c04346247#>


Here is an example of a decent server currently available. It's got one 6-core CPU, 16GB memory which is enough to run a couple OpenVMS virtual machines along with a stripped down Linux with VirtualBox. <https://www.ebay.com/itm/HPE-ProLiant-DL360-Gen9-G9-6C-E5-2620v3-2-4GHz-16GB-Server-780018-S01/233340757832>
The vendor has a 100% reputation which is good. The memory is 2 8GB sticks which means that there are slots open if you want to add more in the future. It has another CPU slot in case you want another 6-cores for a total of 12. No disks so you will need to find a couple HP SFF (small form factor - i.e. 2.5") SATA or SAS drives.

This one seems to be priced below market ($493.20 +$50 shipping) so they may have gotten a deal on some used items. <https://www.ebay.com/itm/HPE-ProLiant-DL360-Gen9-G9-6C-E5-2620v3-2-4GHz-16GB-Server-780018-S01/233340757832?>

A DL380 is pricier ($813.81), but here's one with 4x146GB drives, 16GB memory and the same 6-core CPU <https://www.ebay.com/itm/HP-DL380-G9-6-Core-Server-1x-E5-2620-v3-2-4GHz-16GB-16-4x-146GB-15K-SAS-H240ar/202960938030>

--
John H. Reinhardt

[Dave Froble]

I know nothing about VMs, but, my understanding is that they do not
emulate CPUs, thus code is running on the CPU, if through the VM. If
so, then if some instruction is required, a CPU that provides that
instruction would logically be required, right?

Another thought has occurred to me. What kind of tangled web exists for
those charging for licenses based on core count? A VM might be able to
provide a single core to an instance, but, the chip might have more cores.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Dave Froble]

I'd opt for a SATA SSD. Or 2 and mirror (RAID1) them.

> This one seems to be priced below market ($493.20 +$50 shipping) so they
> may have gotten a deal on some used items.
> <https://www.ebay.com/itm/HPE-ProLiant-DL360-Gen9-G9-6C-E5-2620v3-2-4GHz-16GB-Server-780018-S01/233340757832?>
>
>
> A DL380 is pricier ($813.81), but here's one with 4x146GB drives, 16GB
> memory and the same 6-core CPU
> <https://www.ebay.com/itm/HP-DL380-G9-6-Core-Server-1x-E5-2620-v3-2-4GHz-16GB-16-4x-146GB-15K-SAS-H240ar/202960938030>
>
>

John, got to wonder, would a developer need anything that expensive, or
capable?

[John H. Reinhardt]

Dave, probably not. Unless, perhaps they had multiple clients and wanted a separate environment to have for each client or a group of clients. Depending on your needs you might even be able to get along with a small laptop. For example, Clair Grant mentioned running OpenVMS x86 on his MacBook Pro with Virtual Box. And Michael Moroney elsewhere in this thread said he sometimes uses an older Dell laptop with Windows 7 and VirtualBox. You could easily load a version of Linux instead and with VirtualBox have an OpenVMS x86 capable machine probably at least as fast an Alpha DS10 or XP1000 (just guessing).

The systems I mentioned would probably be overkill for anyone not running a multi user production or development system. But, given the cheap pricing on Ebay might still be cheaper than buying a laptop or current PC.

--
John H. Reinhardt

[Arne Vajhøj]

On 5/21/2020 11:20 PM, Dave Froble wrote:
> On 5/21/2020 7:11 PM, Michael Moroney wrote:
>>> On 5/21/2020 9:27 AM, John E. Malmberg wrote:
>>> Is there a test that we can do from Linux or Windows to tell us if
>>> our existing hardware is good enough to run the future VMS 9.x
>>> community licensed edition?
>>
>> Supported or "works"?
>>
>> Rob answered "supported", at least current plans.
>>
>> As to "works" it will boot (on Virtualbox) on certain older
>> hardware, at least for now.
>>
>> VMS needs certain x86-64 instructions and features.
>>
>> I have an older Dell laptop running Windoze 7 and Virtualbox.
>> I sometimes load x86 VMS on it although I usually use a Mac.
>> I don't know what "gen" it is but it is Intel Core i5-2410M.
>> VMS complains upon boot that "ASNs aren't supported, performance
>> may suffer" but runs.  Another ancient Windows 7 system wouldn't
>> boot, when I asked one of the early boot guys he said that was
>> expected, it didn't have a required instruction (forget which).
>>
>> I don't know if VMs or directly on the hardware matters.
>
> I know nothing about VMs, but, my understanding is that they do not
> emulate CPUs, thus code is running on the CPU, if through the VM.  If
> so, then if some instruction is required, a CPU that provides that
> instruction would logically be required, right?

I think that is correct.

Similar to a program requiring EV56 will not run on an EV4.

But I doubt that it will be a problem.

It seems none of the VSI people here are aware of the
specific requirements. That likely means that VMS has run on any
HW they have tried on. If it was 1 out of 4 PC's that it worked on
then they would know.

Arne

[Arne Vajhøj]

On 5/21/2020 11:20 PM, Dave Froble wrote:

> Another thought has occurred to me.  What kind of tangled web exists for
> those charging for licenses based on core count?  A VM might be able to
> provide a single core to an instance, but, the chip might have more cores.

Licenses is a jungle.

Some license per system defined as OS instance - VM or physical.

Some license per core in system running software - cores allocated to VM
if VM or just cores if physical.

Oracle license per core in physical box (unless their own virtualization
software).

Arne

[Simon Clubley]

On 2020-05-21, Andrew Commons <andrew....@bigpond.com> wrote:
>
> One would hope that it is not dependent on esoteric instructions. If it is going to succeed it needs to be able to run on hardware that is in place today and not get derailed by hardware deployed in the future.

VMS is going to need PCID support for best performance, however VSI do
have a fallback for when the underlying processor does not support that.

What no-one is saying so far (and I hope that doesn't mean it's really
bad news) is how much of a performance hit VMS takes when PCID support
is not available.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[erga...@gmail.com]

On Friday, 22 May 2020 04:20:58 UTC+1, Dave Froble wrote:

> I know nothing about VMs, but, my understanding is that they do not
> emulate CPUs, thus code is running on the CPU, if through the VM. If
> so, then if some instruction is required, a CPU that provides that
> instruction would logically be required, right?

That's one part of it yes. However, for development purposes one would
probably drop back quite a way, and only later worry too much about
"/arch=<whatever>". These could be handled the same way as with Alpha,
at the price of some complexity byt having multiple shared images and
execlets.

The other part is the support for things like hardware support for
virtualization which are a it more under the hood. Some of them
may be deal brealers, other might mean a performance hit.

There isn't a lot of sense in setting minimums for performance related
stuff, or building multiple versions until one has had a chance to
performance measure optimized versions, and that will be some way
down the line.

[Robert A. Brooks]

On 5/22/2020 8:37 AM, Simon Clubley wrote:

> What no-one is saying so far (and I hope that doesn't mean it's really
> bad news) is how much of a performance hit VMS takes when PCID support
> is not available.

We have no clue about performance. The compilers are quite raw, and no
optimization is being attempted. We just want stuff to work, and will worry about
optimization when we have native compilers.

John will weigh in if I've misstated something.

--

-- Rob

[Arne Vajhøj]

On 5/22/2020 9:57 AM, Robert A. Brooks wrote:
> On 5/22/2020 8:37 AM, Simon Clubley wrote:
>> What no-one is saying so far (and I hope that doesn't mean it's really
>> bad news) is how much of a performance hit VMS takes when PCID support
>> is not available.

> We have no clue about performance. The compilers are quite raw, and no
> optimization is being attempted. We just want stuff to work, and will worry about
> optimization when we have native compilers.

"first make it work, then make it right, and finally make it fast"

Arne

[already...@yahoo.com]

Proliant G9 is based on Intel Haswell-E (Xeon E5 v3).
In desktop land an equivalent is 4th generation core-i3/5/7.

[Robert A. Brooks]

On 5/22/2020 10:23 AM, already...@yahoo.com wrote:
> On Friday, May 22, 2020 at 1:28:30 AM UTC+3, Arne Vajhøj wrote:

>> Are there any relation between Proliant Gen X and Intel Core Xth Gen??
>>
>
> Proliant G9 is based on Intel Haswell-E (Xeon E5 v3).
> In desktop land an equivalent is 4th generation core-i3/5/7.

I've been told that the specific requirement of Proliant Gen 9 or Gen 10
is because of the requirement of UEFI on the system. Gen 8 and before
did not use UEFI.

--

-- Rob

[John Reagan]

The early boot looks at several features and either adjusts with alternate code or rejects the CPU. We look for things like XSAVE/XSAVEOPT, FSGSBASE, PCID, MTRR, SSE4.1, TSC and frequency, APIC, FXSAVE/FXSRSTOR, and others. Some of these vary among different Intel chips, some are Intel vs AMD. And obviously 64-bit and virtualization support.

It certainly works on my Skylake box.

I haven't booted my ancient Core2Duo from 2008 (still has Windows XP on it). I doubt VirtualBox would even install. I'd have to install some Linux distro and try VBox there only to find out that the chip didn't have something I needed. As I've said many times, the target system is not the Gateway laptop you have in the basement.

[johnwa...@yahoo.co.uk]

There are HPE QuickSpecs around that state the DL380 G9 is based
around:
Intel® C610 Series Chipset
Intel® E5-2600v3 Processor Family
Intel® E5-2600v4 Processor Family
(no point providing a link to stuff like Quickspecs at HPE).

Those who care about these things at this stage can e.g. search for
QuickSpecs c04346247 -15034 -Worldwide -V47 -02-December-2019
and see where it leads.

There seems to be an AMD-based 'equivalent' too, the Proliant
DL385:
https://www.hpe.com/us/en/solutions/amd.html

[Dave Froble]

I've got VirtualBox V4.2.0 or something like that running on a 32 bit
WEENDOZE XP system. Not sure if that would work.

It took a 64 bit WEENDOZE 7 box to install version 6.??

Both on AMD CPUs. Without PCID perhaps neither would work.

[Craig A. Berry]

On 5/22/20 7:37 AM, Simon Clubley wrote:
> On 2020-05-21, Andrew Commons <andrew....@bigpond.com> wrote:

>> One would hope that it is not dependent on esoteric instructions.
>> If it is going to succeed it needs to be able to run on hardware that is in
>> place today and not get derailed by hardware deployed in the future.

> VMS is going to need PCID support for best performance, however VSI do
> have a fallback for when the underlying processor does not support that.
>
> What no-one is saying so far (and I hope that doesn't mean it's really
> bad news) is how much of a performance hit VMS takes when PCID support
> is not available.

According to this:

<https://virtualhackey.wordpress.com/2018/05/24/how-to-check-pcid-availability-for-your-cpu/>

PCID was introduced with Westmere and INVPCID (dunno if VMS also uses
that to defeat Spectre and Meltdown and such) came along with Haswell.

As far as I can find Westmere came out in 2010 and Haswell in 2013. We
are still roughly two years away from OpenVMS x64 v9.2 production
release. So concern about what happens on VMS when there is no PCID
support is basically concern about whether something brand new will run
on hardware that is over 10-12 years old. Yes, I know, people are
stubborn, and tend to think that if an operating system designed for a
GS1280 doesn't run on a Multia their rights are being trampled on, etc.
But the PCID requirement doesn't seem like much to worry about for
anyone trying to do serious work.

It does appear to be the case that a lot of hypervisors did not
initially expose PCID to guests even if the underlying hardware
supported it because PCID was never used for the first almost decade it
was available, but again, the solution is simple: don't run an ancient
version of your hypervisor.

[Bob Gezelter]

David,

Per the VirtualBox www site (Virtualbox.org), the present version is 6.1.8 (released on May 15, 2020). At the same time, maintenance updates of 6.0.22 and 5.4.42 were also released.

Subject to correction from Clair, Rob, or their colleagues, I would presume that OpenVMS-x64 has been checked on the recent versions of VirtualBox. Version 2.x is a bit long of tooth. YMMV.

[clairg...@gmail.com]

I am on Version 6.1.6 r137129 (Qt5.6.3). I move up very frequently.

Another tidbit, in our guests we select ICH9 as the chip set and enable PAE/NX.

BTW: We have not run on AMD yet so all bets are off on that front for a while. (I assume there will be some flavor of problems to overcome.)

[Michael Moroney]

Bob Gezelter <geze...@rlgsc.com> writes:

>Per the VirtualBox www site (Virtualbox.org), the present version is 6.1.8
>(released on May 15, 2020). At the same time, maintenance updates of 6.0.22
>and 5.4.42 were also released.

>Subject to correction from Clair, Rob, or their colleagues, I would presume
>that OpenVMS-x64 has been checked on the recent versions of VirtualBox.
>Version 2.x is a bit long of tooth. YMMV.

It has been suggested that developers keep up to date on Virtualbox updates.
I do.

As Claire has pointed out, nobody is known to have attempted to run on AMD yet.

[Scott Dorsey]

=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com> wrote:
>
>I'm sure I have misunderstood something, but I thought that if OpenVMS runs
>on VirtualBox, it will run on anything where VirtualBox runs.

If you run it on a virtual system, then you should be able to run it on
anything that runs the hypervisor, if it's fast enough and has enough memory.
However, there is the possibility that you will run into issues with things
like the way the hypervisor maps network interfaces. Because this stuff is
not totally foolproof yet.

>But then, if Win10 on my laptop reports "Intel Core i7-6500U CPU", how
>do I know if it is a Gen9/Gen10 CPU or not?

If you run it on a native system, the supported ones are the HP Gen9 and Gen10
servers.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

<VAXman- @SendSpamHere.ORG> wrote:
>In article <ra64vj$dt9$1...@dont-email.me>, "Robert A. Brooks" <FIRST...@vmssoftware.com> writes:
>>On 5/21/2020 9:27 AM, John E. Malmberg wrote:
>>> Is there a test that we can do from Linux or Windows to tell us if
>>> our existing hardware is good enough to run the future VMS 9.x
>>> community licensed edition?
>>
>>The Proliant Gen 9 and Gen 10 are the supported systems.
>>
>>I don't have the detail about what CPU features are specifically required.
>
>Can I purchase one of those without the Billy-tax?

Yes, you can order it with FreeDOS or with Linux.

However, you must use HP-branded disks in the raid, or the raid controller
gets upset. You can use non-HP disks in the four or so non-raid SATA
controllers. Linux people get around this by tossing the HP controller
and installing an LSI one, but my suspicion is that there will not be
VMS support for the LSI controllers yet.

[Andrew Commons]

Simon,

I suspect that a, possibly large, segment of the potential customer base might not really care about this.

Make support something that can be toggled via SYSGEN in the first instance. Customers who are TEMPEST inclined can then make a choice until such time as the installed hardware base has mitigation in the hardware.

That said, there will probably be other side channels discovered by then...hardware, like all software, will be seen to be buggy and we have to learn how to cope with it.

[Simon Clubley]

On 2020-05-22, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
> As far as I can find Westmere came out in 2010 and Haswell in 2013. We
> are still roughly two years away from OpenVMS x64 v9.2 production
> release. So concern about what happens on VMS when there is no PCID
> support is basically concern about whether something brand new will run
> on hardware that is over 10-12 years old.

PCID is Intel only. (Although there are possible upcoming plans to
implement something similar on AMD processors.)

[Simon Clubley]

On 2020-05-22, Andrew Commons <andrew....@bigpond.com> wrote:
>
> Simon,
>
> I suspect that a, possibly large, segment of the potential customer base might not really care about this.
>

PCID is required not for the security issues but to help mitigate the
overhead of emulating 4 hardware modes (KESU) on a 2-mode (KU) architecture.

There is going to be a major overhead from doing this emulation without
PCID or similar support. How major an impact is still unknown and is
why I keep asking the question every so often to see if VSI have been
able to do any performance testing yet.

[Andrew Commons]

Thanks for the clarification.

I haven't thought about that problem for many years...now my head hurts just thinking about thinking about it.

[Bob Gezelter]

Andrew,

WADR, PCID has very little connection to TEMPEST.

PCID has to do with the mitigation for series of cache timing exploitation attacks, e.g., SPECTRE and MELTDOWN. (See the Wikipedia entry for an introduction).

TEMPEST has to do with RF-emissions.

All are security issues, but that is where the similarity ends.

[Andrew Commons]

Bob, I know very well what TEMPEST is. I was attempting, and obviously failing, to imply that the parties most likely to be concerned with Spectre and Meltdown were also likely to be concerned with RF emanations....high security environments. For most other environments there will be far easier ways to gain information than resorting to these vulnerabilities.

[clairg...@gmail.com]

Some text from one of my webinar slides....

VSI is not abandoning direct HW platform support

VSI will test a limited set of systems, for starters
HPE and Dell servers
Intel and AMD processors

We will encourage customers to try other platforms and let us know the results

We assume there will be issues in most cases and will work with customers where appropriate

The problems will usually involve booting the system (UEFI and ACPI), once up most will run with few issues

Bottom line: HW support will depend largely on the customers

[Robert A. Brooks]

On 5/22/2020 11:22 PM, Simon Clubley wrote:

> There is going to be a major overhead from doing this emulation without
> PCID or similar support. How major an impact is still unknown and is
> why I keep asking the question every so often to see if VSI have been
> able to do any performance testing yet.

As I stated a bit ago, do not expect to see any statement related to performance
until we have native compilers.

The cross-compilers are non-optimizing.

Reagan will weigh in if he has anything else to add; the Bliss corner cases
we keep finding are keeping him up at night.

Ask him about LIB$INITIALIZE some day . . .


--
-- Rob

[Bob Gezelter]

Rob,

I am sure. Corner cases are always "stimulating" when boottrapping code generators.

Please correct me if I put too much into your statement, but I would strongly suspect that true performance numbers are likely to be a bit AFTER native compilers are achieved.

Not a complaint in any way or form. Optimizatizers have a tendency to uncover subtle issues and corner cases, and I suspect that such will be the case here.

[Michael Moroney]

"Robert A. Brooks" <FIRST...@vmssoftware.com> writes:

>On 5/22/2020 11:22 PM, Simon Clubley wrote:

>> There is going to be a major overhead from doing this emulation without
>> PCID or similar support. How major an impact is still unknown and is
>> why I keep asking the question every so often to see if VSI have been
>> able to do any performance testing yet.

>As I stated a bit ago, do not expect to see any statement related to performance
>until we have native compilers.

>The cross-compilers are non-optimizing.

That is an understatement! Sometimes when looking through the generated binary
I want to pull what little hair I have left out.
But that's fine, priority is to get things working, who cares if it is super
fast if it won't boot.

Pretty much the only performance report you'll see is that it boots quickly.

>Reagan will weigh in if he has anything else to add; the Bliss corner cases
>we keep finding are keeping him up at night.

>Ask him about LIB$INITIALIZE some day . . .

He has more than a few horror stories...

[Bob Gezelter]

Andrew,

Au contraire. TEMPEST issues can be remediated by external shielding, and require a fair degree of physical proximity and sophistication.

SPECTRE/MELTDOWN are vulnerabilities in the implementation of the CPU instruction set. They are triggered by tailored code sequences. Systems can be attacked from Java-level code. There are remediations, but they come at a significant performance penalty and require cooperating code generation, not something which can always be assumed, as it turns any software supplier into a potential attack vector.

[Craig A. Berry]

On 5/22/20 10:15 PM, Simon Clubley wrote:
> On 2020-05-22, Craig A. Berry <craig...@nospam.mac.com> wrote:
>>
>> As far as I can find Westmere came out in 2010 and Haswell in 2013. We
>> are still roughly two years away from OpenVMS x64 v9.2 production
>> release. So concern about what happens on VMS when there is no PCID
>> support is basically concern about whether something brand new will run
>> on hardware that is over 10-12 years old.
>
> PCID is Intel only. (Although there are possible upcoming plans to
> implement something similar on AMD processors.)

From what I can tell, they've had "something similar" for a long time,
namely ASID:

<http://developer.amd.com/wordpress/media/2012/10/NPT-WP-1%201-final-TM.pdf>

but I don't know enough to know whether the VMS mode emulation can use
that or use it without maintaining a completely separate implementation
for AMD and Intel.

And yes, current AMD documentation does point to PCID support:

<https://www.amd.com/system/files/TechDocs/24593.pdf>

Search for "PCID" in the PDF. So the worst that can happen is that by
the time OpenVMS x64 is out, getting the best performance will require
somewhat newer AMD hardware (or perhaps specific models) compared to
Intel hardware. But being able to start investigating what level of
impact specific chip features will have on performance is probably still
close to a year away.

[John Reagan]

On Saturday, May 23, 2020 at 9:21:16 AM UTC-4, Robert A. Brooks wrote:

The PCID (or lack thereof) isn't related to compiler optimizations. And with VBox (and othes), I'm sure they kill all of the translation buffer entries when my W10 machine switches to my Facebook page streaming a live concert.

And to Mike Moroney's comment, yes, without optimizations enabled, you see all those compiler-generated temporaries moving data from register to stack and right back to the same register.

But with the latest Intel chips (ignorning Spectre/Meltdown) have hundreds of actual general purpose registers and I doubt the data ever actually made it to the memory locations. We have a plan in place for native compilers and optimizations later this year. Since we're still debugging with XDELTA/DELTA, having non-optimized code is better to step through.

[John Reagan]

On Saturday, May 23, 2020 at 9:21:16 AM UTC-4, Robert A. Brooks wrote:

I'm done with LIB$INITALIZE :) I think I'm still chasing a BLISS static initialization bug but I can't isolate it yet. And a bug with Pascal uplevel addressing and non-local GOTOs in the same routine. I'm close on that one.

My latest nightmare is floating point (seriously, I had a floating point dream the other night).

In the meantime, I'm streaming the weekly Willy Porter concert on FB.

[Bob Gezelter]

John,

Just make sure that the handling of floating point exceptions is solid. That way, your dream cannot become too much of a nightmare ...

[Camiel Vanderhoeven]

Op vrijdag 22 mei 2020 17:40:08 UTC+2 schreef John Reagan:

> The early boot looks at several features and either adjusts with alternate code or rejects the CPU. We look for things like XSAVE/XSAVEOPT, FSGSBASE, PCID, MTRR, SSE4.1, TSC and frequency, APIC, FXSAVE/FXSRSTOR, and others. Some of these vary among different Intel chips, some are Intel vs AMD. And obviously 64-bit and virtualization support.
>
> It certainly works on my Skylake box.
>
> I haven't booted my ancient Core2Duo from 2008 (still has Windows XP on it). I doubt VirtualBox would even install. I'd have to install some Linux distro and try VBox there only to find out that the chip didn't have something I needed. As I've said many times, the target system is not the Gateway laptop you have in the basement.

Maybe it's time for me to jump in.

Our idea is to be able to run on any reasonably recent CPU. What we absolutely require are a few things, such as 64-bit, XSAVE and XRSTOR, MTRR's, TSC, APIC. Most of these are present on almost any Intel or AMD 64-bit platform. A 2008 Core2 might actually be a corner case, as support for XSAVE and XRSTOR was added in the August 2008 steppings of Core2. Beyond the CPU, of course, we need UEFI firmware and a decent ACPI implementation from the platform (but VirtualBox or VMware can take care of those requirements).

Verifying this has not been a huge priority, but I think we can probably run in a virtual machine on systems with a 2009 or later Intel çpu. For AMD cpu's we'll probably go back a little less far. Once we release version 9.1 to the public, I'd be very interested in anecdotal information of the "it runs on this hardware/it doesn't run on that hardware" variety, preferably with a log of captured boot output with a few debugging bootflag bits turned on.

On CPU's that have them, there are features that we can use, mainly for performance reasons. Examples of this are PCID's (and no, AMD's ASIDs are not the same thing, as they're expressly reserved for use by a hypervisor), and the XSAVEOPT instruction. The way we deal with these optional features is by loading a different variant of SYSTEM_PRIMITIVES.EXE depending on which features are available. The user has some control over which variant gets loaded through a SYSGEN parameter (you can opt not to use specific available CPU features by disabling them).

Finally, the performance impact of not having (or not using) PCID's. Performance testing at this point is meaningless in general. We're not using any compiler optimizations anywhere, so the system is much slower overall than the production build will be. That means that if we were to measure the impact of something like not using PCIDs, it would be less percentage-wise as it would be in the final version.

Even in the production version, we won't be able to give you a specific percentage, as the impact will be highly application dependent. An application that mostly does number-crunching in user mode will see less impact than an application that uses RMS calls to sort a file one record at a time.

Camiel

[clairg...@gmail.com]

One more thing from the webinar......

Getting from today to the full blown 9.1 is a functional leap; we have to add all the things that we do not have today that complete the total VMS environment...clusters, shadowing, SMP, etc., plus the layered products and the open source stuff.

From 9.1 to 9.2 is stability and performance. I do not expect us to do any serious performance work until well into 2021.

Clair

[Bob Gezelter]

On Sunday, May 24, 2020 at 9:05:02 AM UTC-4, Camiel Vanderhoeven wrote:

Camiel,

Your comments are much appreciated.

It was mentioned earlier in this thread, the desirability of having a Windows/Linux executable which verifies that a CPU has the needed features.

I may be incorrect in my presumptions, but it would seem that such an executable, which would be fairly small, would be a useful initial check that a configuration (virtual or physical) did not contain a CPU functionality showstopper. It would seem simpler than doing all of the preparation, only to find that thee is a CPU issue. I am aware that this would not preclude an ACPI-related issue, but it would seem to be worth the bother.

Your thoughts appreciated.

[Bob Gezelter]

On Sunday, May 24, 2020 at 9:36:17 AM UTC-4, Bob Gezelter wrote:
>
> ... deleted for brevity ...

>
> Camiel,
>
> Your comments are much appreciated.
>
> It was mentioned earlier in this thread, the desirability of having a Windows/Linux executable which verifies that a CPU has the needed features.
>
> I may be incorrect in my presumptions, but it would seem that such an executable, which would be fairly small, would be a useful initial check that a configuration (virtual or physical) did not contain a CPU functionality showstopper. It would seem simpler than doing all of the preparation, only to find that thee is a CPU issue. I am aware that this would not preclude an ACPI-related issue, but it would seem to be worth the bother.
>
> Your thoughts appreciated.
>
> - Bob Gezelter, http://www.rlgsc.com

Camiel,

A clarification. One of the reasons for my suggestion is the use of third-party cloud instances. Coupled with a desire to spare VSI essentially spurious problem calls.

While most major cloud providers and in-house cloud farms are highly likely to be using fairly late model kit, that is hardly a safe presumption. Linux and Windows instances frequently are "canned", making it easy to run such a test without fanfare or arrangement. Forewarned is forearmed.

[Dave Froble]

On 5/23/2020 11:07 PM, Bob Gezelter wrote:
> On Saturday, May 23, 2020 at 8:36:03 PM UTC-4, John Reagan wrote:
>> On Saturday, May 23, 2020 at 9:21:16 AM UTC-4, Robert A. Brooks wrote:

>>> Ask him about LIB$INITIALIZE some day . . .
>>>
>>>
>>> --
>>> -- Rob
>>
>> I'm done with LIB$INITALIZE :)

Ok, I'll bite. Looked up LIB$INITIALIZE in the help on Alpha VMS V8.4
2L1. Nothing there. Is it something not on Alpha? Is it something not
documented? What is it?

[Craig A. Berry]

On 5/24/20 10:33 AM, Dave Froble wrote:
> On 5/23/2020 11:07 PM, Bob Gezelter wrote:
>> On Saturday, May 23, 2020 at 8:36:03 PM UTC-4, John Reagan wrote:
>>> On Saturday, May 23, 2020 at 9:21:16 AM UTC-4, Robert A. Brooks wrote:
>
>>>> Ask him about LIB$INITIALIZE some day . . .

>>> I'm done with LIB$INITALIZE :)
>
> Ok, I'll bite.  Looked up LIB$INITIALIZE in the help on Alpha VMS V8.4
> 2L1.  Nothing there.  Is it something not on Alpha?  Is it something not
> documented?  What is it?

It's in the programing concepts manual and the Alpha internals book, not
the library routines manual. This based on a 10-second web search.
Consider doing your own homework.

[hb]

LIB$INITIALIZE is a PSECT, a routine and a module. You need them for
image initialization. For example, some C programs want to have CRTL
features set before main() runs: they use image initialization.

All you need is to set up a PSECT with this name in your source, which
contains a list of init functions - to be called at image initialization
time, and to include the module with this name, when you link your
program. Everything else is done by linker/image activator magic.

LIB$INITIALIZE, the routine, is defined by LIB$INITIALIZE, the module.
So you can add a reference to the routine to your source module, to get
the LIB$INITIALIZE module automatically included from STARLET.OLB. You
must not call the routine.

Bliss creates a reference to a routine, if you declare it as an external
routine. So in a Bliss program, to get the LIB$INITIALIZE module
included, you just declare the external routine in one source module

In C external function declarations are ignored if they are not
referenced. So in C you define a function pointer and assign it the
value of the external function LIB$INITIALIZE.

This is very likely documented in the VMS documentation, but not in the
LIBRTL documentation, because the routine must not be called.

[Arne Vajhøj]

On 5/24/2020 9:42 AM, Bob Gezelter wrote:
> On Sunday, May 24, 2020 at 9:36:17 AM UTC-4, Bob Gezelter wrote:
>> It was mentioned earlier in this thread, the desirability of having
>> a Windows/Linux executable which verifies that a CPU has the needed
>> features.
>>
>> I may be incorrect in my presumptions, but it would seem that such
>> an executable, which would be fairly small, would be a useful
>> initial check that a configuration (virtual or physical) did not
>> contain a CPU functionality showstopper. It would seem simpler than
>> doing all of the preparation, only to find that thee is a CPU
>> issue. I am aware that this would not preclude an ACPI-related
>> issue, but it would seem to be worth the bother.

> A clarification. One of the reasons for my suggestion is the use of
> third-party cloud instances. Coupled with a desire to spare VSI
> essentially spurious problem calls.
>
> While most major cloud providers and in-house cloud farms are highly
> likely to be using fairly late model kit, that is hardly a safe
> presumption. Linux and Windows instances frequently are "canned",
> making it easy to run such a test without fanfare or arrangement.
> Forewarned is forearmed.

I think the idea of a "vms_capable" test program is a good idea.

Just note that for public cloud there is no guarantee that the
test program and the future VMS instance will run on the same CPU
type.

Arne

[Camiel Vanderhoeven]

Op zondag 24 mei 2020 18:48:52 UTC+2 schreef Arne Vajhøj:

I had a hunch that this might be possible in python, and it is!

Grab cpuid.py from https://github.com/flababah/cpuid.py, and use the following python program to perform a basic test. Note: there may be requirements that I missed, so don't hang me if this test says yes, but VMS doesn't boot. This is literally a five-minute solution to your question. The following appears to work on Windows, Linux, and Mac OS X.

# -*- coding: utf-8 -*-
#
# Quick test to see if a cpu might be capable of running
# VSI OpenVMS 9.x for x86-64.
#
# by Camiel Vanderhoeven
#
# Based on example.py for cpuid.py, which is
# Copyright (c) 2014 Anders Høst
#

from __future__ import print_function

import struct
import cpuid

def cpu_vendor(cpu):
_, b, c, d = cpu(0)
return struct.pack("III", b, d, c).decode("utf-8")

def cpu_name(cpu):
return "".join((struct.pack("IIII", *cpu(0x80000000 + i)).decode("utf-8")
for i in range(2, 5))).strip()

"""
@param {leaf} %eax
@param {sublead} %ecx, 0 in most cases
@param {reg_idx} idx of [%eax, %ebx, %ecx, %edx], 0-based
@param {bit} bit of reg selected by {reg_idx}, 0-based
"""
def is_set(cpu, leaf, subleaf, reg_idx, bit):
regs = cpu(leaf, subleaf)

if (1 << bit) & regs[reg_idx]:
return "Yes"
else:
return "--"

if __name__ == "__main__":
cpu = cpuid.CPUID()

print()
print("OpenVMS 9.x compatibility quick-check")
print()
print("Vendor ID : %s" % cpu_vendor(cpu))
print("CPU name : %s" % cpu_name(cpu))
print()
print("Necessary for OpenVMS 9.x:")
print("XSAVE : %s" % is_set(cpu, 1, 0, 2, 26))
print("TSC : %s" % is_set(cpu, 1, 0, 3, 4))
print("APIC : %s" % is_set(cpu, 1, 0, 3, 9))
print("MTTR : %s" % is_set(cpu, 1, 0, 3, 12))
print("Optional for OpenVMS 9.x:")
print("PCID : %s" % is_set(cpu, 1, 0, 2, 17))
print("X2APIC : %s" % is_set(cpu, 1, 0, 2, 21))
print("XSAVEOPT : %s" % is_set(cpu, 0xd, 1, 0, 0))

[already...@yahoo.com]

IMHO, supporting CPUs without AVX2, FMA and BMI will needlessly complicate things, more so on compilers/libs side, but also on the OS side.

[Simon Clubley]

On 2020-05-24, Camiel Vanderhoeven <iamc...@gmail.com> wrote:
>
> Even in the production version, we won't be able to give you a specific
> percentage, as the impact will be highly application dependent. An
> application that mostly does number-crunching in user mode will see less
> impact than an application that uses RMS calls to sort a file one record at
> a time.
>

The example I gave when this was first being discussed was to consider
running a user mode program that makes 5000 RMS calls and then think
about how many TLB invalidations that is going to involve without PCID
support...

[Arne Vajhøj]

On 5/24/2020 11:33 AM, Dave Froble wrote:
> On 5/23/2020 11:07 PM, Bob Gezelter wrote:
>> On Saturday, May 23, 2020 at 8:36:03 PM UTC-4, John Reagan wrote:
>>> On Saturday, May 23, 2020 at 9:21:16 AM UTC-4, Robert A. Brooks wrote:
>>>> Ask him about LIB$INITIALIZE some day . . .
>>>

>>> I'm done with LIB$INITALIZE :)
>
> Ok, I'll bite.  Looked up LIB$INITIALIZE in the help on Alpha VMS V8.4
> 2L1.  Nothing there.  Is it something not on Alpha?  Is it something not
> documented?  What is it?

It is not a LIB$ function you call. It is a way to get code
executed before your main program starts. And it is documented.
And somewhat messy.

Here is an example (tested on VMS Alpha):

$ type libini.bas
program libini

print "1"

end program

sub pre

print "0"

end sub
$ type trick.mar
.title trick
.extrn lib$initialize
.psect lib$initialize long,nopic,con,gbl,noshr,noexe,nowrt
.address mydisp
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry mydisp,^m<>
calls #0,G^PRE
movl #0,r0
ret
.end
$ bas libini
$ mac trick
$ lin libini+trick
$ run libini
0
1
$

I am not really sure that the code is correct, but the result is
what I tried to achieve.

Arne

[John Reagan]

On Sunday, May 24, 2020 at 3:30:30 PM UTC-4, already...@yahoo.com wrote:

>
> IMHO, supporting CPUs without AVX2, FMA and BMI will needlessly complicate things, more so on compilers/libs side, but also on the OS side.

We enable -sse4.1 as a minimum (except for kernel code where floating is either not allowed or in limited places). We have avoided BMI/BMI2 at the moment. There are places in XMACRO where some of those BMI instructions come close to the VAX INSV/EXTV instructions. But it also a place with you see subtle differences in Intel and AMD with instructions contained in those subsets.

[Mark Berryman]

I just ran this on a Mac Mini that is over 10 years old. Its CPU is a
Core 2 Duo, model P8800. It shows all of the required features but none
of the optional ones.

This would seem to indicate that there is quite a bit of kit out there
that will be able to successfully run OpenVMS x86-64.

Mark Berryman

[Phillip Helbig (undress to reply)]

In article <rah5oi$51j$1...@dont-email.me>, Mark Berryman

<ma...@theberrymans.com> writes:

> I just ran this on a Mac Mini that is over 10 years old. Its CPU is a
> Core 2 Duo, model P8800. It shows all of the required features but none
> of the optional ones.
>
> This would seem to indicate that there is quite a bit of kit out there
> that will be able to successfully run OpenVMS x86-64.

Maybe I could even run VMS on my iPad. One of the first apps I got for
it was a VT220 emulator. However, it connects via telnet or ssh.
Presumably one would have to somehow get a console in order to configure
the network and so on so that one could connect to it.

[Craig A. Berry]

iPads are ARM-based, not x86_64.

[Hans Bachner]

Mark Berryman schrieb am 25.05.2020 um 21:19:
> On 5/24/20 11:50 AM, Camiel Vanderhoeven wrote:
>> Op zondag 24 mei 2020 18:48:52 UTC+2 schreef Arne Vajhøj:

>>> [...]

>>>
>>> I think the idea of a "vms_capable" test program is a good idea.
>>>
>>> Just note that for public cloud there is no guarantee that the
>>> test program and the future VMS instance will run on the same CPU
>>> type.
>>>
>>> Arne
>>
>> I had a hunch that this might be possible in python, and it is!
>>

>> [...]

>
> I just ran this on a Mac Mini that is over 10 years old.  Its CPU is a
> Core 2 Duo, model P8800.  It shows all of the required features but none
> of the optional ones.
>
> This would seem to indicate that there is quite a bit of kit out there
> that will be able to successfully run OpenVMS x86-64.

Another data point (Mac Mini 2012 with a 3rd generation i7 CPU):

admin@mini12 ~ % python cpu_test.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel
CPU name : Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz

Necessary for OpenVMS 9.x:
XSAVE : Yes
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes
XSAVEOPT : Yes
admin@mini12 ~ %

On two other systems running RedHat 7.7 and CentOS 8.0 I get:

> Traceback (most recent call last):
> File "cpu_test.py", line 40, in <module>
> cpu = cpuid.CPUID()
> File "/root/cpuid.py", line 116, in __init__
> raise OSError("Failed to set RWX")
> OSError: Failed to set RWX

The call to self.libc.mprotect returns -1. I tried to query search
engines but they are not really talkative :-(

Hans.

[Mark Daniel]

On 26/5/20 4:49 am, Mark Berryman wrote:
> On 5/24/20 11:50 AM, Camiel Vanderhoeven wrote:

8< snip 8<

> I just ran this on a Mac Mini that is over 10 years old.  Its CPU is a
> Core 2 Duo, model P8800.  It shows all of the required features but none
> of the optional ones.
>
> This would seem to indicate that there is quite a bit of kit out there
> that will be able to successfully run OpenVMS x86-64.
>
> Mark Berryman

Damn...

Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.26 GHz
Number of Processors: 2
Total Number of Cores: 8
Memory: 32 GB

macpro:~ mark$ python x86-64.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz

Necessary for OpenVMS 9.x:
XSAVE : --

TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:

PCID : --
X2APIC : --
XSAVEOPT : --

(might be the necessary excuse)

[Steven Schweda]

> Damn...

Hardware Overview:

Model Name: Mac Pro
Model Identifier: MacPro5,1
Processor Name: Quad-Core Intel Xeon

Processor Speed: 2.4 GHz

Number of Processors: 2
Total Number of Cores: 8

proa$ python x86-64.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

Necessary for OpenVMS 9.x:
XSAVE : --
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:

PCID : Yes
X2APIC : --
XSAVEOPT : Yes

Ooh. So close. (And that's my _new_ (Mid 2010) machine.)

[Steven Schweda]

Mac mini (Late 2010)

Model Name: Mac mini
Model Identifier: Macmini4,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.66 GHz
Number of Processors: 1
Total Number of Cores: 2


min$ python x86-64.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz

Necessary for OpenVMS 9.x:
XSAVE : Yes

TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:

PCID : --
X2APIC : --
XSAVEOPT : --

Mac mini (Late 2012)

Model Name: Mac mini
Model Identifier: Macmini6,1
Processor Name: Dual-Core Intel Core i5
Processor Speed: 2.5 GHz
Number of Processors: 1
Total Number of Cores: 2


minc% python x86-64.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz

Necessary for OpenVMS 9.x:
XSAVE : Yes

TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes

X2APIC : Yes
XSAVEOPT : Yes

[Mark Daniel]

Absolutely.

The 2015 i5 MacBook ticks all the boxes but obviously would prefer to
run VMS on the workhorse.

Can any one comment on the 5590? Apparently there's an upgrade path and
a matched pair affordable at US$50. I'm guessing if a 56.. doesn't tick
the boxes no 55.. will.

Pity, the 5520 runs Win10 VM a treat :-/

[Bob Gezelter]

Camiel,

Much appreciated! The list of what is needed will be useful.

As my contribution, the Dell Latitude E6420 reads out as:

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz

Necessary for OpenVMS 9.x:
XSAVE : Yes

TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes

X2APIC : Yes
XSAVEOPT : Yes

I will start a newsgroup thread dedicated to the results of this python script. If someone at VSI cares to monitor the traffic, the topic might yield a useful compendium of hardware information for future reference.

[Camiel Vanderhoeven]

Updated version of the python script (adds a few features I missed initially):

# -*- coding: utf-8 -*-
#
# Quick test to see if a cpu might be capable of running
# VSI OpenVMS 9.x for x86-64.
#

print("SSE 4.1 : %s" % is_set(cpu, 1, 0, 2, 19))

print("XSAVE : %s" % is_set(cpu, 1, 0, 2, 26))
print("TSC : %s" % is_set(cpu, 1, 0, 3, 4))
print("APIC : %s" % is_set(cpu, 1, 0, 3, 9))
print("MTTR : %s" % is_set(cpu, 1, 0, 3, 12))
print("Optional for OpenVMS 9.x:")
print("PCID : %s" % is_set(cpu, 1, 0, 2, 17))
print("X2APIC : %s" % is_set(cpu, 1, 0, 2, 21))

print("FSGSBASE : %s" % is_set(cpu, 7, 0, 1, 0))
print("MD_CLEAR : %s" % is_set(cpu, 7, 0, 3, 10))

print("XSAVEOPT : %s" % is_set(cpu, 0xd, 1, 0, 0))

print("Possible future optionals:")
print("TSX-HLE : %s" % is_set(cpu, 7, 0, 1, 4))
print("TSX-RTM : %s" % is_set(cpu, 7, 0, 1, 11))
print("UMIP : %s" % is_set(cpu, 7, 0, 2, 2))

[Henry Crun]

On Ubuntu 18.04
cat&pasted the code,(without the ">" ) and got:

$ python cpuid.py

Traceback (most recent call last):

File "cpuid.py", line 39, in <module>
cpu = cpuid.CPUID()
AttributeError: 'module' object has no attribute 'CPUID'

What have I left undone?
Thanks.
Mike


--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

[Camiel Vanderhoeven]

Op dinsdag 26 mei 2020 13:02:06 UTC+2 schreef Henry Crun:

> On Ubuntu 18.04
> cat&pasted the code,(without the ">" ) and got:
>
> $ python cpuid.py
> Traceback (most recent call last):
> File "cpuid.py", line 39, in <module>
> cpu = cpuid.CPUID()
> AttributeError: 'module' object has no attribute 'CPUID'
>
> What have I left undone?

Did you

>> Grab cpuid.py from https://github.com/flababah/cpuid.py

[Henry Crun]

You're right; my bad.
Now:

dir *.py
-rw-r--r-- 1 mike mike 5.7K Jul 19 2018 cpuid.py
-rw-r--r-- 1 mike mike 1.9K May 26 13:54 test-86.py

and:
$ python test-86.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes

XSAVE : Yes
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes

FSGSBASE : Yes
MD_CLEAR : Yes
XSAVEOPT : Yes
Possible future optionals:
TSX-HLE : --
TSX-RTM : --
UMIP : --

Many thanks!

Mike

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.

Missile address: N31.7624/E34.9691

[Henry Crun]

and another:

prodesk
Intel® Core™ i5-8500T CPU @ 2.10GHz × 6
Ubuntu 18.04.4 LTS

$ python test-86.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-8500T CPU @ 2.10GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes
XSAVE : Yes
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes
FSGSBASE : Yes
MD_CLEAR : Yes
XSAVEOPT : Yes
Possible future optionals:

TSX-HLE : Yes
TSX-RTM : Yes
UMIP : --

seems OK.

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.

[Michael Moroney]

Camiel Vanderhoeven <iamc...@gmail.com> writes:

>Updated version of the python script (adds a few features I missed initially):

You may want to, if possible, put something about ASN support in the "Optional"
section. VMS on my laptop complains about lack of ASN support but otherwise
runs fine (although slower than on the Mac). I have not looked to see what
that means.

Also EFI support for those who want it on bare hardware someday.

[Camiel Vanderhoeven]

PCID is the Intel name for ASNs.

[Hans Bachner]

Hans Bachner schrieb am 25.05.2020 um 23:43:
> [... running Camiel's CPU test script ...]

>
> On two other systems running RedHat 7.7 and CentOS 8.0 I get:
>
>> Traceback (most recent call last):
>>   File "cpu_test.py", line 40, in <module>
>>     cpu = cpuid.CPUID()
>>   File "/root/cpuid.py", line 116, in __init__
>>     raise OSError("Failed to set RWX")
>> OSError: Failed to set RWX
>
> The call to self.libc.mprotect returns -1. I tried to query search
> engines but they are not really talkative :-(

Does anyone have an idea what could cause this behaviour or (even
better) how to fix it?

I tried the script on more RedHat/CentOS boxes (both physical and
virtual) and always got the same error. Python versions are 2.7 and 3.6
(iirc).

Thanks for your help,
Hans.

[Craig A. Berry]

You would need to check the value of errno to see why mprotect failed.
Some docs on mprotect are here:

<https://www.man7.org/linux/man-pages/man2/mprotect.2.html>

My first guess would be you just don't have the privileges to poke at
memory that way and you would need to run the program with sudo,
hopefully on a development system.

[hb]

Looks like a security feature.

The code wants to make some memory PROT_EXEC | PROT_WRITE | PROT_READ,
as you can easily conclude from the hard coded numbers. In general write
and exec is not a good idea. The script seems to need it, because it
wants to execute some assembler code. The code is copied to the
allocated memory and very like executed later on. I didn't try, but
maybe you can change the script to allocate the memory PROT_WRITE |
PROT_READ, copy the opcode and set the protection to PROT_EXEC | PROT_READ.

On the other hand, I would expect some documentation for RedHat/CentOS
and the behavior of mprotect.

[Simon Clubley]

On 2020-05-27, hb <end...@inter.net> wrote:
>
> Looks like a security feature.
>
> The code wants to make some memory PROT_EXEC | PROT_WRITE | PROT_READ,
> as you can easily conclude from the hard coded numbers. In general write
> and exec is not a good idea. The script seems to need it, because it
> wants to execute some assembler code. The code is copied to the
> allocated memory and very like executed later on. I didn't try, but
> maybe you can change the script to allocate the memory PROT_WRITE |
> PROT_READ, copy the opcode and set the protection to PROT_EXEC | PROT_READ.
>
> On the other hand, I would expect some documentation for RedHat/CentOS
> and the behavior of mprotect.

Are you running as root or as a normal user ?

Is SELinux in enforcing mode and stopping you ?

[Sprag]

I've tried it on Fedora both as a normal user and root and it looks like SELinux is stopping it due to the execheap policy.

When I set the selinuxuser_execheap boolean to true (which should allow processes to set a chunk of memory as executable even if their contexts don't explicitly allow it) I get a segfault.

I looked at the flags manually on my laptop and it looks like it's good for the required and most of the optional.

[Michael Moroney]

Camiel Vanderhoeven <iamc...@gmail.com> writes:

>PCID is the Intel name for ASNs.

Are you sure that someone isn't looking at the wrong thing?

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes

XSAVE : Yes
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes

FSGSBASE : --
MD_CLEAR : --

XSAVEOPT : Yes
Possible future optionals:

TSX-HLE : --
TSX-RTM : --
UMIP : --

====

BOOTMGR> B
Booting...


%VMS_BOOTMGR-I-TRANSFER: Starting VSI OpenVMS...



%%%%%%% VSI OpenVMS (tm) x86-64 Operator Console %%%%%%%

VSI Primary Kernel SYSBOOT Apr 27 2020 16:55:43

%SYSBOOT-I-VMTYPE, Booting as a VirtualBox (tm) Guest
SYSBOOT-W-NOASNS, ASNs are not supported on this CPU. Performace may suffer.
HPET period is 69841279 fs
For virtual machines, hardtick frequency is 100 per second
EXE$GQ_SYSTIME address ffffffff80200b08 value 00b4a3bedfb1c000


VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, XFJQ-N4A
Copyright 2020 VMS Software, Inc.

MDS Mitigation active, variant nehalem(NEHALEM/WESTMERE/SANDY BRIDGE/IVY BRIDGE)

[Stephen Hoffman]

On 2020-05-27 16:15:57 +0000, Michael Moroney said:

> Camiel Vanderhoeven <iamc...@gmail.com> writes:
>
>> PCID is the Intel name for ASNs.
>
> Are you sure that someone isn't looking at the wrong thing?

> ...

> %SYSBOOT-I-VMTYPE, Booting as a VirtualBox (tm) Guest
> SYSBOOT-W-NOASNS, ASNs are not supported on this CPU. Performace may suffer.

I'll assume the first test was native, and the second (OpenVMS) was as a guest.

Tried booting a not-OpenVMS guest in VirtualBox and testing for PCID there?

Or running the same test with OpenVMS active, and seeing if PCID is
shown there?

The platform vendors have some
possibly-surprising-to-longtime-OpenVMS-folks permutations, Intel has a
gazillion processor variations, and the guests add yet more, hence my
earlier QUALIFY comments.


--
Pure Personal Opinion | HoffmanLabs LLC

[IanD]

On Thursday, May 21, 2020 at 11:29:20 PM UTC+10, John E. Malmberg wrote:
> Is there a test that we can do from Linux or Windows to tell us if our
> existing hardware is good enough to run the future VMS 9.x community
> licensed edition?
>
> Most of my x86_64 systems are several years old.
>
> Just because a system can run VirtualBox or KVM may not be the minimum
> needed for VMS 9.x.
>
> VirtualBox and KVM can pass through CPU features to their guests, but
> may not be able to emulate CPU features that are not present on the
> native hardware that may be needed by the guest operating system.
>
> So looking ahead to see if I will need to get newer hardware and what
> the minimum hardware I would need to run the future VMS 9.X community
> licensed edition for building GNV in a VM.
>
> Regards,
> -John

Seems I am the only one with an AMD cpu so far?

Hope AMD gets some more love going forward, after all, even Linus Torvald has embraced AMD now :-)

https://www.lowyat.net/2020/213985/linus-torvalds-embraces-amd-based-desktop-after-more-than-a-decade-using-intel/

My CPU isn't overly new (released 8/31/2018) but it's not 'that old'

The optional section of the report is looking a little bare, 2/5, :-(

OpenVMS 9.x compatibility quick-check

Vendor ID : AuthenticAMD
CPU name : AMD Ryzen Threadripper 2950X 16-Core Processor

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes
XSAVE : Yes
TSC : Yes
APIC : Yes
MTTR : Yes
Optional for OpenVMS 9.x:

PCID : --
X2APIC : --
FSGSBASE : Yes

[hb]

On 5/27/20 1:33 AM, Hans Bachner wrote:

> Hans Bachner schrieb am 25.05.2020 um 23:43:
>> [... running Camiel's CPU test script ...]
>>
>> On two other systems running RedHat 7.7 and CentOS 8.0 I get:
>>
>>> Traceback (most recent call last):
>>>   File "cpu_test.py", line 40, in <module>
>>>     cpu = cpuid.CPUID()
>>>   File "/root/cpuid.py", line 116, in __init__
>>>     raise OSError("Failed to set RWX")
>>> OSError: Failed to set RWX
>>
>> The call to self.libc.mprotect returns -1. I tried to query search
>> engines but they are not really talkative :-(
>
> Does anyone have an idea what could cause this behaviour or (even
> better) how to fix it?

I tried this on a (live) Fedora 32 and it also failed. A look into the
audit log shows why:
# grep denied /var/log/audit/audit.log
...
type=AVC msg=audit(1590928894.640:256): avc: denied { execheap } for
pid=3388 comm="python" ...

Checking for execheap shows
# getsebool selinuxuser_execheap
selinuxuser_execheap --> off

Setting it (temporarily) to on avoids the failure:
# setsebool selinuxuser_execheap on

$ sed 's/MTTR/MTRR/' -i vms-cpu-reqs.py
$ python vms-cpu-reqs.py

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes

XSAVE : Yes
TSC : Yes
APIC : Yes

MTRR : Yes

Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes

FSGSBASE : Yes
MD_CLEAR : --
XSAVEOPT : Yes
Possible future optionals:
TSX-HLE : --
TSX-RTM : --
UMIP : --

$

I don't know how compatible Fedora 32 and RedHat 7.7/CentOS 8.0 are. But
you should see an entry in the audit log and should be able to
temporarily enable what is denied. You probably can set up a rule for
python or the script (make it executable and add a "#! /usr/bin/python")
to allow making the heap executable. However, I didn't try to find out
how to do that.

On the other hand, there is usually "lshw" in a Linux distro.

[s.ca...@ieee.org]

Thanks for the suggestion of setting the linux se boolean execheap to allow execution. That worked for me. I ran the cpu check program on Centos 7 running under VMWare Workstation 14.1 I got the following:

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes
XSAVE : Yes
TSC : Yes
APIC : Yes

MTTR : Yes
Optional for OpenVMS 9.x:
PCID : --
X2APIC : --
FSGSBASE : --
MD_CLEAR : --
XSAVEOPT : --

Possible future optionals:
TSX-HLE : --
TSX-RTM : --
UMIP : --

When I ran the CPU check program on the same box under VMWare Workstation 14 but this time with a Windows 10 guest I got slightly different results:

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes
XSAVE : Yes
TSC : Yes
APIC : Yes

MTTR : Yes

Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes

FSGSBASE : --
MD_CLEAR : --
XSAVEOPT : --

Possible future optionals:
TSX-HLE : --
TSX-RTM : --
UMIP : --

I ran the CPU Check program again from the Host OS (Windows 7 Pro) and I got results that looked a lot like the Windows 10's guest's results):

OpenVMS 9.x compatibility quick-check

Vendor ID : GenuineIntel

CPU name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

Necessary for OpenVMS 9.x:
SSE 4.1 : Yes
XSAVE : Yes
TSC : Yes
APIC : Yes

MTTR : Yes

Optional for OpenVMS 9.x:
PCID : Yes
X2APIC : Yes

FSGSBASE : --
MD_CLEAR : --
XSAVEOPT : --