Can we create processors for the microarchitectures?

[stuartbh]

Proxmox Users, developers, et alia:

As some of you might well be aware in the summer of 2020 AMD, Intel, RedHat, and SuSE all got together and created the microarchitectures of x86-64-v2, x86-64-v3, and x86-64-v4, each constituting some greater number of available classes of instructions added to the processor's instruction set that each microarchitecture substantiates.

Starting with REL 9, RedHat decided that x86-64-v2 was the minimum required to boot its environment and as such processors of a lesser level will not boot REL 9.

https://developers.redhat.com/blog/...-9-for-the-x86-64-v2-microarchitecture-level#

Now let us say that you have a some older hardware that have these processors and microarchitectures:

"Intel(R) Core(TM) i7-2655LE CPU @ 2.20GHz" meets x86-64-v2
"Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz" meets x86-64-v3
"Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz" meets x86-64-v3

All of the systems with these CPUs will qualify to boot REL 9 with zero problem. In fact, if you specify the processor as 'host' under ProxMox, they will also boot up fine. The issue rears its ugly head when you try to use kvm64 or qemu64. There are no virtual processors that have the proper feature flags even though the host processor supports such features. Thus, if you want to use a more generic virtual processor type you give up capabilities that your processor really does have!

Is there a way that kvm64 or qemu64 (or even some new definition of a processor) can be created so that we can have a virtual version of a processor that supports these microarchitectures?

If the feature flags covered by these microarchitectures were added as extra CPU flags like things like "AES-NI" was, that would ostensibly solve the problem too.

Thanks!

Stuart

 

[apoc]

In fact, if you specify the processor as 'host' under ProxMox, they will also boot up fine.

I was about to mention that. This is the most reasonable approach anyways IMHO.

The issue rears its ugly head when you try to use kvm64 or qemu64.

Why would you want to use these anyways? They limit the usage of registers and therefore impact performance.

For some reason I don't see the point, except perhaps cross cluster live migrations...
Not sure if this is the right place to ask this either. This probably needs to be raised with the KVM and qemu developers (KVM is maintained by redhat iirc)

Hth

 

[stuartbh]

I was about to mention that. This is the most reasonable approach anyways IMHO.

That is the way they are booting up right now. Granted, the environment is a home lab I use for testing and that for my consulting work.

Why would you want to use these anyways? They limit the usage of registers and therefore impact performance.

For some reason I don't see the point, except perhaps cross cluster live migrations...
Not sure if this is the right place to ask this either. This probably needs to be raised with the KVM and qemu developers (KVM is maintained by redhat iirc)

Hth

Well, there are two reasons it interests me to use qemu64 or kvm64 as the processor type. The first being live migration. The second being that not all the members of my cluster are the same processors, I have two NUCs with i7 processors, one HP T620 with an AMD processor, and one x3650 with Xeon 5680 processors in it. I also have a few more Xeon based servers I plan to bring online soon too.

Nothing I do requires live migration, but, it is nice to have it available. The main VM I really care about having HA and live migration for is my pfSense VM and pfSense is FreeBSD based so it can use kvm64 or qemu64 as its CPU type and work fine.

Regarding your point about if this is the correct place to ask about this, I really do not know how much or in what way ProxMox contributes back source code to either KVM or QEMU, but perhaps they do? There is also a way to create custom processors on KVM but it seems only to support CPU flags for the most part and not too much else. Regarding RedHat, I do know a few people there so I can try to get their point of view on it.

Stuart