Re: [Xen-devel] getting 4.11.3 ready

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.10.2019 15:30, Julien Grall wrote:
> 
> 
> On 28/10/2019 21:43, Stefano Stabellini wrote:
>> On Mon, 28 Oct 2019, Julien Grall wrote:
>>> Hi,
>>>
>>> On 25/10/2019 11:31, Jan Beulich wrote:
>>>> All,
>>>>
>>>> the 4.11.3 stable release is due. I intend to wait for the XSA fixes
>>>> going public on the 31st, but not (much) longer. Please point out
>>>> backporting candidates that you find missing from the respective
>>>> stable trees. I have three ones queued which haven't passed the push
>>>> gate to the master branch yet:
>>>>
>>>> 9257c218e5 x86/vvmx: Fix the use of RDTSCP when it is intercepted at L0
>>>> 7eee9c16d6 x86/tsc: update vcpu time info on guest TSC adjustments
>>>> 9633929824 x86: fix off-by-one in is_xen_fixed_mfn()
>>>
>>> We don't seem to have backported patches for quite a while on Arm. Some of 
>>> my
>>> patches have been marked as to be backported from the beginning [1]. I am
>>> specifically thinking to:
>>>     
>>> e04818b46d xen/arm: traps: Avoid using BUG_ON() to check guest state in
>>> advance_pc()
> 
> Urgh, I gave the correct title but the wrong commit sha1. It should be 
> 
> 72615f2e6b98e861c08abb1d2b194126013d54fe
> 
>>
>> I have e04818b46d, plus the following marked for backport:
>>
>> e98edccb944a80db782e551f3090628e66c7fb52 xen/arm: SCTLR_EL1 is a 64-bit 
>> register on Arm64
> 
> There are more than that to backport:
> 
> 30f5047b2c4e577436b505ba7627f34c3be02014    xen/arm: gic: Make sure the 
> number of interrupt lines is valid before using it  [4.11]
> 8aa276235b93eeb4f81095c638970900e19b31e5    xen/arm: irq: End cleanly 
> spurious interrupt                                    [4.11]
> b4df73de493954c44f240f78779c9bd3782e1572    xen/arm: gic-v2: deactivate 
> interrupts during initialization                    [4.11]
> 0322e0db5b29a0d1ce4b452885e34023e3a4b00e    arm: gic-v3: deactivate 
> interrupts during initialization                        [4.11]
> 
> 5ba1c5d0641cf63086b3058e547fcd28c3c4a011    xen/arm: memaccess: Initialize 
> correctly *access in __p2m_get_mem_access        [4.12]
> 07e44b3d1be32fa2165c2367ae3ef9c6c8b39e1e    xen/arm: Implement workaround for 
> Cortex A-57 and Cortex A72 AT speculate       [4.12]
> 
> 08e2059facd78d5ffaf206ba06ac2017c4adeed4    xen/arm: setup: Calculate 
> correctly the size of Xen                             [4.11+]
> 8dba9a81e7c62b8a7dbe023fffecd2e16cc20486    xen/arm: Don't use _end in 
> is_xen_fixed_mfn()                                   [4.11+]
> 671878779741b38c5f2363adceef8de2ce0b3945    xen/arm: p2m: Free the p2m entry 
> after flushing the IOMMU TLBs                  [4.11+]
> 7f4217cc60574866cb90d67d9750228c6b86c91e    xen/arm: vsmc: The function 
> identifier is always 32-bit                         [4.11+]
> 612d476e74a314be514ee6a9744eea8db09d32e5    xen/arm64: Correctly compute the 
> virtual address in maddr_to_virt()             [4.11+]
> f51027be0688540aaab61513b06a8693a37e4c00    xen/arm: fix nr_pdxs calculation  
>                                               [4.11+]
> a189ef027dbb7a3c0dfe566137f05c06d6685fb9    xen/arm: mm: Flush the TLBs even 
> if a mapping failed in create_xen_entries      [4.11+]

This is quite long a list for a release about to be cut. Looking
at the branch I don't see any Arm backports other than the ones
done yesterday post-4.11.2. I'm fine with batching, but may I
ask for such batches to not be postponed until the last minute?

Thanks, Jan

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