Xen 4.11.1: guest uses altp2m to crash host

Xen 4.11.1: guest uses altp2m to crash host

[Matt Leinhos]

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

Greetings,

I've found a way to crash a host from a misbehaving guest, using altp2m.
This is on a recent Intel core i7 chip. I've crashed two systems running
4.11.1. This behavior is not exhibited on 4.12, and since altp2m is a tech
preview in 4.11.1, this is not covered by security support. However, I
believe that the divergence between software and hardware state, as
mentioned below, is still present in 4.12.

On Xen 4.11.1 with altp2m enabled, follow these steps in the guest, whose
config file includes `altp2m = "mixed":
1. Allocate page P (GFN G)
2. Enable altp2m
3. Enable #VE notification, setting to G
4. Disable altp2m
5. Enable altp2m
6. Enable #VE notification, setting to G

At this point the entire system is unresponsive; #6 does not return control
to the guest. Note that step 3 is required, thus indicating some incomplete
cleanup after 4 that leads to a crash at 6. I've noticed a problem in the
Xen source at step 4, where the software and hardware states diverge. See
below for my notes on pertinent code.

I hope this is helpful and would appreciate it if you could fill me in on
why the entire host goes down - I suspect Xen is interacting with the VMCS
incorrectly, but I don't know the details and would like to understand.

1. Allocate page P (GFN G)

2. HVMOP_altp2m_set_domain_state(true)
    set d->arch.altp2m_active = true
    if first time:
       p2m_init_altp2m_by_id()
    for each vcpu V:
       altp2m_vcpu_initialise(V)
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)

3. HVMOP_altp2m_vcpu_enable_notify(G)
     checks: only toggling between INVALID_GFN and another value is
permitted
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

4. HVMOP_altp2m_set_domain_state(false)
     set d->arch.altp2m_active = false
     for each vcpu V:
        altp2m_vcpu_destroy()
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)
              ****** Does not update VMCS because altp2m_active() evals to
false *****

Now the software (Xen) thinks altp2m is disabled, but the hardware has
these features registered/enabled:
   VM_FUNCTION_CONTROL
   EPTP_LIST_ADDR
   VIRT_EXCEPTION_INFO

5. HVMOP_altp2m_set_domain_state(true)
      see above

6. HVMOP_altp2m_vcpu_enable_notify(not INVALID_GFN):
     checks: only toggling between INVALID_GFN and another value is
permitted
       -succeeds because reset() was called above
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

I claim that something in step 6 causes an unhandled exception. Please note
that the guest does not register a #VE ISR.

Kind regards,
Matt Leinhos

[-- Attachment #1.2: Type: text/html, Size: 3354 bytes --]

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

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

[Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Matt Leinhos]

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

Greetings,

I've found a way to crash a host from a misbehaving guest, using altp2m.
This is on a recent Intel core i7 chip. I've crashed two systems running
4.11.1. This behavior is not exhibited on 4.12, and since altp2m is a tech
preview in 4.11.1, this is not covered by security support. However, I
believe that the divergence between software and hardware state, as
mentioned below, is still present in 4.12.

On Xen 4.11.1 with altp2m enabled, follow these steps in the guest, whose
config file includes `altp2m = "mixed":
1. Allocate page P (GFN G)
2. Enable altp2m
3. Enable #VE notification, setting to G
4. Disable altp2m
5. Enable altp2m
6. Enable #VE notification, setting to G

At this point the entire system is unresponsive; #6 does not return control
to the guest. Note that step 3 is required, thus indicating some incomplete
cleanup after 4 that leads to a crash at 6. I've noticed a problem in the
Xen source at step 4, where the software and hardware states diverge. See
below for my notes on pertinent code.

I hope this is helpful and would appreciate it if you could fill me in on
why the entire host goes down - I suspect Xen is interacting with the VMCS
incorrectly, but I don't know the details and would like to understand.

1. Allocate page P (GFN G)

2. HVMOP_altp2m_set_domain_state(true)
    set d->arch.altp2m_active = true
    if first time:
       p2m_init_altp2m_by_id()
    for each vcpu V:
       altp2m_vcpu_initialise(V)
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)

3. HVMOP_altp2m_vcpu_enable_notify(G)
     checks: only toggling between INVALID_GFN and another value is
permitted
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

4. HVMOP_altp2m_set_domain_state(false)
     set d->arch.altp2m_active = false
     for each vcpu V:
        altp2m_vcpu_destroy()
          reset (av->p2midx = INVALID_ALTP2M,
                 av->veinfo_gfn = INVALID_GFN)
          altp2m_vcpu_update_p2m(V)
              ****** Does not update VMCS because altp2m_active() evals to
false *****

