[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Nested virt broken in Linux 4.9 (was Re: [OSSTEST PATCH 2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])

Julien Grall writes ("Re: Nested virt broken in Linux 4.9 (was Re: [OSSTEST 
PATCH 2/3] ap-common: Switch to Linux 4.9 by default [and 1 more messages])"):
> On 30/05/17 17:13, Ian Jackson wrote:
> > I see.  Can you do that please ?  It's blocking moving our testing to
> > a non-ancient kernel.
> I will do that. However, we don't use Linux 4.9 branch for arm64/arm32 
> testing. So why are we blocking on those boards?

It works like this:

The CI in general has a notion of the default Linux.  That is
currently Linux 3.18.  But, there is a special case, and for ARM it is
the special linux-arm-xen branch.

I am trying to update the non-ARM default Linux from 3.18 to 4.9.  For
that to be true, there must be no regressions between 3.18 and 4.9.

Specifically, because changing to 4.9 as the the non-ARM default Linux
version would mean using _the version of Linux 4.9 that has itself
passed osstest's tests_, there must be no x86 regressions between
Linux 3.18 as currently used for the x86 tests, and the
osstest-approved 4.9.

Currently the osstest-approved linux-4.9 contains some x86 nested virt
regressions compared to the osstest-approved linux-3.18.  These are
not regressions _within osstest's view of linux-4.9_ because they
never worked there.

They would be fixed if osstest were to update its version of linux-4.9
to a more recent one, which has bugfixes for the x86 nested virt bugs.

But osstest does not want to update its linux-4.9 branch to include
those x86 nested fixes, because doing so would introduce an ARM
regression _within the 4.9 branch_.

This is relevant because, obviously, when osstest is testing
linux-4.9, it uses it for all architectures.

I hope we can get this fixed soon.  We cannot update to Linux 4.9
until we have a version of 4.9 which doesn't have any regressions.  It
seems people keep breaking it.  If the time to fix any particular
regression too much exceeds the time between new regressions being
introduced, we will never succeed.


Xen-devel mailing list



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