Does lxcfs reserve the interface implementation lxcfs.virtualized_cpu_model?

[damoncui1993]

Hello everyone, I use the compiled lxcfs in Centos 7 to associate with the docker container. I want the CPU seen when the container lscpu "Model_NAME" is a name defined by me. Is there currently an interface that can be implemented?

[mihalicyn]

Hi @damoncui1993

No, we have no feature for that. It's easy to cheat on lscpu, because you just need to adjust /proc/cpuinfo implementation to provide fake CPU model. The problem is cpuid instruction (or its counterpart for non amd64 architecture). cpuid is the processor instruction and we can't fake it values with LXCFS. Intel processors have cpuid_fault feature which allows to do that (of course, with some kernel modification), but AMD ones not.

I don't know your use-case, but depending on it, hacking /proc/cpuinfo can be sufficient.

[damoncui1993]

Hi @damoncui1993

No, we have no feature for that. It's easy to cheat on lscpu, because you just need to adjust /proc/cpuinfo implementation to provide fake CPU model. The problem is cpuid instruction (or its counterpart for non amd64 architecture). cpuid is the processor instruction and we can't fake it values with LXCFS. Intel processors have cpuid_fault feature which allows to do that (of course, with some kernel modification), but AMD ones not.

I don't know your use-case, but depending on it, hacking /proc/cpuinfo can be sufficient.

Thank you for your reply. I have a batch of x86 devices on which the customer's docker container is running. If lxcfs is not applicable, the container user can directly read the host's cpuinfo through lscpu to obtain the cpu model. This is what I don't want to see .

Based on your suggestion, do I need to modify the implementation of the int proc_cpuinfo_read function in the src/proc_cpuview.c file to define my own CPU_Model_name? I'm sorry, my programming ability is not very good, and I still have to give pointers again.

[mihalicyn]

Hi @damoncui1993 No, we have no feature for that. It's easy to cheat on lscpu, because you just need to adjust /proc/cpuinfo implementation to provide fake CPU model. The problem is cpuid instruction (or its counterpart for non amd64 architecture). cpuid is the processor instruction and we can't fake it values with LXCFS. Intel processors have cpuid_fault feature which allows to do that (of course, with some kernel modification), but AMD ones not. I don't know your use-case, but depending on it, hacking /proc/cpuinfo can be sufficient.

Thank you for your reply. I have a batch of x86 devices on which the customer's docker container is running. If lxcfs is not applicable, the container user can directly read the host's cpuinfo through lscpu to obtain the cpu model. This is what I don't want to see .

Based on your suggestion, do I need to modify the implementation of the int proc_cpuinfo_read function in the src/proc_cpuview.c file to define my own CPU_Model_name? I'm sorry, my programming ability is not very good, and I still have to give pointers again.

Yes, ultra-hacky approach is to find model name : in output and replace all symbols after with your hardcoded value. But as I mentioned earlier, it makes not much sense. User inside the container can use utilities like cpuid (http://www.etallen.com/cpuid.html) to obtain real CPU model from the CPUID instruction.

LXCFS is about hiding/virtualizing system information for the container processes but only from ones who don't care a lot ;-)

So, my question is why you need to replace CPU model inside the container?

[stgraber]

Closing as faking the CPU model doesn't fit in LXCFS's project goals. The reason for LXCFS is to provide a /proc view consistent with cgroup limits in place, not to fake hardware information.

As mentioned, there's also nothing lxcfs can do about the other ways to get this information, whether it's cpuid or some /sys files.