[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen,x86: introduce tcg_errata
>>> On 25.01.18 at 21:04, <andrew.cooper3@xxxxxxxxxx> wrote: > On 25/01/18 19:43, Stefano Stabellini wrote: >> On Thu, 25 Jan 2018, Andrew Cooper wrote: >>> On 25/01/18 18:37, Stefano Stabellini wrote: >>>> The TCG emulator in QEMU is not good enough to pass the the tests in >>>> stub_selftest. Detect if Xen is running on TCG early, then drop the >>>> tests if it is the case. >>>> >>>> Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx> >>> I'm still opposed to this change. The selftests demonstrate that TCG >>> doesn't work for an architectural area we depend, and simply pretending >>> its not buggy isn't ok. If this were a piece of real hardware, it would >>> be blacklisted in a similar fashion to XSA-9. >>> I still haven't seen a convincing enough usecase to cause Xen to >>> proactively look for Qemu in all cases including release builds on real >>> hardware. >> Testing is a very good use case. > > Testing is good. I approve of testing. > > The problem is that what you are doing here is using a broken testing > tool and instead of fixing the tool, you're bodging Xen to pro-actively > search for your broken testing tool in all cases including release > builds, and ignore one of Xen's safety checks. What about a slightly different approach: Instead of skipping the tests, issue a bright warning (along the lines of the sync_console one) if the tests fail (remember that they're carried out in debug builds only anyway). That'll allow people to use Xen in such an environment, but makes them aware that their testing results may be meaningless. And this wouldn't require probing whether we're running on that qemu emulator. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |