4.4.2-rc2 and 4.3.4-rc2 have been tagged

4.4.2-rc2 and 4.3.4-rc2 have been tagged

[Jan Beulich]

All,

aiming at releases with, as before, presumably no further RC on both
of the branches (even more so with the long delay already incurred),
please test! (The plan however is to incorporate the fixes for the XSAs
that are going to go public during the next several days; unless
something extremely important shows up, the expectation is for no
other changes to go in before the release.)

To remind you, 4.3.4 is expected to be the last xen.org coordinated
release on the 4.3 series.

Thanks, Jan

Re: 4.4.2-rc2 and 4.3.4-rc2 have been tagged

[Andrew Cooper]

On 03/03/15 17:18, Jan Beulich wrote:
> All,
>
> aiming at releases with, as before, presumably no further RC on both
> of the branches (even more so with the long delay already incurred),
> please test! (The plan however is to incorporate the fixes for the XSAs
> that are going to go public during the next several days; unless
> something extremely important shows up, the expectation is for no
> other changes to go in before the release.)
>
> To remind you, 4.3.4 is expected to be the last xen.org coordinated
> release on the 4.3 series.
>
> Thanks, Jan

My NMI shootdown fixes still suffer from the TLB shootdown issue which
you identified.  I notice your patch is still not even in staging
(lacking acks?) but it has been thoroughly tested by XenServer.

If that patch can't be fasttracked through, it might be worth
introducing an extra fixmap entry in older trees to avoid introducing a
regression into the crash path for systems using tboot.

~Andrew

Re: 4.4.2-rc2 and 4.3.4-rc2 have been tagged

[Jan Beulich]

>>> On 03.03.15 at 19:13, <andrew.cooper3@citrix.com> wrote:
> My NMI shootdown fixes still suffer from the TLB shootdown issue which
> you identified.  I notice your patch is still not even in staging
> (lacking acks?) but it has been thoroughly tested by XenServer.

Lacking ack-s, right. But I think I'm going to commit at least the first
one now, pinging the other one to see whether the maintainers
react at all (otherwise I'll propose removing their maintainer status,
if need be together with removing the maintained status of the
tboot code).

> If that patch can't be fasttracked through, it might be worth
> introducing an extra fixmap entry in older trees to avoid introducing a
> regression into the crash path for systems using tboot.

I guess this could then go into the branches together with the
pending security fixes.

Jan