Now the software (Xen) thinks altp2m is disabled, but the hardware has
these features registered/enabled:
   VM_FUNCTION_CONTROL
   EPTP_LIST_ADDR
   VIRT_EXCEPTION_INFO

5. HVMOP_altp2m_set_domain_state(true)
      see above

6. HVMOP_altp2m_vcpu_enable_notify(not INVALID_GFN):
     checks: only toggling between INVALID_GFN and another value is
permitted
       -succeeds because reset() was called above
     set vcpu_altp2m(curr).veinfo_gfn = G
     altp2m_vcpu_update_vmfunc_ve()

I claim that something in step 6 causes an unhandled exception. Please note
that the guest does not register a #VE ISR.

Kind regards,
Matt Leinhos

[-- Attachment #1.2: Type: text/html, Size: 3354 bytes --]

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

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

Hello Matt,

Judging by the description of your problem, I believe that it has 
already been fixed by this commit:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec

Could you please either try to reproduce the problem with 4.12 or apply 
this patch to 4.11 and confirm?


Thanks,
Razvan

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

Hello Matt,

Judging by the description of your problem, I believe that it has 
already been fixed by this commit:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec

Could you please either try to reproduce the problem with 4.12 or apply 
this patch to 4.11 and confirm?


Thanks,
Razvan

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Matt Leinhos]

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

Hi Razvan,

You are correct -- cherry picking that commit into RELEASE-4.11.1 addresses
the crash. The problem cannot be reproduced on 4.12.

I hope this helps.

Kind regards,
Matt


On Mon, Apr 15, 2019 at 8:43 AM Razvan Cojocaru <rcojocaru@bitdefender.com>
wrote:

> Hello Matt,
>
> Judging by the description of your problem, I believe that it has
> already been fixed by this commit:
>
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>
> Could you please either try to reproduce the problem with 4.12 or apply
> this patch to 4.11 and confirm?
>
>
> Thanks,
> Razvan
>

[-- Attachment #1.2: Type: text/html, Size: 1292 bytes --]

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

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Matt Leinhos]

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

Hi Razvan,

You are correct -- cherry picking that commit into RELEASE-4.11.1 addresses
the crash. The problem cannot be reproduced on 4.12.

I hope this helps.

Kind regards,
Matt


On Mon, Apr 15, 2019 at 8:43 AM Razvan Cojocaru <rcojocaru@bitdefender.com>
wrote:

> Hello Matt,
>
> Judging by the description of your problem, I believe that it has
> already been fixed by this commit:
>
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>
> Could you please either try to reproduce the problem with 4.12 or apply
> this patch to 4.11 and confirm?
>
>
> Thanks,
> Razvan
>

[-- Attachment #1.2: Type: text/html, Size: 1292 bytes --]

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

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

On 4/15/19 5:04 PM, Matt Leinhos wrote:
> You are correct -- cherry picking that commit into RELEASE-4.11.1 
> addresses the crash. The problem cannot be reproduced on 4.12.
> 
> I hope this helps.

Thank you for confirming the fix!

To the deciders: would it be reasonable to ask patches like this to be 
backported to the future 4.11 release?


Thanks,
Razvan

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

On 4/15/19 5:04 PM, Matt Leinhos wrote:
> You are correct -- cherry picking that commit into RELEASE-4.11.1 
> addresses the crash. The problem cannot be reproduced on 4.12.
> 
> I hope this helps.

Thank you for confirming the fix!

To the deciders: would it be reasonable to ask patches like this to be 
backported to the future 4.11 release?


Thanks,
Razvan

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Jan Beulich]

>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>> addresses the crash. The problem cannot be reproduced on 4.12.
>> 
>> I hope this helps.
> 
> Thank you for confirming the fix!
> 
> To the deciders: would it be reasonable to ask patches like this to be 
> backported to the future 4.11 release?

Well, first of all you can always send a request. And yes, in general
I'd consider this reasonable, but I say so without having looked at
the actual commit(s) in question.

Jan



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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Jan Beulich]

>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>> addresses the crash. The problem cannot be reproduced on 4.12.
>> 
>> I hope this helps.
> 
> Thank you for confirming the fix!
> 
> To the deciders: would it be reasonable to ask patches like this to be 
> backported to the future 4.11 release?

Well, first of all you can always send a request. And yes, in general
I'd consider this reasonable, but I say so without having looked at
the actual commit(s) in question.

Jan



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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>
>>> I hope this helps.
>>
>> Thank you for confirming the fix!
>>
>> To the deciders: would it be reasonable to ask patches like this to be 
>> backported to the future 4.11 release?
> 
> Well, first of all you can always send a request. And yes, in general
> I'd consider this reasonable, but I say so without having looked at
> the actual commit(s) in question.

