This eases recognizing that something odd is going on.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -845,6 +845,9 @@ void fatal_trap(const struct cpu_user_re
msecs = 10;
}
}
+if ( pending )
+
flight 171600 linux-5.4 real [real]
flight 171612 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171600/
http://logs.test-lab.xenproject.org/osstest/logs/171612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On 12.07.2022 19:28, Julien Grall wrote:
> On 11/07/2022 17:08, Rahul Singh wrote:
>>> On 22 Jun 2022, at 3:51 pm, Julien Grall wrote:
>>> On 22/06/2022 15:37, Rahul Singh wrote:
evtchn_alloc_unbound() always allocates the next available port. Static
event channel support for dom0less do
On 13.07.2022 03:36, Chuck Zmudzinski wrote:
> v2: *Add force_pat_disabled variable to fix "nopat" on Xen PV (Jan Beulich)
> *Add the necessary code to incorporate the "nopat" fix
> *void init_cache_modes(void) -> void __init init_cache_modes(void)
> *Add Jan Beulich as Co-developer (Ja
On 12.07.2022 21:48, Chuck Zmudzinski wrote:
> I will also re-compile and test the new patch before sending
> v2 and unless Jan objects, I should acknowledge Jan as co-author
> of the patch since I will be using parts of his proposed patch
> to fix the "nopat" issue, so I also need to get his sign-
On Tue, Jul 12, 2022 at 03:57:45PM -0400, Chuck Zmudzinski wrote:
> On 7/12/22 3:26 PM, Greg KH wrote:
> > On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> > > On 7/12/22 2:36 PM, Greg KH wrote:
> > > > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > > > T
flight 171597 qemu-mainline real [real]
flight 171610 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171597/
http://logs.test-lab.xenproject.org/osstest/logs/171610/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 13.07.22 03:36, Chuck Zmudzinski wrote:
The commit 99c13b8c8896d7bcb92753bf
("x86/mm/pat: Don't report PAT on CPUs that don't support it")
incorrectly failed to account for the case in init_cache_modes() when
CPUs do support PAT and falsely reported PAT to be disabled when in
fact PAT is enabl
Hi Julien
Before submitting the v6 patch series, I would like to double confirm that ...
> -Original Message-
> From: Julien Grall
> Sent: Wednesday, June 29, 2022 6:18 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volo
The commit 99c13b8c8896d7bcb92753bf
("x86/mm/pat: Don't report PAT on CPUs that don't support it")
incorrectly failed to account for the case in init_cache_modes() when
CPUs do support PAT and falsely reported PAT to be disabled when in
fact PAT is enabled. In some environments, notably in Xen PV d
Registration is open! Virtual attendance is open to everyone; due to space
constraints, physical attendance will be priority-based: Those not on the
"priority list" will be put on a waiting list until 2 September, at which point
slots will be first-come-first-served.
https://events.linuxfoundat
flight 171594 xen-4.15-testing real [real]
flight 171607 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171594/
http://logs.test-lab.xenproject.org/osstest/logs/171607/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
> On 30 Jun 2022, at 22:18, Oleksandr wrote:
>
>
> Dear all.
>
>
> On 25.06.22 17:32, Oleksandr wrote:
>>
>> On 24.06.22 15:59, George Dunlap wrote:
>>
>> Hello George
>>
>>>
On 17 Jun 2022, at 17:14, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Thi
flight 171595 xen-4.16-testing real [real]
flight 171606 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171595/
http://logs.test-lab.xenproject.org/osstest/logs/171606/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 7/12/22 3:31 PM, Greg KH wrote:
On Tue, Jul 12, 2022 at 03:19:39PM -0400, Boris Ostrovsky wrote:
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't find starting inst
On 7/12/22 3:26 PM, Greg KH wrote:
> On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> > On 7/12/22 2:36 PM, Greg KH wrote:
> > > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > > The commit 99c13b8c8896d7bcb92753bf
> > > > ("x86/mm/pat: Don't report PAT on
On 7/12/22 3:18 PM, Chuck Zmudzinski wrote:
> On 7/12/22 2:27 PM, Juergen Gross wrote:
> > On 12.07.22 20:20, Chuck Zmudzinski wrote:
> > > The commit 99c13b8c8896d7bcb92753bf
> > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > > incorrectly failed to account for the case in
flight 171602 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171602/
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
Hi,
On Tue, Jul 12, 2022 at 09:27:07PM +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Jul 12, 2022 at 04:36:10PM +, Xen.org security team wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Xen Security Advisory CVE-2022-23816,CVE-2022-23825,CVE-2022-29900 /
> > XS
On Tue, Jul 12, 2022 at 03:19:39PM -0400, Boris Ostrovsky wrote:
>
> On 7/12/22 12:38 PM, Greg KH wrote:
> > Hi all,
> >
> > I'm seeing the following build warning:
> > arch/x86/kernel/head_64.o: warning: objtool:
> > xen_hypercall_mmu_update(): can't find starting instruction
> > in the 5.1
Hi,
On Tue, Jul 12, 2022 at 04:36:10PM +, Xen.org security team wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Xen Security Advisory CVE-2022-23816,CVE-2022-23825,CVE-2022-29900 / XSA-407
>
>Retbleed - arbitrary speculative code execution with return instructions
>
> IS
On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> On 7/12/22 2:36 PM, Greg KH wrote:
> > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > The commit 99c13b8c8896d7bcb92753bf
> > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > > incorrect
On 7/12/22 12:38 PM, Greg KH wrote:
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't find starting instruction
in the 5.15.y and 5.10.y retbleed backports.
I don't know why just this one hypercall is being
On 7/12/22 2:27 PM, Juergen Gross wrote:
> On 12.07.22 20:20, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the case in init_cache_modes() when
> > CPUs do support PAT and fals
On 7/12/22 2:36 PM, Greg KH wrote:
> On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > The commit 99c13b8c8896d7bcb92753bf
> > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > incorrectly failed to account for the case in init_cache_modes() when
> > CPUs do sup
On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> The commit 99c13b8c8896d7bcb92753bf
> ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> incorrectly failed to account for the case in init_cache_modes() when
> CPUs do support PAT and falsely reported PAT to be disab
On 12.07.22 20:20, Chuck Zmudzinski wrote:
The commit 99c13b8c8896d7bcb92753bf
("x86/mm/pat: Don't report PAT on CPUs that don't support it")
incorrectly failed to account for the case in init_cache_modes() when
CPUs do support PAT and falsely reported PAT to be disabled when in
fact PAT is enabl
The commit 99c13b8c8896d7bcb92753bf
("x86/mm/pat: Don't report PAT on CPUs that don't support it")
incorrectly failed to account for the case in init_cache_modes() when
CPUs do support PAT and falsely reported PAT to be disabled when in
fact PAT is enabled. In some environments, notably in Xen PV d
flight 171593 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171593/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 171586
test-armhf-armhf-libvirt 16 save
On 11/07/2022 17:08, Rahul Singh wrote:
Hi Julien,
Hi Rahul,
On 22 Jun 2022, at 3:51 pm, Julien Grall wrote:
Hi,
On 22/06/2022 15:37, Rahul Singh wrote:
evtchn_alloc_unbound() always allocates the next available port. Static
event channel support for dom0less domains requires allocating a
Sorry for all of the emails, but here is /proc/device-tree with XEN and
without XEN:
with Xen:
With XEN
qos@ffa60080 interrupt-parent
qos@ffa9 qos@ffaa8080
pmu-clock-controller@ff75 watchdog@ff848000
pwm@ff420030 serial@ff1b
vcc5
flight 171599 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171599/
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
Hi all,
I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool:
xen_hypercall_mmu_update(): can't find starting instruction
in the 5.15.y and 5.10.y retbleed backports.
I don't know why just this one hypercall is being called out by objtool,
and this warning
On 7/12/22 11:30 AM, Juergen Gross wrote:
> On 12.07.22 17:09, Chuck Zmudzinski wrote:
> > On 7/12/2022 9:32 AM, Juergen Gross wrote:
> >> On 12.07.22 15:22, Chuck Zmudzinski wrote:
> >>> On 7/12/2022 2:04 AM, Jan Beulich wrote:
> On 11.07.2022 19:41, Chuck Zmudzinski wrote:
> > Moreove
Hi Bertrand,
I believe I understand, but just to clarify, should I leave the
ppi-partitions block in rk3399.dtsi as is and disable the little cores, or
should I also modify that block?
Brad
On Tue, Jul 12, 2022 at 11:11 AM Bertrand Marquis
wrote:
> Hi Brad,
>
> > On 12 Jul 2022, at 16:59, Brad
Hi Brad,
> On 12 Jul 2022, at 16:59, Brad Churchwell wrote:
>
> Hi Bertrand,
>
> Thanks so much for the quick response!
>
> I should have mentioned previously that this device tree and kernel Image
> (5.15.16) does boot properly with the rootfs without XEN. The interrupt
> errors are only prese
On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> From: Connor Davis
>
> [Connor]
> Xue is a cross-platform USB 3 debugger that drives the Debug
> Capability (DbC) of xHCI-compliant host controllers. This patch
> implements the operations needed for xue to initialize the host
> controller'
On 06.07.2022 17:32, Marek Marczykowski-Górecki wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -721,10 +721,15 @@ Available alternatives, with their meaning, are:
>
> ### dbgp
> > `= ehci[ | @pci:. ]`
> +> `= xue`
>
> Specify the USB controll
Hi Bertrand,
Thanks so much for the quick response!
I should have mentioned previously that this device tree and kernel Image
(5.15.16) does boot properly with the rootfs without XEN. The interrupt
errors are only present when booting with XEN.
These are custom boards and they do have usb c, how
On 12.07.22 17:09, Chuck Zmudzinski wrote:
On 7/12/2022 9:32 AM, Juergen Gross wrote:
On 12.07.22 15:22, Chuck Zmudzinski wrote:
On 7/12/2022 2:04 AM, Jan Beulich wrote:
On 11.07.2022 19:41, Chuck Zmudzinski wrote:
Moreover... (please move to the bottom of the code snippet
for more informatio
On 7/12/2022 9:32 AM, Juergen Gross wrote:
> On 12.07.22 15:22, Chuck Zmudzinski wrote:
> > On 7/12/2022 2:04 AM, Jan Beulich wrote:
> >> On 11.07.2022 19:41, Chuck Zmudzinski wrote:
> >>> Moreover... (please move to the bottom of the code snippet
> >>> for more information about my tests in the Xe
Hi Brad,
> On 11 Jul 2022, at 19:38, Brad Churchwell wrote:
>
> Hello,
>
> I've been trying to get Xen to boot dom0 with my kernel for weeks on an
> rk3399 based board and thought I'd reach out for help. It looks like either
> Xen is not properly recreating the device tree or the interrupt cont
...because there are some scripts in automation corresponding to the
entry (build-test.sh and build-each-commit.sh)
Signed-off-by: Bertrand Marquis
---
.gitignore | 1 -
1 file changed, 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 4729911c51..f731975713 100644
--- a/.gitignore
+++ b
On 08.07.2022 16:54, Wei Chen wrote:
> --- a/xen/arch/Kconfig
> +++ b/xen/arch/Kconfig
> @@ -17,3 +17,14 @@ config NR_CPUS
> For CPU cores which support Simultaneous Multi-Threading or similar
> technologies, this the number of logical threads which Xen will
> support.
> +
>
On 08.07.2022 16:54, Wei Chen wrote:
> We have moved acpi_scan_nodes from x86 to common. Because of
> of our previous work, this function no longer has many ACPI
> characteristics, except some "SRAT" words in print messages.
> So we rename acpi_scan_nodes to a more generic name
> numa_scan_nodes, a
On 08.07.2022 16:54, Wei Chen wrote:
> When NUMA initialization code is failed in scanning SRAT. It will
> call bad_srat to set disable NUMA and clear relate data. But this
> name is ACPI specific, we have moved generically usable NUMA codes
> to common, bad_srat has came with these codes to common
On 08.07.2022 16:54, Wei Chen wrote:
> x86 has implemented a set of codes to scan NUMA nodes. These
> codes will parse NUMA memory and processor information from
> ACPI SRAT table. But except some ACPI specific codes, most
> of the scan codes like memory blocks validation, node memory
> range updat
Move the "credit expired" loop exit to the middle of the loop,
immediately after "return true". This way having reached the goal on the
last iteration would be reported as success to the caller, rather than
as "timed out".
Signed-off-by: Jan Beulich
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/x
On 08.07.2022 16:54, Wei Chen wrote:
> @@ -82,3 +83,25 @@ unsigned int __init arch_get_dma_bitsize(void)
> flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 -
> 1)
> + PAGE_SHIFT, 32);
> }
> +
> +/*
> + * This function provides the ability for caller to
On 12.07.22 15:22, Chuck Zmudzinski wrote:
On 7/12/2022 2:04 AM, Jan Beulich wrote:
On 11.07.2022 19:41, Chuck Zmudzinski wrote:
Moreover... (please move to the bottom of the code snippet
for more information about my tests in the Xen PV environment...)
void init_cache_modes(void)
{
u64 p
On 7/12/2022 2:04 AM, Jan Beulich wrote:
> On 11.07.2022 19:41, Chuck Zmudzinski wrote:
> > Moreover... (please move to the bottom of the code snippet
> > for more information about my tests in the Xen PV environment...)
> >
> > void init_cache_modes(void)
> > {
> > u64 pat = 0;
> >
> > i
On 08.07.2022 16:54, Wei Chen wrote:
> --- /dev/null
> +++ b/xen/common/numa.c
> @@ -0,0 +1,439 @@
> +/*
> + * Generic VM initialization for NUMA setups.
> + * Copyright 2002,2003 Andi Kleen, SuSE Labs.
> + * Adapted for Xen: Ryan Harper
> + */
> +
> +#include
> +#include
> +#include
> +#includ
flight 171588 qemu-mainline real [real]
flight 171596 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171588/
http://logs.test-lab.xenproject.org/osstest/logs/171596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Tue, Jul 12, 2022 at 09:01:48AM +0200, Jan Beulich wrote:
> On 11.07.2022 18:21, Anthony PERARD wrote:
> > On Fri, Jul 08, 2022 at 03:39:38PM +0200, Jan Beulich wrote:
> >> While in principle possible also under other conditions as long as other
> >> parallel operations potentially consuming mem
On Tue, Jul 12, 2022 at 08:18:30AM +0200, Juergen Gross wrote:
> In case of maxmem != memsize the E820 map of the PVH stubdom is wrong,
> as it is missing the RAM above memsize.
>
> Additionally the memory map should only specify the Xen special pages
> as reserved.
>
> Signed-off-by: Juergen Gro
On 08.07.2022 16:54, Wei Chen wrote:
> In current code, x86 is using two variables, numa_off and acpi_numa,
> to indicate the NUMA status. This is because NUMA is not coupled with
> ACPI, and ACPI still can work without NUMA on x86. With these two
> variables' combinations, x86 can have several NUM
On Tue, Jul 12, 2022 at 11:10:07AM +0200, Juergen Gross wrote:
> Enumerating a file from $(targets) in $(clean-files) isn't needed.
>
> Remove hypercall-defs.h and headers*.chk from $(clean-files) in
> xen/include/Makefile.
>
> Reported-by: Jan Beulich
> Fixes: eca1f00d0227 ("xen: generate hyper
flight 171590 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171590/
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 171589 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171589/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
On 08.07.2022 16:54, Wei Chen wrote:
> x86 provides a mem_hotplug variable to maintain the memory hotplug
> end address. We want to move some codes from x86 to common, so that
> it can be reused by other architectures. But not all architectures
> have supported memory hotplug. So in this patch, we
Enumerating a file from $(targets) in $(clean-files) isn't needed.
Remove hypercall-defs.h and headers*.chk from $(clean-files) in
xen/include/Makefile.
Reported-by: Jan Beulich
Fixes: eca1f00d0227 ("xen: generate hypercall interface related code")
Signed-off-by: Juergen Gross
---
V2:
- remove
flight 171587 linux-linus real [real]
flight 171592 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171587/
http://logs.test-lab.xenproject.org/osstest/logs/171592/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 171586 xen-unstable real [real]
flight 171591 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171586/
http://logs.test-lab.xenproject.org/osstest/logs/171591/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 12.07.2022 09:20, Wei Chen wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年7月11日 14:32
>> To: Wei Chen
>> Cc: nd ; Andrew Cooper ; George
>> Dunlap ; Julien Grall ; Stefano
>> Stabellini ; Wei Liu ; Jiamei Xie
>> ; xen-devel@lists.xenproject.org
>> Subject:
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年7月11日 14:32
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini ; Wei Liu ; Jiamei Xie
> ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2 4/9] xen/x86: Use ASSERT instead of
On 12.07.2022 09:01, Jan Beulich wrote:
> On 11.07.2022 18:21, Anthony PERARD wrote:
>> On Fri, Jul 08, 2022 at 03:39:38PM +0200, Jan Beulich wrote:
>>> While in principle possible also under other conditions as long as other
>>> parallel operations potentially consuming memory aren't "locked out",
On 11.07.2022 18:21, Anthony PERARD wrote:
> On Fri, Jul 08, 2022 at 03:39:38PM +0200, Jan Beulich wrote:
>> While in principle possible also under other conditions as long as other
>> parallel operations potentially consuming memory aren't "locked out", in
>> particular with IOMMU large page mappi
67 matches
Mail list logo
