[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.