preparations for 4.13.3

preparations for 4.13.3

[Jan Beulich]

All,

the release is overdue (my apologies). Please point out backports
you find missing from the respective staging branches, but which
you consider relevant.

Ones that I have queued already, but which hadn't passed the push
gate to master yet when doing a swipe late last week, are

c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized

Jan

Re: preparations for 4.13.3

[Julien Grall]

Hi Jan & Stefano,

On 08/03/2021 09:49, Jan Beulich wrote:
> All,
> 
> the release is overdue (my apologies). Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant.
> > Ones that I have queued already, but which hadn't passed the push
> gate to master yet when doing a swipe late last week, are
> 
> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized

I would like to also consider the following one:

28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 
2} drivers (4.11+ as updating the security support)
067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
     To support newer kernel on stable Xen
d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped 
(4.13 only)
f6790389613c xen/arm: sched: Ensure the vCPU context is seen before 
vcpu_pause() returns (4.13 only)

I have put in parentheses the list of versions targeted.

Cheers,

-- 
Julien Grall

Call for tools backports (was Re: preparations for 4.13.3)

[Ian Jackson]

Julien Grall writes ("Re: preparations for 4.13.3"):
> On 08/03/2021 09:49, Jan Beulich wrote:
> > All,
> > 
> > the release is overdue (my apologies). Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant.
> > > Ones that I have queued already, but which hadn't passed the push
> > gate to master yet when doing a swipe late last week, are
> > 
> > c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
> > 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
> > 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized
> 
> I would like to also consider the following one:
> 
> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 
> 2} drivers (4.11+ as updating the security support)
> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
>      To support newer kernel on stable Xen
> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped 
> (4.13 only)
> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before 
> vcpu_pause() returns (4.13 only)
> 
> I have put in parentheses the list of versions targeted.

My backport list seems to have very few tools patches on it.

If anyone has any tools bugfixes that ought to go into 4.13 please do
let me know!

Additionally, perhaps this one commit to be backported ?
  935e0836710ce8cab584155b2844cea8497a5159
  arm: replace typeof() with __typeof__()

Thanks,
Ian.

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Julien Grall]

Hi Ian,

On 17/03/2021 14:55, Ian Jackson wrote:
> Julien Grall writes ("Re: preparations for 4.13.3"):
>> On 08/03/2021 09:49, Jan Beulich wrote:
>>> All,
>>>
>>> the release is overdue (my apologies). Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant.
>>>> Ones that I have queued already, but which hadn't passed the push
>>> gate to master yet when doing a swipe late last week, are
>>>
>>> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
>>> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
>>> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized
>>
>> I would like to also consider the following one:
>>
>> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1,
>> 2} drivers (4.11+ as updating the security support)
>> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
>>       To support newer kernel on stable Xen
>> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
>> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
>> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
>> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped
>> (4.13 only)
>> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before
>> vcpu_pause() returns (4.13 only)
>>
>> I have put in parentheses the list of versions targeted.
> 
> My backport list seems to have very few tools patches on it.
> 
> If anyone has any tools bugfixes that ought to go into 4.13 please do
> let me know!
> 
> Additionally, perhaps this one commit to be backported ?
>    935e0836710ce8cab584155b2844cea8497a5159
>    arm: replace typeof() with __typeof__()

I think it would be useful.

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.3

[Julien Grall]

Hi Stefano,

Gentle ping. On IRC, Jan pointed out that he would like to realize the 
4.13.3 pretty soon.

Cheers,

On 13/03/2021 15:29, Julien Grall wrote:
> Hi Jan & Stefano,
> 
> On 08/03/2021 09:49, Jan Beulich wrote:
>> All,
>>
>> the release is overdue (my apologies). Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant.
>> > Ones that I have queued already, but which hadn't passed the push
>> gate to master yet when doing a swipe late last week, are
>>
>> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
>> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization 
>> without reserved bits
>> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when 
>> running virtualized
> 
> I would like to also consider the following one:
> 
> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 
> 2} drivers (4.11+ as updating the security support)
> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
>      To support newer kernel on stable Xen
> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 
> (4.13+)
> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped 
> (4.13 only)
> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before 
> vcpu_pause() returns (4.13 only)
> 
> I have put in parentheses the list of versions targeted.
> 
> Cheers,
> 

-- 
Julien Grall

Re: preparations for 4.13.3

[Andrew Cooper]

On 08/03/2021 09:49, Jan Beulich wrote:
> All,
>
> the release is overdue (my apologies). Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant.
>
> Ones that I have queued already, but which hadn't passed the push
> gate to master yet when doing a swipe late last week, are
>
> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized

fe36a173d110 - x86/amd: Initial support for Fam19h processors
90b014a6e6ec - x86/ucode/amd: Fix microcode payload size for Fam19
processors

~Andrew

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Andrew Cooper]