Thank you for the answer. This is the commit in question:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec

AFAICT there's nothing controversial about it, and it should easily
apply to 4.11, so if possible I propose that we consider backporting it
to the next 4.11 release.


Thanks,
Razvan

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Razvan Cojocaru]

On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>
>>> I hope this helps.
>>
>> Thank you for confirming the fix!
>>
>> To the deciders: would it be reasonable to ask patches like this to be 
>> backported to the future 4.11 release?
> 
> Well, first of all you can always send a request. And yes, in general
> I'd consider this reasonable, but I say so without having looked at
> the actual commit(s) in question.

Thank you for the answer. This is the commit in question:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec

AFAICT there's nothing controversial about it, and it should easily
apply to 4.11, so if possible I propose that we consider backporting it
to the next 4.11 release.


Thanks,
Razvan

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Andrew Cooper]

On 25/04/2019 13:17, Razvan Cojocaru wrote:
> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>
>>>> I hope this helps.
>>> Thank you for confirming the fix!
>>>
>>> To the deciders: would it be reasonable to ask patches like this to be 
>>> backported to the future 4.11 release?
>> Well, first of all you can always send a request. And yes, in general
>> I'd consider this reasonable, but I say so without having looked at
>> the actual commit(s) in question.
> Thank you for the answer. This is the commit in question:
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>
> AFAICT there's nothing controversial about it, and it should easily
> apply to 4.11, so if possible I propose that we consider backporting it
> to the next 4.11 release.

I have a rather large number of altp2m backports to Xen 4.11 in the
XenServer patchqueue, which in practice

It would certainly make my life easier if they were to go upstream.  I
can put together a branch if that would be helpful.

~Andrew

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Andrew Cooper]

On 25/04/2019 13:17, Razvan Cojocaru wrote:
> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>
>>>> I hope this helps.
>>> Thank you for confirming the fix!
>>>
>>> To the deciders: would it be reasonable to ask patches like this to be 
>>> backported to the future 4.11 release?
>> Well, first of all you can always send a request. And yes, in general
>> I'd consider this reasonable, but I say so without having looked at
>> the actual commit(s) in question.
> Thank you for the answer. This is the commit in question:
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa709b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>
> AFAICT there's nothing controversial about it, and it should easily
> apply to 4.11, so if possible I propose that we consider backporting it
> to the next 4.11 release.

I have a rather large number of altp2m backports to Xen 4.11 in the
XenServer patchqueue, which in practice

It would certainly make my life easier if they were to go upstream.  I
can put together a branch if that would be helpful.

~Andrew

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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Jan Beulich]

>>> On 25.04.19 at 14:53, <andrew.cooper3@citrix.com> wrote:
> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>>
>>>>> I hope this helps.
>>>> Thank you for confirming the fix!
>>>>
>>>> To the deciders: would it be reasonable to ask patches like this to be 
>>>> backported to the future 4.11 release?
>>> Well, first of all you can always send a request. And yes, in general
>>> I'd consider this reasonable, but I say so without having looked at
>>> the actual commit(s) in question.
>> Thank you for the answer. This is the commit in question:
>>
>> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa7 
> 09b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>>
>> AFAICT there's nothing controversial about it, and it should easily
>> apply to 4.11, so if possible I propose that we consider backporting it
>> to the next 4.11 release.
> 
> I have a rather large number of altp2m backports to Xen 4.11 in the
> XenServer patchqueue, which in practice

... ???

> It would certainly make my life easier if they were to go upstream.  I
> can put together a branch if that would be helpful.

What volume / count are we talking about? Anyway, if it's really
mostly altp2m code that gets touched, I don't mind, and having a
branch to pull from would be helpful. 4.11.2 is going to be delayed
anyway at least until the master branch advances again, as I've
meanwhile queued up quite a few bug fixes which all sit behind the
push gate there.

Jan



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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Jan Beulich]

>>> On 25.04.19 at 14:53, <andrew.cooper3@citrix.com> wrote:
> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>>
>>>>> I hope this helps.
>>>> Thank you for confirming the fix!
>>>>
>>>> To the deciders: would it be reasonable to ask patches like this to be 
>>>> backported to the future 4.11 release?
>>> Well, first of all you can always send a request. And yes, in general
>>> I'd consider this reasonable, but I say so without having looked at
>>> the actual commit(s) in question.
>> Thank you for the answer. This is the commit in question:
>>
>> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa7 
> 09b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>>
>> AFAICT there's nothing controversial about it, and it should easily
>> apply to 4.11, so if possible I propose that we consider backporting it
>> to the next 4.11 release.
> 
> I have a rather large number of altp2m backports to Xen 4.11 in the
> XenServer patchqueue, which in practice

