Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

[Julien Grall <julien.grall@xxxxxxx>]

On 16/03/2018 16:56, Julien Grall wrote:
> Hi Stefano,
>
> On 16/03/2018 16:33, Stefano Stabellini wrote:
> > On Fri, 16 Mar 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 15/03/18 23:52, Stefano Stabellini wrote:
> > > > On Wed, 14 Mar 2018, Stefano Stabellini wrote:
> > > > > After looking at the test results, which are good for arm, and
> > > > > considering that master hasn't passed yet after 2 more days, I agree
> > > > > with Julien: I think we should not release 4.9.2 and 4.7.5 without the
> > > > > arm64 spectre patches. At this point, I'll proceed to backport the
> > > > > patches now.
> > > > Julien, Andre,
> > > >
> > > > Please give a look at the following branches:
> > > >
> > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > staging-4.7-spectre
> > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > staging-4.8-spectre
> > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > staging-4.9-spectre
> > > For all of the tree above, as I said yesterday, I clearly don't want 
> > > to see
> > > the smccc framework backport for Xen 4.9 and older. This is a massive 
> > > changes
> > > of the interface that is not necessary for spectre. My main concern 
> > > is making
> > > SMC instruction available to the guest.
> > >
> > > It would be just sufficient to emulate the few SMCCC function ID we 
> > > care in
> > > do_trap_psci (function can be renamed).
> > >
> > > This is also clearly wrong to backport coding style or code 
> > > non-justified code
> > > movement (sysreg) just to please the cherry-pick.
> > >
> > > I am also worry to bump the version of the emulated PSCI (0.2 -> 1.0) 
> > > for
> > > those releases. Some guests may rely on a specific version and may now
> > > crashes.
> > >
> > > Overall, the right way to support spectre in earlier releases is 
> > > custom patch
> > > and only do minimal modification.
> > >
> > > > git://xenbits.xen.org/people/sstabellini/xen-unstable.git
> > > > staging-4.10-spectre
> > > The patches below should not be part of spectre nor backport to 4.10:
> > >    - 82e29c87dc7f4f2a7e2f111c3646479da21a910a "ARM: remove unneeded 
> > > gic.h
> > > inclusions"
> > >    - 79563717c9dd5383abcf0ba94d813de9b42e3793 "xen/arm: psci: Prefix 
> > > with
> > > static any functions not exported"
> > >    - 6d0e9b21b1f7213c1994cc2d636448ee2d5372c2 "xen/arm: vpsci: Update 
> > > the
> > > return type for MIGRATE_INFO_TYPE"
> > >
> > > The patches below should not be part of spectre but candidate to 4.10:
> > >    - c2d70f77cc7987be164cd87b76459782497fc540 "xen/arm: vpsci: Rework 
> > > the logic
> > > to start AArch32 vCPU in Thumb mode"
> > >
> > > You will also want to backport [1] which address a relaxation of the
> > > ARM_SMCCC_ARCH_WORKAROUND_1.
> > I understand your concerns, in that case could you please provide the
> > git branches?
> That will have to wait when I have spare cycle. Most likely somewhere in 
> April when I am done from the Xen 4.11 patches and back from holidays.
> So It is probably the right time to put into contribution stakeholders 
> who are using those Xen 4.* stable releases.
To be clear, for Xen 4.10 it is just a matter of dropping the 3 patches 
I suggested. There are actually no clash with the current code.
Although, this would imply a bump to the PSCI version. A new patch 
allowing the user to set the PSCI version would be necessary if we 
consider this important.
Where we would need help is for Xen 4.9, 4.8 and 4.7. For those releases 
what we need is:
        1) Add PSCI Features for the host (Xen 4.10 patches should work)
        2) Add SMCCC detection for the host (Xen 4.10 patches should work)
        3) Bump virtual PSCI to 1.0
        4) Handle only function ID required for the workaround
(SMCCC_FEATURES and WORKAROUND_ARCH_1). All the other will return 0xffff.
        5) Plug to the cpu errata framework

The only patches that would need to be written from scratch is for 4). 
Most of the others could be taken as it is from Xen 4.10 or slightly 
adapt (when code changes).
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel