CPU emulation: change cache size?

[alexc]

I got a bit unusual question related to virtual CPU as it seen in VM.

I need to copy VM with some rare and licensed software from old PVE host (4.x, and old hardware) into new one (PVE 6.2, much newer hardware). The software itself bound its license to id string consists of CPU info bits (vendor_id, cpu family, model, stepping and, for some strange reason, cache size).

Since CPU for VM was set to kvm64, all but last part of that CPU info bits are the same on new PVE host, but cache size is different (old = 4096 Kb, new = 16384 Kb) since, I suppose, it is taken from real CPU that's on system. So the software reports license is broken and no magic can help it.

So, the question is: how can I set cache size reported to VM to some specific value?

 

[oguz]

hi,

you can use the host cpu model to pass the options directly from host cpu.

you can also take a look here [0] for custom cpu options

[0]: https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html

 

[alexc]

hi,

you can use the host cpu model to pass the options directly from host cpu.

you can also take a look here [0] for custom cpu options

[0]: https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html

Thank you, but I just can’t find how to change reported cache size for virtual CPU and your links seems not to help. I see I can report CPU mode and flags, but not cache?

May you please advice the magic how to set CPU cache size that is seen by guest OS?

 

[t.lamprecht]

That's not really possible, at least not without patching QEMU, as of now you get always the L3 cache of your host, only some AMD Epyc models overwrite it but then always with 16 MiB. So your HW change exposed the new, bigger cache size.

QEMU only allows to disable the L3 cache completely, but besides that needing adding some manual arguments it also won't really help here either, as no L3 cache is not equals the 4 MiB from the previous hardware.

The software

What is the software and how do you know the L3 cache change is the real problem?

 

[alexc]

That's not really possible, at least not without patching QEMU, as of now you get always the L3 cache of your host, only some AMD Epyc models overwrite it but then always with 16 MiB. So your HW change exposed the new, bigger cache size.

QEMU only allows to disable the L3 cache completely, but besides that needing adding some manual arguments it also won't really help here either, as no L3 cache is not equals the 4 MiB from the previous hardware.


What is the software and how do you know the L3 cache change is the real problem?

You see, this is some some small company produced software and the author is kind of non-pleasant person who think everyone will try to steal his software (not that case, but we can’t prove him anything). This time (of 4->16 Mb cache change) we almost ready to pay him for reissue the license for new hardware (even that we once paid him for), but we discussing future risks as well.

What if we’ll need to change server next time in maybe 10 years, caches will be different again, and the author be unavailable for any reason - we simple can not do that transition to new server then?

So if there is any strategy that we can set up our server and PVE this time, issue license for this set of hardware, and next time be able to reproduce the same virtual hardware (CPU) on next server, we are ready to use that way.

And I suppose disabling cache is not good for software, right? After all, we expect the software will do some useful calculations for us, without cache it will be much slower. AMD is possible, but today we use Intel so this transition may be quite hard to implement.

 

[t.lamprecht]

You see, this is some some small company produced software and the author is kind of non-pleasant person who think everyone will try to steal his software (not that case, but we can’t prove him anything). This time (of 4->16 Mb cache change) we almost ready to pay him for reissue the license for new hardware (even that we once paid him for), but we discussing future risks as well.

Depending on the licensing terms and your jurisdiction that may be well their rights to do.

If there's any competition in that space you could use that as leverage when trying to convince that this movement is not a theft.
In any case, if it is just the CPU it's probably senseless anyway, as one can just buy the same model as the licence and be done...

So if there is any strategy that we can set up our server and PVE this time, issue license for this set of hardware, and next time be able to reproduce the same virtual hardware (CPU) on next server, we are ready to use that way.

Strategies depend on your jurisdiction too, circumventing such copy protections may be illegal, even if not done for theft or the like. IMO, the best long term solution is to get in agreement with that developer or else search for a competition without this strict terms - as then you do not need to hack around, can be sure to be on the legal side and still on good terms (or at least not bad terms) with the dev.

And I suppose disabling cache is not good for software, right? After all, we expect the software will do some useful calculations for us, without cache it will be much slower. AMD is possible, but today we use Intel so this transition may be quite hard to implement.

I mean, it's not really disabling the L3 cache, that cannot be done for in software (besides from the CPU "microcode" firmware itself), it only changes what is reported by the CPUID informational instruction in the guest - still some software checks this and behaves worse with L3 shown as non-existent. Also, as mentioned, I do not think that is a solution to the problem.

For completeness sake only: Changing that would require patching QEMU's CPU info cache handling in target/i386/cpu.c, if you cannot do that yourself, you could ask QEMU developers if they'd be open for such options, currently no idea what the opinion is for such stuff.