preparations for 4.14.5 ?

preparations for 4.14.5 ?

[Jan Beulich]

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.

Jan

Re: preparations for 4.14.5 ?

[Marek Marczykowski-Górecki]

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

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.

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

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

Re: preparations for 4.14.5 ?

[Jan Beulich]

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.

Jan

Re: preparations for 4.14.5 ?

[Marek Marczykowski-Górecki]

[-- 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 --]

Re: preparations for 4.14.5 ?

[Anthony PERARD]

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:
> > 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.

The patch might be good to backport. I guess that could mess up memory
hotplug a little with PVH guests without the patch.

I've got a few others commits which would be good to backport I think:

e45ad0b1b0 ("xl: Fix global pci options")
d2ecf97f91 ("libxl: Don't segfault on soft-reset failure")
d62a34423a ("libxl: Re-scope qmp_proxy_spawn.ao usage")

Thanks,

-- 
Anthony PERARD