[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] getting 4.11.3 ready
Hi Jan,
On 29/10/2019 14:49, Jan Beulich wrote:
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?
That's ~1 year worth of backport because nobody looked at it. Apologies if it
comes late but I only noticed the backport request e-mail yesterday as I am not
CCed.
I am happy to take over the backports for Arm if that helps to get patches
backported in a more timely manner.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
