Backports for Xen 4.6

Backports for Xen 4.6

[Andrew Cooper]

Hi,

Looking at the XenServer patch queue, I have a few nominations for
backports.

Hypervisor:
22a1fbb575df "x86/hvm: make sure stdvga cache cannot be re-enabled"
0747bc8b4d85 "x86/vmx: Fix injection of #DB traps following XSA-156"

Possibly also:
42940c046902 "x86/shadow: Fix missing newline in dprintk()"
6851e979874e "VT-d: use proper error codes in iommu_enable_x2apic_IR()"
0ce647ad6f70 "x86: suppress bogus log message"
484c14b7254e "x86/vmx: enable PML by default"

Toolstack:
82ff7cbed64e "oxenstored: Quota.merge: don't assume domain already exists"
8a2c11f876e6 "tools/ocaml/xb: Correct calculations of data/space the ring"

In particular, the advisory for XSA-156 needs re-issuing with c/s
0747bc8b4d85 folded in.

~Andrew

Re: Backports for Xen 4.6

[Ian Jackson]

Andrew Cooper writes ("Backports for Xen 4.6"):
> Toolstack:
> 82ff7cbed64e "oxenstored: Quota.merge: don't assume domain already exists"
> 8a2c11f876e6 "tools/ocaml/xb: Correct calculations of data/space the ring"

I have applied these to 4.6 and 4.5.

They didn't apply cleanly to 4.4.  If someone wants to check if
they're relevant and supply backport(s), I would apply them.

Thanks,
Ian.

Re: Backports for Xen 4.6

[Andrew Cooper]

On 19/01/16 13:43, Ian Jackson wrote:
> Andrew Cooper writes ("Backports for Xen 4.6"):
>> Toolstack:
>> 82ff7cbed64e "oxenstored: Quota.merge: don't assume domain already exists"
>> 8a2c11f876e6 "tools/ocaml/xb: Correct calculations of data/space the ring"
> I have applied these to 4.6 and 4.5.

Thanks.

~Andrew

Re: Backports for Xen 4.6

[Jan Beulich]

>>> On 18.01.16 at 16:53, <andrew.cooper3@citrix.com> wrote:
> Possibly also:
> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"

The affected statement compiles to nothing in a release build, which
can be taken as an argument both ways. I lean towards not putting
it in.

> 6851e979874e "VT-d: use proper error codes in iommu_enable_x2apic_IR()"

Since I had pulled this into our own tree already, and since you're
now also viewing this as useful, I guess I will throw it in.

> 0ce647ad6f70 "x86: suppress bogus log message"

This being a purely cosmetic change, may I ask for the reason
you consider this a backport candidate?

> 484c14b7254e "x86/vmx: enable PML by default"

Not in a point release I would say.

Jan

Re: Backports for Xen 4.6

[Andrew Cooper]

On 20/01/16 12:29, Jan Beulich wrote:
>>>> On 18.01.16 at 16:53, <andrew.cooper3@citrix.com> wrote:
>> Possibly also:
>> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"
> The affected statement compiles to nothing in a release build, which
> can be taken as an argument both ways. I lean towards not putting
> it in.
>
>> 6851e979874e "VT-d: use proper error codes in iommu_enable_x2apic_IR()"
> Since I had pulled this into our own tree already, and since you're
> now also viewing this as useful, I guess I will throw it in.
>
>> 0ce647ad6f70 "x86: suppress bogus log message"
> This being a purely cosmetic change, may I ask for the reason
> you consider this a backport candidate?

The shear volume reduction in debug builds.

XenServer ships both a release and a debug hypervisor for first-line
triage of customer issues.  As such, "only affecting a debug build"
isn't a relevant consideration for us, and I expect we are not alone here.

~Andrew

Re: Backports for Xen 4.6

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1228 bytes --]

On 1/20/16 7:14 AM, Andrew Cooper wrote:
> On 20/01/16 12:29, Jan Beulich wrote:
>>>>> On 18.01.16 at 16:53, <andrew.cooper3@citrix.com> wrote:
>>> Possibly also:
>>> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"
>> The affected statement compiles to nothing in a release build, which
>> can be taken as an argument both ways. I lean towards not putting
>> it in.
>>
>>> 6851e979874e "VT-d: use proper error codes in iommu_enable_x2apic_IR()"
>> Since I had pulled this into our own tree already, and since you're
>> now also viewing this as useful, I guess I will throw it in.
>>
>>> 0ce647ad6f70 "x86: suppress bogus log message"
>> This being a purely cosmetic change, may I ask for the reason
>> you consider this a backport candidate?
> 
> The shear volume reduction in debug builds.
> 
> XenServer ships both a release and a debug hypervisor for first-line
> triage of customer issues.  As such, "only affecting a debug build"
> isn't a relevant consideration for us, and I expect we are not alone here.
> 
> ~Andrew
> 

I will likely locally backport this one myself if it doesn't land in
4.6.1 because we too have a debug variant and a release variant.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Backports for Xen 4.6

[Andrew Cooper]

On 18/01/16 15:53, Andrew Cooper wrote:
> Hi,
>
> Looking at the XenServer patch queue, I have a few nominations for
> backports.
>
> Hypervisor:
> 22a1fbb575df "x86/hvm: make sure stdvga cache cannot be re-enabled"

This patch appears to have been missed in the latest round of backports.

It causes guest console corruption when an HVM guest restarts its
graphics drivers.

~Andrew

Re: Backports for Xen 4.6

[Jan Beulich]

>>> On 20.01.16 at 19:32, <andrew.cooper3@citrix.com> wrote:
> On 18/01/16 15:53, Andrew Cooper wrote:
>> Looking at the XenServer patch queue, I have a few nominations for
>> backports.
>>
>> Hypervisor:
>> 22a1fbb575df "x86/hvm: make sure stdvga cache cannot be re-enabled"
> 
> This patch appears to have been missed in the latest round of backports.
> 
> It causes guest console corruption when an HVM guest restarts its
> graphics drivers.

Oops - I had pulled it into my queue, but with the queue ordered by
time I then overlooked it when committing the pieces. Will do together
with the vPMU ones requested by Boris.

Jan