Does all the PVM code in this repository include the optimizations mentioned in the paper?

[cl0udee]

When I use PVM to deploy Kata Containers in a nested virtualization scenario, I observe a significant performance degradation compared to deploying Kata Containers in a bare metal environment.

I used sysbench to test multiple performance metrics, and the most significant performance gaps were in memory and I/O. I wonder if there are some optimizations that have not been merged into the current repo.

[bysui]

Hi @cl0udee,
Thanks for your interest in PVM.

First, let's clarify that a bare metal environment refers to scenarios based on hardware virtualization (such as Intel VT-x). Are you comparing nested virtualization to bare metal? We must acknowledge that nested virtualization scenarios incur certain performance losses compared to bare metal.

Secondly, memory and I/O are indeed weaknesses of PVM, and performance can significantly decline in these scenarios. In our paper, in response to memory issues, we implemented concurrent page fault handling to reduce lock contention, as well as PV MMU to eliminate the overhead of shadow page tables. We observed that concurrent page fault handling for shadow pages resulted in a noticeable improvement in the test results. However, the optimizations discussed in the paper are based on the 4.19 version of the kernel, which differs from the current open-source version of the codebase, indicating that we are still in the adaptation phase. The PV MMU has shown slight improvements in some benchmark tests, and we have adapted and submitted this to the pv_mmu_draft branch. In the future, we will also update this branch after completing the adaptation of the concurrent code.

Additionally, the testing environment is crucial; different configurations may lead to poor performance in the nested virtualization scenario due to the VM exiting to L0. The mitigations can greatly influence the results. In our testing environment, all mitigations are disabled in the L1/L2 guests. I’m not sure if you have done the same in your testing environments. Furthermore, different CPUID configurations can also affect the results. For example, if the xcr0 for L1/L2 is different, saving/restoring the xcr0 during guest entry/exit can incur more overhead than in a bare-metal scenario.

[cl0udee]

Many thanks for your response! @bysui

I am very interested in both PVM and Kata Containers. I can understand that PVM is a technology that is highly suitable for Kata Containers. I have previously used Kata Containers, so I am very much looking forward to being able to use PVM to deploy more Kata containers on cloud-based servers.

Firstly, in response to your question, the definition of bare metal is consistent with your description. I am comparing bare metal environments with nested virtualization. At the same time, I am also reading your paper and hope to have more exchanges with you!

You mentioned that there are still some optimizations for concurrent page fault handling code that have not yet been merged into the current repo. I suspect this might be the reason for the performance issues I encountered during testing. Could you please let me know when these code are expected to be merged into this repo? At that time, I can retest using the latest code. The memory issue is critical, and I am currently hesitant to use PVM in a production environment.

Regarding the last paragraph you mentioned, which involves some VM configurations, I will confirm this later. Thank you very much for your advice!