On 13/11/2019 14:42, Jan Beulich wrote: > On 13.11.2019 12:55, osstest service owner wrote: >> flight 144059 xen-4.12-testing real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/144059/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. >> vs. 144035 > From looking at this some I get the impression that the L2 guest > is busy-waiting in its boot loader. Seeing that the same test > also failed for 4.11, it doesn't seem entirely impossible that > the fixes for the two XSAs have caused a regression here. Any > other thoughts / insights anyone?
OSSTest has no hardware which is impacted by 305, so I'm fairly confident ruling that out. (For affected hardware, it is only boot-time changes.) (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) This is a Haswell box, so is impacted by 304. (Its actually the same CPU as my main dev box so has had a *lot* of testing in this area...) L0 reports: (XEN) VMX: Disabling executable EPT superpages due to CVE-2018-12207 as expected. L1 should find that it is virtualised and turn off the mitigation, but we don't get that far during boot. I can't see how the nested-virt aspect would be relevant at this point, so I can't reason about what might have gone wrong. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
