Re: [Xen-devel] getting 4.11.3 ready

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 29/10/2019, 12:41, "Stefano Stabellini" <sstabellini@xxxxxxxxxx> wrote:

    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.
    
Jan, AFAICT this is not yet ready to run the XSA checking tools.
Let me know when you think I should run them
Lars

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