Re: preparations for 4.14.5 ?

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]

On Mon, Apr 04, 2022 at 03:42:09PM +0200, Jan Beulich wrote:
> On 01.04.2022 15:46, Marek Marczykowski-Górecki wrote:
> > On Wed, Mar 30, 2022 at 12:16:00PM +0200, Jan Beulich wrote:
> >> All,
> >>
> >> while 4.14's general support period ended in January, we're considering
> >> to cut an out-of-band release due to the relatively large number of
> >> security relevant backports which has accumulated in just 2 months. By
> >> doing this we would _not_ be promising to do so again in the future.
> >> Please voice objections to the plan (or support for it) in the next
> >> couple of days.
> >>
> >> Since it's a little easier to "batch" releases, I would intend to keep
> >> 4.14.5 aligned with 4.16.1.
> >>
> >> Commits I have queued but not committed to the branch yet (and I won't
> >> until in a couple of days time, to allow for objections to the plan to
> >> be raised):
> >>
> >> dd6c062a7a4a tools/libxl: Correctly align the ACPI tables
> >> aa390d513a67 build: fix exported variable name CFLAGS_stack_boundary
> >> e62cc29f9b6c tools/libs: Fix build dependencies
> >> eddf13b5e940 x86emul: fix VPBLENDMW with mask and memory operand
> >> 6bd1b4d35c05 x86/console: process softirqs between warning prints
> >> 07449ecfa425 tools/libxl: don't allow IOMMU usage with PoD
> >> 10454f381f91 xz: avoid overlapping memcpy() with invalid input with in-place decompression
> >> 0a21660515c2 xz: validate the value before assigning it to an enum variable
> >> b4f211606011 vpci/msix: fix PBA accesses
> >>
> >> Please point out backports you find missing from both the respective
> >> staging branch and the list above, but which you consider relevant.
> > 
> > I'm not sure if "just" bugfix qualify for 4.14 at this point, but if so,
> > I'd propose:
> > 0a20a53df158 tools/libs/light: set video_mem for PVH guests
> > 
> > In any case, the above should be backported to 4.15 and 4.16.
> 
> Hmm, Anthony, I'd like to ask for your view here: This looks more
> like a cosmetic change to me at the first glance. Plus it's a
> little odd to see it being proposed for backporting now, when it's
> already almost 4 months old and hence could have gone into 4.15.2
> and 4.14.4 if it was important.

A little context (from IRC discussion on Friday) - this was only
recently identified to fix videoram set to -1 on PVH:
/local/domain/22/memory/static-max = "819200"   (n0,r22)
/local/domain/22/memory/target = "819201"   (n0,r22)
/local/domain/22/memory/videoram = "-1"   (n0,r22)

And since target = static-max - videoram, a guest started with
mem=maxmem doesn't really have them equal.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]