> -----Original Message-----
> From: Paul Durrant <xadimgnik@gmail.com>
> Sent: 15 June 2020 18:04
> To: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'Xen-devel' <xen-devel@lists.xenproject.org>
> Cc: 'Wei Liu' <wl@xen.org>; 'Jan Beulich' <JBeulich@suse.com>; 'Ian Jackson' <Ian.Jackson@citrix.com>;
> 'Roger Pau Monné' <roger.pau@citrix.com>
> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
> 
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Andrew Cooper
> > Sent: 15 June 2020 15:15
> > To: Xen-devel <xen-devel@lists.xenproject.org>
> > Cc: Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>;
> Jan
> > Beulich <JBeulich@suse.com>; Ian Jackson <Ian.Jackson@citrix.com>; Roger Pau Monné
> > <roger.pau@citrix.com>
> > Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
> >
> > This is some work in light of IvyBridge not gaining microcode to combat SRBDS
> > / XSA-320.  It is a mix of some work I'd planned for 4.15, and some patches
> > posted already and delayed due to dependence's I'd discovered after-the-fact.
> >
> > This provides a more user-friendly way of making IvyBridge safe by default
> > without encountering migration incompatibilities.
> >
> > In terms of functionality, it finishes the "fresh boot" vs "migrate/restore
> > from pre-4.14" split in the libxc CPUID logic, and uses this to let us safely
> > hide features by default without breaking the "divine what a guest may have
> > seen previously" logic on migrate.
> >
> > On top of that, we hide RDRAND by default to mitigate XSA-320.
> >
> > Additionally, take the opportunity of finally getting this logic working to
> > hide MPX by default (as posted previously), due to upcoming Intel timelines.
> >
> > Request for 4.14.  The IvyBridge angle only became apparent after the public
> > embargo on Tue 9th.  Otherwise, I would have made a concerted effort to get
> > this logic sorted sooner and/or part of XSA-320 itself.
> >
> > Strictly speaking, patches 1-4 aren't necessary, but without them the logic is
> > very confusing to follow, particularly the reasoning about the safely of later
> > changes.  As it is a simple set of transforms, we're better with them than
> > without.
> >
> > Also, the MPX patch isn't related to the RDRAND issue, but I was planning to
> > get it into 4.14 already, until realising that the migration path was broken.
> > Now that the path is fixed for the RDRAND issue, include the MPX patch as it
> > pertains to future hardware compatibility (and would be backported to 4.14.1
> > if it misses 4.14.0).
> >
> 
> Fair enough. Once the series has all the requisite maintainer acks then I'll release-ack it.
> 

I believe all acks are now place so the series is...

Release-acked-by: Paul Durrant <paul@xen.org>