On 17/03/2021 14:55, Ian Jackson wrote:
> Julien Grall writes ("Re: preparations for 4.13.3"):
>> On 08/03/2021 09:49, Jan Beulich wrote:
>>> All,
>>>
>>> the release is overdue (my apologies). Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant.
>>>> Ones that I have queued already, but which hadn't passed the push
>>> gate to master yet when doing a swipe late last week, are
>>>
>>> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
>>> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
>>> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized
>> I would like to also consider the following one:
>>
>> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 
>> 2} drivers (4.11+ as updating the security support)
>> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
>>      To support newer kernel on stable Xen
>> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
>> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
>> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
>> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped 
>> (4.13 only)
>> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before 
>> vcpu_pause() returns (4.13 only)
>>
>> I have put in parentheses the list of versions targeted.
> My backport list seems to have very few tools patches on it.
>
> If anyone has any tools bugfixes that ought to go into 4.13 please do
> let me know!
>
> Additionally, perhaps this one commit to be backported ?
>   935e0836710ce8cab584155b2844cea8497a5159
>   arm: replace typeof() with __typeof__()

These are general backport requests, not specifically for 4.13

d92ba1aa7cf8 - tools/ocaml: libxb: Harden stub_header_of_string()
59b087e39544 - tools/ocaml: Fix stubs build when OCaml has been compiled
with -safe-string
78686437e949 - tools/ocaml: libxb: Avoid to use String_val() when value
is bytes
2b8079610ec5 - tools/libxc: misc: Mark const the parameter 'keys' of
xc_send_debug_keys()
a6ed77f1e033 - oxenstored: fix ABI breakage introduced in Xen 4.9.0

The penultimate one is an API change, but strictly in a relaxing
direction.  The final one is an ABI change, but fixing a regression.


5e31789634 - tools/ocaml/libs/xb: Do not crash after xenbus is unmapped
2a47797d1f - tools/oxenstored: Trim txhistory on xenbus reconnect
c8b9670825 - tools/oxenstored: Fix quota calculation for mkdir EEXIST
dc8caf214fb - tools/oxenstored: Reject invalid watch paths early
45dee7d92b - tools/oxenstored: mkdir conflicts were sometimes missed


Do we want to backport the -Og fixes so we can get ABI checking working?

~Andrew

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Jan Beulich]

On 19.03.2021 12:57, Andrew Cooper wrote:
> Do we want to backport the -Og fixes so we can get ABI checking working?

Do we have a finalized picture of how this checking is going to
work? I was under the impression that this is still in flux, in
which case I'm not convinced of backporting changes just because
they're prereqs to this.

Jan

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Ian Jackson]

Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for 4.13.3)"):
> These are general backport requests, not specifically for 4.13

Thanks!

> d92ba1aa7cf8 - tools/ocaml: libxb: Harden stub_header_of_string()
> 59b087e39544 - tools/ocaml: Fix stubs build when OCaml has been compiled
> with -safe-string
> 78686437e949 - tools/ocaml: libxb: Avoid to use String_val() when value
> is bytes

These look straightforward.

> 2b8079610ec5 - tools/libxc: misc: Mark const the parameter 'keys' of
> xc_send_debug_keys()
...
> The penultimate one is an API change, but strictly in a relaxing
> direction.

I am happy with this and will backport it.

> a6ed77f1e033 - oxenstored: fix ABI breakage introduced in Xen 4.9.0
> 
>  The final one is an ABI change, but fixing a regression.

I'm not sure about this but I think the effect can only be on
"Reset_watches" ?  I guess I will take it.

> 5e31789634 - tools/ocaml/libs/xb: Do not crash after xenbus is unmapped
> 2a47797d1f - tools/oxenstored: Trim txhistory on xenbus reconnect
> c8b9670825 - tools/oxenstored: Fix quota calculation for mkdir EEXIST
> dc8caf214fb - tools/oxenstored: Reject invalid watch paths early
> 45dee7d92b - tools/oxenstored: mkdir conflicts were sometimes missed

Ack, thanks.

> Do we want to backport the -Og fixes so we can get ABI checking working?

As Jan says, I think these are still in a state of flux ?

Ian.

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Andrew Cooper]

On 19/03/2021 13:21, Ian Jackson wrote:
>> a6ed77f1e033 - oxenstored: fix ABI breakage introduced in Xen 4.9.0
>>
>>  The final one is an ABI change, but fixing a regression.
> I'm not sure about this but I think the effect can only be on
> "Reset_watches" ?  I guess I will take it.

The effects of the bug were twofold:
 * A client actually requesting Reset_watches has the request rejected
 * A client actually requesting Restrict got Reset_watches instead

We spotted the bug when trying to add soft-reset support to Xapi, where
a Reset_watches request got a hard error and the guest choked.

>> Do we want to backport the -Og fixes so we can get ABI checking working?
> As Jan says, I think these are still in a state of flux ?

The ABI checking side, yes, but the -Og is a prerequisite which is
fairly self contained.

~Andrew

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Ian Jackson]

Ian Jackson writes ("Re: Call for tools backports (was Re: preparations for 4.13.3)"):
> Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for 4.13.3)"):
> > These are general backport requests, not specifically for 4.13
> 
> Thanks!

