[vfio-users] regression from linux 4.0.4 to 4.2.0

[globalgorrilla at fastmail.fm]

Alex,

I reported this on 08/18. It's been echoed several times on this list 
since.

You've said everything is working for you and you appear to have a very 
similar setup to us others (passing through devices with VFIO to QEMU 
and using OVMF).

Circumstantial evidence is that there is something in > 4.1 that (often) 
breaks OVMF in QEMU.

How could we dig into this? Perhaps it's not related to vfio?

Regarding the MTRR patch, I had made the fix myself in the 4.2 RCs and I 
believe the patch is merged in already to 4.2 +. I don't think that is 
the culprit ...?

Thoughts?

On 20 Sep 2015, at 9:09, Kővágó Zoltán wrote:

> Hello,
>
> I've been using vfio-pci to passthrough a GPU to virtual machine since 
> some time now, and it worked great.  But this weekend I've finally had 
> enough time to update kernel, and things are completely broken with 
> the new kernel...
>
> I've been using the ACS override patch (and a quick-and-dirty fix for 
> multiple GOPs, but created a proper-ish patch yesterday, see 
> http://article.gmane.org/gmane.linux.kernel.efi/6332 ), CSM disabled 
> in UEFI and using OVMF virtual machines.  The motherboard is an ASRock 
> Z87M Extreme4, with two PCI video cards (an NVidia GT640 (the primary 
> card, used for linux), for which I almost had to beg at Gigabyte 
> support to send an UEFI compatible VBIOS, and a GTX980 (secondary 
> card, to passthrough)).  The integrated Intel GPU is diabled in UEFI 
> settings. I'm not sure if it's supposed to work, but with 4.0.4 
> kernels it worked like a charm.
>
> Now with 4.2.0, when I start qemu the monitor attached to the 
> secondary card powers down, and then nothing happens, except qemu 
> eating about 150% cpu. I've started bisecting the kernel, and found 
> out that
>
> d69afbc6b1b5d0579f13d1a6339d952c4f60a9f4 KVM: MMU: fix decoding cache 
> type from MTRR
>
> is the culprit.  When mtrr is diabled, the old code returns 0xFF while 
> the new returns MTRR_TYPE_UNCACHABLE.  I have absolutely no idea what 
> the hell is going on here, but changing that return statement back 
> solves the problem, until
>
> b18d5431acc7a2fd22767925f3a6f597aa4bd29e KVM: x86: fix CR0.CD 
> virtualization
>
> If I comment out the if kvm_read_cd0 part it will work..  until 
> 4e241557fc1cb560bd9e77ca1b4a9352732a5427, which is a merge commit(!). 
> I'm attaching a patch, it fixes the problem until 
> f2ae45edbca7ba5324eef01719ede0151dc5cead for me.  But as I said 
> earlier I have no freakin' idea what's going on here.
>
> I have recompiled OVMF from svn yesterday evening, and have a 
> recent-ish qemu master (with some audio related patches).  Tell me if 
> you need any more information.
>
> Thanks,
> Zoltan
>
> [magic.patch]
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users