It is visible from dmesg files that in case of large guest ram, the function doesn't even get called for vcpus other than 0. Printk(KERN_INFO "vmx_get_mt_mask got the following: cpu=%d, vcpu=%d, gfn=%x, MMIO=%d, cache=%x", vcpu->cpu, vcpu->vcpu_id, gfn, is_mmio, cache) The added line was (just before the return statement in vmx_get_mt_mask):
The dmesg files in each folder show the arguments of vmx_get_mt_mask and what kvm_mtrr_get_guest_memory_type returns to it. One of the members on the original Arch Linux thread suggested I put a printk in the problematic function. In the shared folders you can find MTRR, PAT, and lspci -vvv info for each host, along with traces for HostA as requested (2GB and 3GB). I can also provide the traces with working kernel version on HostA and also on HostB, if requested for comparison. UEFI shell, UEFI setup in guest works perfectly at all conditions, slowness starts when booting an OS. Sometimes the guest just shuts down, qemu terminates. Once I got a blue screen, and letters came up one-by-one, like if the error message was written with a typewriter.
Qemu vga passthrough non uefi windows#
Windows guest only shows the white dots under the logo circling around very slowly. I tried booting live Linux guest, after about 15 minutes a saw messages, but even after two hours I still couldn't get to a shell.
The exact symptom is (when I say it doesn't work), that the guest is extremly slow. Of course I made the traces with unmodified kernel, and only the 2G guest actually booted. I can make it work with either lowering RAM to under 2.5 GB or with my beforementioned modification (kvm_mtrr_get_guest_memory_type to always return MTRR_TYPE_WRBACK). It worked with 4.1 kernels, but still doesn't work with 4.2.6-301.fc23. I did the trace as requested, with 2G and 3G guest ram. Than I tested again back a few days, and it works again with 4.2.6-301.fc23 fedora repo kernel. Tried several repo versions and untouched versions, that was back about a month ago. It broke with with several 4.2 versions and also 4.3. VGA passthrough with EDKII worked out of the box on 4.1 kernels. I captured the traces, they take more than half a GB uncompressed. The other bug mentions very similar hardware to mine, and issues started the same time (upgrading to 4.2.x) with a pci passthrough configuration.
I would also like to point out, that may be related. It seems as the new function (in 4.2 and onward) does not return the proper cache type in case of pci passthrough configurations. Guest boots correctly.Īlthough I know, that hardcoding Write-back mode is not a viable long-term solution. This is all related to how the hardware is set up regarding IOMMU, MMIO, VT-d and EPT andress translation.įor experimenting purposes I simply modified kvm_mtrr_get_guest_memory_type to always return MTRR_TYPE_WRBACK and that fixed the issue. This kvm_mtrr_get_guest_memory_type function is only called by vmx_get_mt_mask. What kvm_mtrr_get_guest_memory_type() does is basically decides what cache type to use (Uncachable, Write-Back, or Write-Through) based on the function mtrr_for_each_mem_type().
Qemu vga passthrough non uefi code#
To my knowledge 4.1.x versions didn't have this code set at all. Actually this was the commit to break it, but it is only a small part of the feauture set implementing vMTRR. I narrowed it down earlier to "simplify kvm_mtrr_get_guest_memory_type".
0 kommentar(er)
