--- Comment #8 from schefis...@gmail.com ---
I captured the traces, they take more than half a GB uncompressed. They are
available in xz under
To make things clear: I have two hosts. HostB is a testing machine. VGA
passthrough with EDKII worked out of the box on 4.1 kernels. It broke with with
several 4.2 versions and also 4.3. Tried several repo versions and untouched
kernel.org versions, that was back about a month ago. Than I tested again back
a few days, and it works again with 4.2.6-301.fc23 fedora repo kernel.
HostA is the problematic one. I did the trace as requested, with 2G and 3G
guest ram. It worked with 4.1 kernels, but still doesn't work with
4.2.6-301.fc23. 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). Of course I made the traces with unmodified kernel,
and only the 2G guest actually booted.
The exact symptom is (when I say it doesn't work), that the guest is extremly
slow. 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. Windows guest only
shows the white dots under the logo circling around very slowly. Once I got a
blue screen, and letters came up one-by-one, like if the error message was
written with a typewriter. Sometimes the guest just shuts down, qemu
terminates. UEFI shell, UEFI setup in guest works perfectly at all conditions,
slowness starts when booting an OS.
I can also provide the traces with working kernel version on HostA and also on
HostB, if requested for comparison.
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). One of the
members on the original Arch Linux thread suggested I put a printk in the
problematic function. 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.
The added line was (just before the return statement in vmx_get_mt_mask):
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);
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. On the other hand it is called
for all in case of small memory.
The traces are NOT from the same run as the dmesg files, as they have been
created before your post about tracing.
Please ask if any more info, traces or dumps are needed. I would be glad to
provide any help.
You are receiving this mail because:
You are watching the assignee of the bug.
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html