... ???

> It would certainly make my life easier if they were to go upstream.  I
> can put together a branch if that would be helpful.

What volume / count are we talking about? Anyway, if it's really
mostly altp2m code that gets touched, I don't mind, and having a
branch to pull from would be helpful. 4.11.2 is going to be delayed
anyway at least until the master branch advances again, as I've
meanwhile queued up quite a few bug fixes which all sit behind the
push gate there.

Jan



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

Re: Xen 4.11.1: guest uses altp2m to crash host

[Andrew Cooper]

On 25/04/2019 13:58, Jan Beulich wrote:
>>>> On 25.04.19 at 14:53, <andrew.cooper3@citrix.com> wrote:
>> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>>>
>>>>>> I hope this helps.
>>>>> Thank you for confirming the fix!
>>>>>
>>>>> To the deciders: would it be reasonable to ask patches like this to be 
>>>>> backported to the future 4.11 release?
>>>> Well, first of all you can always send a request. And yes, in general
>>>> I'd consider this reasonable, but I say so without having looked at
>>>> the actual commit(s) in question.
>>> Thank you for the answer. This is the commit in question:
>>>
>>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa7 
>> 09b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>>> AFAICT there's nothing controversial about it, and it should easily
>>> apply to 4.11, so if possible I propose that we consider backporting it
>>> to the next 4.11 release.
>> I have a rather large number of altp2m backports to Xen 4.11 in the
>> XenServer patchqueue, which in practice
> ... ???

Oops sorry "in practice brings it in line with Xen 4.12."

>
>> It would certainly make my life easier if they were to go upstream.  I
>> can put together a branch if that would be helpful.
> What volume / count are we talking about? Anyway, if it's really
> mostly altp2m code that gets touched, I don't mind, and having a
> branch to pull from would be helpful.

Looks like 20 fixes or so.

> 4.11.2 is going to be delayed
> anyway at least until the master branch advances again, as I've
> meanwhile queued up quite a few bug fixes which all sit behind the
> push gate there.

Looking through the patchqueue, there are also some other fixes which
definitely qualify.  Given the current blockages, I'll wait until things
are open and flowing again, and highlight any further fixes.

~Andrew

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

Re: [Xen-devel] Xen 4.11.1: guest uses altp2m to crash host

[Andrew Cooper]

On 25/04/2019 13:58, Jan Beulich wrote:
>>>> On 25.04.19 at 14:53, <andrew.cooper3@citrix.com> wrote:
>> On 25/04/2019 13:17, Razvan Cojocaru wrote:
>>> On 4/25/19 1:04 PM, Jan Beulich wrote:
>>>>>>> On 15.04.19 at 16:10, <rcojocaru@bitdefender.com> wrote:
>>>>> On 4/15/19 5:04 PM, Matt Leinhos wrote:
>>>>>> You are correct -- cherry picking that commit into RELEASE-4.11.1 
>>>>>> addresses the crash. The problem cannot be reproduced on 4.12.
>>>>>>
>>>>>> I hope this helps.
>>>>> Thank you for confirming the fix!
>>>>>
>>>>> To the deciders: would it be reasonable to ask patches like this to be 
>>>>> backported to the future 4.11 release?
>>>> Well, first of all you can always send a request. And yes, in general
>>>> I'd consider this reasonable, but I say so without having looked at
>>>> the actual commit(s) in question.
>>> Thank you for the answer. This is the commit in question:
>>>
>>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1dddfff4c39d3db17dfa7 
>> 09b1c57f44e3ed352e3;hp=68465944c81fa2fbc40bf29ec6084072af5e48ec
>>> AFAICT there's nothing controversial about it, and it should easily
>>> apply to 4.11, so if possible I propose that we consider backporting it
>>> to the next 4.11 release.
>> I have a rather large number of altp2m backports to Xen 4.11 in the
>> XenServer patchqueue, which in practice
> ... ???

Oops sorry "in practice brings it in line with Xen 4.12."

>
>> It would certainly make my life easier if they were to go upstream.  I
>> can put together a branch if that would be helpful.
> What volume / count are we talking about? Anyway, if it's really
> mostly altp2m code that gets touched, I don't mind, and having a
> branch to pull from would be helpful.

Looks like 20 fixes or so.

> 4.11.2 is going to be delayed
> anyway at least until the master branch advances again, as I've
> meanwhile queued up quite a few bug fixes which all sit behind the
> push gate there.

Looking through the patchqueue, there are also some other fixes which
definitely qualify.  Given the current blockages, I'll wait until things
are open and flowing again, and highlight any further fixes.

~Andrew

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