I have now applied these, I think each to the appropriate trees.

I went back to 4.11, which is still security-supported, because
several of the oxenstored changes seemed to have some kind of possible
security implications even if they weren't XSA-worthy.  It seemed
better to backport the whole lot for 4.11 and 4.12 than to try to pick
apart which, if any, were security-relevant.

So, thanks for the information.

Ian.

Re: Call for tools backports (was Re: preparations for 4.13.3)

[Ian Jackson]

Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for 4.13.3)"):
> The effects of the bug were twofold:
>  * A client actually requesting Reset_watches has the request rejected
>  * A client actually requesting Restrict got Reset_watches instead
> 
> We spotted the bug when trying to add soft-reset support to Xapi, where
> a Reset_watches request got a hard error and the guest choked.

Thanks for the info.  What fun.  I have taken it.

> >> Do we want to backport the -Og fixes so we can get ABI checking working?
> > As Jan says, I think these are still in a state of flux ?
> 
> The ABI checking side, yes, but the -Og is a prerequisite which is
> fairly self contained.

I think I would prefer to wait for the ABI checking as a whole to
congeal before backporting even this self-contained prereq.  Feel free
to try to change my mind if you think this is a wrong decision.

Thanks,
Ian.

Re: preparations for 4.13.3

[Jan Beulich]

On 19.03.2021 12:44, Andrew Cooper wrote:
> On 08/03/2021 09:49, Jan Beulich wrote:
>> the release is overdue (my apologies). Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant.
>>
>> Ones that I have queued already, but which hadn't passed the push
>> gate to master yet when doing a swipe late last week, are
>>
>> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
>> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
>> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized
> 
> fe36a173d110 - x86/amd: Initial support for Fam19h processors
> 90b014a6e6ec - x86/ucode/amd: Fix microcode payload size for Fam19
> processors

For the latter one, didn't you indicate to me elsewhere that there
was still some uncertainty about the value?

Jan

Re: preparations for 4.13.3

[Andrew Cooper]

On 19/03/2021 14:02, Jan Beulich wrote:
> On 19.03.2021 12:44, Andrew Cooper wrote:
>> On 08/03/2021 09:49, Jan Beulich wrote:
>>> the release is overdue (my apologies). Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant.
>>>
>>> Ones that I have queued already, but which hadn't passed the push
>>> gate to master yet when doing a swipe late last week, are
>>>
>>> c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
>>> 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without reserved bits
>>> 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when running virtualized
>> fe36a173d110 - x86/amd: Initial support for Fam19h processors
>> 90b014a6e6ec - x86/ucode/amd: Fix microcode payload size for Fam19
>> processors
> For the latter one, didn't you indicate to me elsewhere that there
> was still some uncertainty about the value?

I'm attempting to get the number put somewhere helpful in documentation,
but I'm fairly confident this is the correct number now.

~Andrew

Re: preparations for 4.13.3

[Stefano Stabellini]

On Sat, 13 Mar 2021, Julien Grall wrote:
> Hi Jan & Stefano,
> 
> On 08/03/2021 09:49, Jan Beulich wrote:
> > All,
> > 
> > the release is overdue (my apologies). Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant.
> > > Ones that I have queued already, but which hadn't passed the push
> > gate to master yet when doing a swipe late last week, are
> > 
> > c6ad5a701b9a crypto: adjust rijndaelEncrypt() prototype for gcc11
> > 9318fdf757ec x86/shadow: suppress "fast fault path" optimization without
> > reserved bits
> > 60c0444fae21 x86/shadow: suppress "fast fault path" optimization when
> > running virtualized
> 
> I would like to also consider the following one:
> 
> 28804c0ce9fd SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 2}
> drivers (4.11+ as updating the security support)
> 067935804a8e xen/vgic: Implement write to ISPENDR in vGICv{2, 3} (4.13+)
>     To support newer kernel on stable Xen
> d81133d45d81 xen/arm: Add workaround for Cortex-A53 erratum #843419 (4.13+)
> fd7479b9aec2 xen/arm: Add workaround for Cortex-A55 erratum #1530923 (4.13+)
> 5505f5f8e7e8 xen/arm: Add Cortex-A73 erratum 858921 workaround (4.13+)
> 63b4c9bfb788 xen/arm: mm: Access a PT entry before the table is unmapped (4.13
> only)
> f6790389613c xen/arm: sched: Ensure the vCPU context is seen before
> vcpu_pause() returns (4.13 only)
> 
> I have put in parentheses the list of versions targeted.


Thanks that was very helpful. I took care of those commits plus a
couple of others:

934bb4c87cf2 xen/arm: Document the erratum #853709 related to Cortex A72
a702c80ec193 xen/arm: call iomem_permit_access for passthrough devices
2fb361c36aa9 xen/arm: mm: Remove ; at the end of mm_printk()
284aed024f58 xen/arm: vgic-v3: fix GICD_ISACTIVER range