Re: [Xen-devel] getting 4.11.3 ready

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 29 Oct 2019, 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+]

They all make sense, I did the backports, building each commit
individually.

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