[Xen-devel] getting 4.11.3 ready

[Xen-devel] getting 4.11.3 ready

[Jan Beulich]

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()

Jan

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

Re: [Xen-devel] getting 4.11.3 ready

[Julien Grall]

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()

@Stefano: Are you still taking care of backport for Arm?

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01309.html


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

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

Re: [Xen-devel] getting 4.11.3 ready

[Stefano Stabellini]

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()

I have e04818b46d, plus the following marked for backport:

e98edccb944a80db782e551f3090628e66c7fb52 xen/arm: SCTLR_EL1 is a 64-bit register on Arm64

I backported them both.

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

Re: [Xen-devel] getting 4.11.3 ready

[Julien Grall]

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

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] getting 4.11.3 ready

[Jan Beulich]

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?

Thanks, Jan

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

Re: [Xen-devel] getting 4.11.3 ready

[Julien Grall]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] getting 4.11.3 ready

[Jan Beulich]

On 29.10.2019 16:06, Julien Grall wrote:
> On 29/10/2019 14:49, Jan Beulich wrote:
>> 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.

Not that on my previous mail you were only Cc-ed, hence the
remark wasn't directed at you anyway. As to not being Cc-ed
on the original request - the Cc list there is generally just
the people involved in making the release. Everyone else
would get it via xen-devel. If I didn't do it that way, how
would I draw the boundary between whom to Cc and whom to omit?
(With your request on irc, as said there, I'll try to remember
Cc-ing you. If, as per above, you took over doing the
backports, I would, too. But in general that's what we have
a mailing list for.)

Jan

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

Re: [Xen-devel] getting 4.11.3 ready

[Stefano Stabellini]

On Tue, 29 Oct 2019, 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+]

They all make sense, I did the backports, building each commit
individually.

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

Re: [Xen-devel] getting 4.11.3 ready

[Lars Kurth]

On 29/10/2019, 12:41, "Stefano Stabellini" <sstabellini@kernel.org> wrote:

    On Tue, 29 Oct 2019, 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+]
    
    They all make sense, I did the backports, building each commit
    individually.
    
Jan, AFAICT this is not yet ready to run the XSA checking tools.
Let me know when you think I should run them
Lars

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

Re: [Xen-devel] getting 4.11.3 ready

[Jan Beulich]

On 28.11.2019 00:51, Lars Kurth wrote:
> On 29/10/2019, 12:41, "Stefano Stabellini" <sstabellini@kernel.org> wrote:
>     On Tue, 29 Oct 2019, 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+]
>     
>     They all make sense, I did the backports, building each commit
>     individually.
>     
> Jan, AFAICT this is not yet ready to run the XSA checking tools.
> Let me know when you think I should run them

I'm lost. Why would the tree not be ready? There are no further
backports supposed to arrive prior to the release. I was hoping
to do the release yesterday. Also the mail you've replied to is
about a month old.

Jan

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