On 25.09.2023 08:40, Henry Wang wrote:
> Hi Jan,
>
>> On Sep 25, 2023, at 14:32, Jan Beulich wrote:
>>
>> On 25.09.2023 03:25, Henry Wang wrote:
>>> Hi everyone,
>>>
>>> This is the reminder that we are currently in code freeze. The hard code
>>> freeze date will be in two weeks, i.e. Fri Oct 6,
Hi,
> On Sep 22, 2023, at 06:30, Stefano Stabellini wrote:
>
> On Thu, 21 Sep 2023, Federico Serafini wrote:
>> Make object declarations consistent. No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry Wang
Kind regards,
Hi,
> On Sep 22, 2023, at 06:33, Stefano Stabellini wrote:
>
> On Thu, 21 Sep 2023, Federico Serafini wrote:
>> Make function declarations and definitions consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry
Hi,
> On Sep 25, 2023, at 14:38, Jan Beulich wrote:
>
> On 22.09.2023 17:19, Federico Serafini wrote:
>>
>> -
>> -/* the intercept action for PIT DM retval:0--not handled; 1--handled */
>> +/* the intercept action for PIT DM retval:0--not handled; 1--handled */
>
> If you already touch this
Hi Jan,
> On Sep 25, 2023, at 15:14, Jan Beulich wrote:
>
> On 25.09.2023 08:40, Henry Wang wrote:
>> Hi Jan,
>>
>>> On Sep 25, 2023, at 14:32, Jan Beulich wrote:
>>>
>>> On 25.09.2023 03:25, Henry Wang wrote:
Hi everyone,
This is the reminder that we are currently in code fre
On 25.09.2023 03:25, Henry Wang wrote:
> Hi everyone,
>
> This is the reminder that we are currently in code freeze. The hard code
> freeze date will be in two weeks, i.e. Fri Oct 6, 2023.
>
> The planned date for 4.18 rc1 is this Friday, i.e. Sep 29, 2023.
>
> Also, below is the (updated) criti
Hi Jan,
> On Sep 25, 2023, at 15:24, Jan Beulich wrote:
>
> On 25.09.2023 03:25, Henry Wang wrote:
>> Hi everyone,
>>
>> This is the reminder that we are currently in code freeze. The hard code
>> freeze date will be in two weeks, i.e. Fri Oct 6, 2023.
>>
>> The planned date for 4.18 rc1 is th
On 22.09.2023 18:11, Andrew Cooper wrote:
> On 18/09/2023 12:37 pm, Jan Beulich wrote:
>> On 15.09.2023 22:36, Andrew Cooper wrote:
>>> The current logic used to update %dr6 when injecting #DB is buggy.
>>>
>>> The SDM/APM documention on %dr6 updates is far from ideal, but does at least
>>> make cl
Hi Jan,
> On Sep 12, 2023, at 08:48, Henry Wang wrote:
>
> Hi Jan,
>
>> On Sep 11, 2023, at 23:01, Jan Beulich wrote:
>>
>> [1] specifies a long list of instructions which are intended to exhibit
>> timing behavior independent of the data they operate on. On certain
>> hardware this independe
flight 183151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183151/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 43dcf453fc15ca152945ca41dcce7f2f43a14313
baseline version:
ovmf 8b2e6b90b85fd4b1f7f92
The declarations for 'vesa_{init,early_init,endboot}' needed by
'xen/drivers/video/vesa.c' and 'fill_console_start_info' in 'vga.c'
are now available by moving the relative code inside 'vga.h'.
While moving the code, the alternative definitions are now guarded by
CONFIG_VGA. The alternative #defin
Hi Henry,
On 25/09/2023 07:40, Henry Wang wrote:
On Sep 25, 2023, at 14:32, Jan Beulich wrote:
On 25.09.2023 03:25, Henry Wang wrote:
Hi everyone,
This is the reminder that we are currently in code freeze. The hard code
freeze date will be in two weeks, i.e. Fri Oct 6, 2023.
Could you furt
On Mon, Sep 25, 2023 at 08:36:03AM +0200, Jan Beulich wrote:
> On 22.09.2023 22:03, Andrew Cooper wrote:
> > On 08/08/2023 2:02 pm, Alejandro Vallejo wrote:
> >> --- a/xen/common/Kconfig
> >> +++ b/xen/common/Kconfig
> >> @@ -23,6 +23,16 @@ config GRANT_TABLE
> >>
> >> If unsure, say Y.
> >>
On 19.09.2023 13:06, Roger Pau Monne wrote:
> Sporadically we have seen the following during AP bringup on AMD platforms
> only:
>
> microcode: CPU59 updated from revision 0x830107a to 0x830107a, date =
> 2023-05-17
> microcode: CPU60 updated from revision 0x830104d to 0x830107a, date =
> 2023-0
On 25.09.2023 11:46, Roger Pau Monné wrote:
> On Mon, Sep 25, 2023 at 08:36:03AM +0200, Jan Beulich wrote:
>> On 22.09.2023 22:03, Andrew Cooper wrote:
>>> On 08/08/2023 2:02 pm, Alejandro Vallejo wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -23,6 +23,16 @@ config GRAN
On 25/09/2023 10:46 am, Roger Pau Monné wrote:
> On Mon, Sep 25, 2023 at 08:36:03AM +0200, Jan Beulich wrote:
>> On 22.09.2023 22:03, Andrew Cooper wrote:
>>> On 08/08/2023 2:02 pm, Alejandro Vallejo wrote:
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -23,6 +23,16 @@ config G
On Mon, Sep 25, 2023 at 10:35 AM Julien Grall wrote:
>
> Hi Henry,
>
> On 25/09/2023 07:40, Henry Wang wrote:
> >> On Sep 25, 2023, at 14:32, Jan Beulich wrote:
> >>
> >> On 25.09.2023 03:25, Henry Wang wrote:
> >>> Hi everyone,
> >>>
> >>> This is the reminder that we are currently in code freez
On 25.09.2023 12:01, Andrew Cooper wrote:
> On 25/09/2023 10:46 am, Roger Pau Monné wrote:
>> On Mon, Sep 25, 2023 at 08:36:03AM +0200, Jan Beulich wrote:
>>> On 22.09.2023 22:03, Andrew Cooper wrote:
On 08/08/2023 2:02 pm, Alejandro Vallejo wrote:
> --- a/xen/common/Kconfig
> +++ b/xe
On 9/25/23 16:30, Jan Beulich wrote:
> On 22.09.2023 18:11, Andrew Cooper wrote:
>> On 18/09/2023 12:37 pm, Jan Beulich wrote:
>>> On 15.09.2023 22:36, Andrew Cooper wrote:
The current logic used to update %dr6 when injecting #DB is buggy.
The SDM/APM documention on %dr6 updates is f
On Mon, Sep 25, 2023 at 11:55:25AM +0200, Jan Beulich wrote:
> On 19.09.2023 13:06, Roger Pau Monne wrote:
> > Sporadically we have seen the following during AP bringup on AMD platforms
> > only:
> >
> > microcode: CPU59 updated from revision 0x830107a to 0x830107a, date =
> > 2023-05-17
> > micr
flight 183155 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183155/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c70d91442889078eb94e0abf777f74e403b72d37
baseline version:
ovmf 43dcf453fc15ca152945c
On 25/09/2023 10:11 am, Nicola Vetrini wrote:
> diff --git a/xen/include/xen/vga.h b/xen/include/xen/vga.h
> index f72b63d446b1..9b2c47971d0c 100644
> --- a/xen/include/xen/vga.h
> +++ b/xen/include/xen/vga.h
> @@ -13,6 +13,12 @@
>
> #ifdef CONFIG_VGA
> extern struct xen_vga_console_info vga_co
Hi Julien,
> On Sep 25, 2023, at 17:34, Julien Grall wrote:
>
> Hi Henry,
>
> On 25/09/2023 07:40, Henry Wang wrote:
>>
>>> This, for example, would then likely mean
>>> that all Misra work now needs queuing for after the tree re-opens ...
>> …I also thought about this, to be honest I am tempt
Hi George,
> On Sep 25, 2023, at 18:07, George Dunlap wrote:
>
> On Mon, Sep 25, 2023 at 10:35 AM Julien Grall wrote:
>>
>> Hi Henry,
>>
>> On 25/09/2023 07:40, Henry Wang wrote:
On Sep 25, 2023, at 14:32, Jan Beulich wrote:
This, for example, would then likely mean
that all M
Hi Andrew,
> On Sep 25, 2023, at 18:53, andrew.coop...@citrix.com wrote:
>
> On 25/09/2023 10:11 am, Nicola Vetrini wrote:
>> diff --git a/xen/include/xen/vga.h b/xen/include/xen/vga.h
>> index f72b63d446b1..9b2c47971d0c 100644
>> --- a/xen/include/xen/vga.h
>> +++ b/xen/include/xen/vga.h
>> @@ -
Hello,
I've encountered a strange behavior with Xen on arm64 with regards to
suspend/resume.
My setup:
Version: Xen 4.13.1
Target: NXP imx8x SoC
We also use a set of patches from Aggios
(https://xen-devel.narkive.com/yGps0HKG/rfc-v2-xen-arm-suspend-to-ram-support-in-xen-for-arm)
Occasionally
flight 183156 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183156/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 183149 linux-5.4 real [real]
flight 183157 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183149/
http://logs.test-lab.xenproject.org/osstest/logs/183157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On 25.09.2023 12:42, Roger Pau Monné wrote:
> On Mon, Sep 25, 2023 at 11:55:25AM +0200, Jan Beulich wrote:
>> On 19.09.2023 13:06, Roger Pau Monne wrote:
>>> Sporadically we have seen the following during AP bringup on AMD platforms
>>> only:
>>>
>>> microcode: CPU59 updated from revision 0x830107a
flight 183150 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 183140
Tests which are fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-20588 / XSA-439
x86/AMD: Divide speculative information leak
ISSUE DESCRIPTION
=
In the Zen1 microarchitecure, there is one divider in the pipeline which
services uops from bo
On September 23, 2023 2:42:10 AM PDT, Xin Li wrote:
>Because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER and
>ERETU is the only legit instruction to return to ring 3, there is NO need
>to setup SYSCALL and SYSENTER MSRs for FRED, except the IA32_STAR MSR.
>
>Split IDT syscall set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-20588 / XSA-439
version 2
x86/AMD: Divide speculative information leak
UPDATES IN VERSION 2
Version 1 accidentally linked to the wrong AMD
On 9/22/23 3:03 PM, Andrew Cooper wrote:
> Several things.
>
> First, Shawn: PPC has gained a HAS_PDX, the deletion of which needs
> merging into this patch.
>
> It was added as part of 4a2f68f909304 which was "minimal to build".
> This series address the issue you presumably encountered where p
> >diff --git a/arch/x86/kernel/cpu/common.c
> >b/arch/x86/kernel/cpu/common.c index 20bbedbf6dcb..2ee4e7b597a3 100644
> >--- a/arch/x86/kernel/cpu/common.c
> >+++ b/arch/x86/kernel/cpu/common.c
> >@@ -2071,10 +2071,8 @@ static void wrmsrl_cstar(unsigned long val)
> > wrmsrl(MSR_CSTAR,
On 9/19/23 5:21 AM, Jan Beulich wrote:
> On 19.09.2023 11:53, GitLab wrote:
>>
>>
>> Pipeline #1009404353 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/xen )
>> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>>
>> Commit: ea36ac0d (
>> https://gitlab.com
Hi,
(Adding [for-4.18] in the title for Henry to spot the request)
On 22/09/2023 23:27, Volodymyr Babchuk wrote:
ITS manages Device Tables and Interrupt Translation Tables on its own,
so generally we are not interested in maintaining any coherence with
CPU's view of those memory regions, except
On September 25, 2023 10:56:44 AM PDT, "Li, Xin3" wrote:
>> >diff --git a/arch/x86/kernel/cpu/common.c
>> >b/arch/x86/kernel/cpu/common.c index 20bbedbf6dcb..2ee4e7b597a3 100644
>> >--- a/arch/x86/kernel/cpu/common.c
>> >+++ b/arch/x86/kernel/cpu/common.c
>> >@@ -2071,10 +2071,8 @@ static void wrm
Hi Henry,
I haven't checked that the code movement is just a code movement. For
now, I am mainly looking at the split.
On 28/08/2023 02:32, Henry Wang wrote:
The extraction of MMU related code is the basis of MPU support.
This commit starts this work by firstly splitting the page table
relate
Hi Julien, Henry,
Julien Grall writes:
> Hi,
>
> (Adding [for-4.18] in the title for Henry to spot the request)
>
> On 22/09/2023 23:27, Volodymyr Babchuk wrote:
>> ITS manages Device Tables and Interrupt Translation Tables on its own,
>> so generally we are not interested in maintaining any c
Hi Henry,
On 28/08/2023 02:32, Henry Wang wrote:
Move the code related to secondary page table initialization, clear
boot page tables and the global variable definitions of these boot
page tables from arch/arm/mm.c to arch/arm/mmu/smpboot.c
Drop the "static" attribute of arm32 global variable c
On 25/09/2023 20:00, Volodymyr Babchuk wrote:
Hi Julien, Henry,
Julien Grall writes:
Hi,
(Adding [for-4.18] in the title for Henry to spot the request)
On 22/09/2023 23:27, Volodymyr Babchuk wrote:
ITS manages Device Tables and Interrupt Translation Tables on its own,
so generally we a
flight 183159 linux-5.4 real [real]
flight 183165 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183159/
http://logs.test-lab.xenproject.org/osstest/logs/183165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On Mon, 25 Sep 2023, Henry Wang wrote:
> > On Sep 25, 2023, at 18:07, George Dunlap wrote:
> > On Mon, Sep 25, 2023 at 10:35 AM Julien Grall wrote:
> >> On 25/09/2023 07:40, Henry Wang wrote:
> On Sep 25, 2023, at 14:32, Jan Beulich wrote:
> This, for example, would then likely mean
>
On 9/22/23 04:44, Roger Pau Monné wrote:
> On Tue, Aug 29, 2023 at 11:19:47PM +, Volodymyr Babchuk wrote:
>> From: Stewart Hildebrand
>>
>> Skip mapping the BAR if it is not in a valid range.
>>
>> Signed-off-by: Stewart Hildebrand
>> ---
>> xen/drivers/vpci/header.c | 9 +
>> 1 file
Hi Julien,
> On Sep 26, 2023, at 02:33, Julien Grall wrote:
>
> Hi,
>
> (Adding [for-4.18] in the title for Henry to spot the request)
Thanks!
>
> On 22/09/2023 23:27, Volodymyr Babchuk wrote:
>> ITS manages Device Tables and Interrupt Translation Tables on its own,
>> so generally we are no
Hi Stefano,
> On Sep 26, 2023, at 05:05, Stefano Stabellini wrote:
>
> On Mon, 25 Sep 2023, Henry Wang wrote:
>>> On Sep 25, 2023, at 18:07, George Dunlap wrote:
>>> On Mon, Sep 25, 2023 at 10:35 AM Julien Grall wrote:
On 25/09/2023 07:40, Henry Wang wrote:
>> On Sep 25, 2023, at 14:3
On 9/25/23 1:11 PM, Shawn Anastasio wrote:
> On 9/19/23 5:21 AM, Jan Beulich wrote:
>> These two, otoh, look to be a result of the tests pre-seeding xen/.config
>> with
>> CONFIG_DEBUG settings, followed by making the olddefconfig goal. That, aiui,
>> isn't picking up xen/arch/*/configs/*_defconfi
When building for Power with CONFIG_DEBUG unset, a compiler error gets
raised inside page_alloc.c's node_to_scrub function, likely due to the
increased optimization level:
common/page_alloc.c: In function 'node_to_scrub.part.0':
common/page_alloc.c:1217:29: error: array subscript 1 is above array
Change automation build script to call the make defconfig target before
setting CONFIG_DEBUG and extra options. This fixes issues on Power where
the build fails without using the ppc64_defconfig.
Signed-off-by: Shawn Anastasio
Reported-by: Jan Beulich
---
automation/scripts/build | 7 ++-
1
Since ppc64le is still undergoing early bringup, disable the randconfig
CI build which was causing spurious CI failures.
Signed-off-by: Shawn Anastasio
Reported-by: Jan Beulich
---
automation/gitlab-ci/build.yaml | 18 --
1 file changed, 18 deletions(-)
diff --git a/automation/
Hello all,
This series contains a few minor fixes to the CI config and one
additional patch to common/ that resolve ppc64-specific CI failures
that Jan discovered.
Thanks,
Shawn Anastasio (3):
automation: Drop ppc64le-*randconfig jobs
automation: Change build script to use arch defconfig
x
Hello Roger,
Roger Pau Monné writes:
> On Tue, Aug 29, 2023 at 11:19:42PM +, Volodymyr Babchuk wrote:
>> Add per-domain d->pci_lock that protects access to
>> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
>> that underlying pdev will not disappear under feet. This is
On Mon, 25 Sep 2023, Shawn Anastasio wrote:
> Since ppc64le is still undergoing early bringup, disable the randconfig
> CI build which was causing spurious CI failures.
>
> Signed-off-by: Shawn Anastasio
> Reported-by: Jan Beulich
Acked-by: Stefano Stabellini
> ---
> automation/gitlab-ci/bu
Hi Roger,
Roger Pau Monné writes:
> On Tue, Aug 29, 2023 at 11:19:42PM +, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>>
>> Use a previously introduced per-domain read/write lock to check
>> whether vpci is present, so we are sure there are no accesses to the
>> contents of t
Adding Henry as this issue is currently causing gitlab-ci failures. I
think we should fix it as soon as possible to get clearer results for
the 4.18 release. (This comment applies to the rest of the series as
well).
On Mon, 25 Sep 2023, Shawn Anastasio wrote:
> When building for Power with CONFIG
On Mon, 25 Sep 2023, Shawn Anastasio wrote:
> Change automation build script to call the make defconfig target before
> setting CONFIG_DEBUG and extra options. This fixes issues on Power where
> the build fails without using the ppc64_defconfig.
>
> Signed-off-by: Shawn Anastasio
> Reported-by: J
flight 183161 xen-unstable real [real]
flight 183167 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183161/
http://logs.test-lab.xenproject.org/osstest/logs/183167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Hi Stefano,
> On Sep 26, 2023, at 07:04, Stefano Stabellini wrote:
>
> Adding Henry as this issue is currently causing gitlab-ci failures. I
> think we should fix it as soon as possible to get clearer results for
> the 4.18 release. (This comment applies to the rest of the series as
> well).
Th
Hi,
> On Sep 26, 2023, at 06:57, Stefano Stabellini wrote:
>
> On Mon, 25 Sep 2023, Shawn Anastasio wrote:
>> Since ppc64le is still undergoing early bringup, disable the randconfig
>> CI build which was causing spurious CI failures.
>>
>> Signed-off-by: Shawn Anastasio
>> Reported-by: Jan Beu
On 8/29/23 19:19, Volodymyr Babchuk wrote:
> From: Stewart Hildebrand
>
> Move iomem_caps initialization earlier (before arch_domain_create()).
>
> Signed-off-by: Stewart Hildebrand
> ---
> This is sort of a follow-up to:
>
> baa6ea700386 ("vpci: add permission checks to map_range()")
>
> I
Hi Julien,
> On Sep 26, 2023, at 02:57, Julien Grall wrote:
>
> Hi Henry,
>
> I haven't checked that the code movement is just a code movement. For now, I
> am mainly looking at the split.
No problem, thank you. I will rebase v6 and use text comparison tools
to check if the code movement is j
Hi Julien,
> On Sep 26, 2023, at 03:13, Julien Grall wrote:
>
> Hi Henry,
>
> On 28/08/2023 02:32, Henry Wang wrote:
>> Move the code related to secondary page table initialization, clear
>> boot page tables and the global variable definitions of these boot
>> page tables from arch/arm/mm.c to
flight 183166 linux-5.4 real [real]
flight 183171 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183166/
http://logs.test-lab.xenproject.org/osstest/logs/183171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
During the Linux kernel booting, an error is reported by the Xen
hypervisor:
(XEN) arch/arm/p2m.c:2202: d0v0: Failing to acquire the MFN 0x1a02dc
The kernel attempts to use an invalid memory frame number, which can be
converted to: 0x1a02dc << PAGE_SHIFT, resulting in 0x1_a02d_c000.
The invali
> >Yes, this is a noop, just a cleanup patch w/o functionality change.
> >
> It just seems to be completely redundant. We can just drop it, no? If we
> aren't going
> to explicitly clobber the registers there is no harm in setting them up for
> IDT
> unconditionally.
If no objection, I can make
66 matches
Mail list logo