On Fri, Jul 08, 2022 at 12:37:44PM -0400, Demi Marie Obenour wrote:
> The recent gntdev fixes introduced two incorrect WARN_ON()s, which
> triggered immediately on my system. Patches for master and all
> supported stable versions follow.
>
>
This is not the correct way to submit patches for i
flight 171561 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl broken
test-amd64-amd64-xl-credit1 8 xen-boot
On Fri, Jul 8, 2022 at 10:28 AM G.R. wrote:
>
> On Fri, Jul 8, 2022 at 12:38 AM Jan Beulich wrote:
> >
> > > I built both 4.14.3 debug version and 4.16.1 release version for
> > > testing purposes.
> > > Unfortunately they gave me absolutely zero information, since both of
> > > them are not able
flight 171560 xen-unstable real [real]
flight 171563 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171560/
http://logs.test-lab.xenproject.org/osstest/logs/171563/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Fri, Jul 8, 2022 at 10:28 AM G.R. wrote:
>
> On Fri, Jul 8, 2022 at 12:38 AM Jan Beulich wrote:
> > > But the 'xl pci-assignable-remove' will lead to xl segmentation fault...
> > >> [ 655.041442] xl[975]: segfault at 0 ip 7f2cccdaf71f sp
> > >> 7ffd73a3d4d0 error 4 in libxenlight.so.
flight 171559 qemu-mainline real [real]
flight 171562 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171559/
http://logs.test-lab.xenproject.org/osstest/logs/171562/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the ESRT shall be stored in memory of type EfiBootServicesData. However,
memory of type EfiBootServicesData is considered general-purpose memory
by Xen,
Hi Jens,
This is the second part of the review.
On 22/06/2022 14:42, Jens Wiklander wrote:
+static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
+ struct ffa_address_range *range, uint32_t range_count,
AFAICT, 'range' is not meant to be modified. So I wo
On 7/8/22 18:56, Stefano Stabellini wrote:
On Fri, 8 Jul 2022, Xenia Ragiadakou wrote:
On 7/8/22 02:05, Stefano Stabellini wrote:
On Thu, 7 Jul 2022, Julien Grall wrote:
Hi Xenia,
On 07/07/2022 21:38, Xenia Ragiadakou wrote:
Add an arm subdirectory under automation/configs for the arm spec
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
On Thu, 7 Jul 2022, Penny Zheng wrote:
> Hi Stefano and julien
>
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: Thursday, July 7, 2022 7:53 AM
> > To: Penny Zheng
> > Cc: Stefano Stabellini ; Julien Grall
> > ;
> > xen-devel@lists.xenproject.org; Wei Chen ; Bertrand
> > M
flight 171553 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171553/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 8 xen-boot fail REGR. vs. 171277
test-amd64-amd64-li
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd jou
The recent gntdev fixes introduced two incorrect WARN_ON()s, which
triggered immediately on my system. Patches for master and all
supported stable versions follow.
Andrew Cooper (3):
x86/spec-ctrl: Honour spec-ctrl=0 for unpriv-mmio sub-option
xen/cmdline: Extend parse_boolean() to signal a name match
x86/spec-ctrl: Add fine-grained cmdline suboptions for primitives
docs/misc/xen-command-line.pandoc | 12 +--
xen/arch/x86/spec_ctrl.c | 67
Support controling the PV/HVM suboption of msr-sc/rsb/md-clear, which
previously wasn't possible.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
docs/misc/xen-command-line.pandoc | 12 +--
xen/arch/x86/spec_ctrl.c | 66 +++
This will help parsing a sub-option which has boolean and non-boolean options
available.
First, rework 'int val' into 'bool has_neg_prefix'. This inverts it's value,
but the resulting logic is far easier to follow.
Second, reject anything of the form 'no-$FOO=' which excludes ambiguous
construct
This was an oversight from when unpriv-mmio was introduced.
Fixes: 8c24b70fedcb ("x86/spec-ctrl: Add spec-ctrl=unpriv-mmio")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/spec_ctrl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/ar
Hi,
On 08/07/2022 16:56, Stefano Stabellini wrote:
Or we could add a script to detect and print specific output but I
don't know if there is something under /proc or /sys that we could
simply "cat" from bash to check it.
The domain device-tree should be /proc/device-tree. So you could check
t
On Fri, 8 Jul 2022, Xenia Ragiadakou wrote:
> On 7/8/22 02:05, Stefano Stabellini wrote:
> > On Thu, 7 Jul 2022, Julien Grall wrote:
> > > Hi Xenia,
> > >
> > > On 07/07/2022 21:38, Xenia Ragiadakou wrote:
> > > > Add an arm subdirectory under automation/configs for the arm specific
> > > > config
> On 24 Jun 2022, at 17:04, Anthony PERARD wrote:
>
> Setup proper dependencies with libacpi so we don't need to run "make
> hvmloader" in the "all" target. ("build.o" new prerequisite isn't
> exactly proper but a side effect of building the $(DSDT_FILES) is to
> generate the "ssdt_*.h" needed
> On 24 Jun 2022, at 17:04, Anthony PERARD wrote:
>
> Don't check if a target exist before installing it. For directory,
> install doesn't complain, and for file it would prevent from updating
> them. Also remove the existing loop and instead install all files with
> a single call to $(INSTALL
> On 24 Jun 2022, at 17:03, Anthony PERARD wrote:
>
> gdbsx/:
> - Make use of subdir facility for the "clean" target.
> - No need to remove the *.a, they aren't in this dir.
> - Avoid calling "distclean" in subdirs as "distclean" targets do only
>call "clean", and the "clean" also runs
> On 24 Jun 2022, at 17:03, Anthony PERARD wrote:
>
> Sources of both xenconsoled and xenconsole are already separated into
> different directory and don't share anything in common. Having two
> different Makefile means it's easier to deal with *FLAGS.
>
> Some common changes:
> Rename $(BIN)
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series - merged in [1]
2. Move generically usable cod
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 updates and some sanity check can be reused by other
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 code. But
it's not reasonable for other NUMA
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, and replace "SRAT" words in print messages.
Aft
Current NUMA nodes number is a hardcode configuration. This
configuration is difficult for an administrator to change
unless changing the code.
So in this patch, we introduce this new Kconfig option for
administrators to change NUMA nodes number conveniently.
Also considering that not all architec
The sanity check performed by the nodes_cover_memory function is
also necessary for other architectures that do not yet support NUMA.
But now, the code of nodes_cover_memory is tied to the x86 E820.
In this case, we introduce arch_get_memory_map to decouple
architecture specific memory map from thi
There are some codes in x86/numa.c can be shared by architectures
to implement NUMA support. Just like some variables and functions
to check and store NUMA memory map. And some variables and functions
to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
and use th
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX
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 NUMA status:
NUMA swith on,
NUMA swith off,
NUMA
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 introduce this
helper to replace mem_hotplug
On 08/07/2022 15:33, Christian Lindig wrote:
>
>
> On 8 Jul 2022, at 14:55, Jane Malalane
> mailto:jane.malal...@citrix.com>> wrote:
>
> tools/ocaml/libs/xc/xenctrl.ml | 9 +
> tools/ocaml/libs/xc/xenctrl.mli | 8
> tools/ocaml/libs/xc/xenctrl_stubs.c | 18 +
flight 171555 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171555/
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 8 Jul 2022, at 14:55, Jane Malalane
mailto:jane.malal...@citrix.com>> wrote:
tools/ocaml/libs/xc/xenctrl.ml | 9 +
tools/ocaml/libs/xc/xenctrl.mli | 8
tools/ocaml/libs/xc/xenctrl_stubs.c | 18 —
Acked-by: Christian Lindig
mailto:christian.lin...
flight 171552 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171552/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail pass in 171545
Tests which did not succeed, but
Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and
XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and
x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization
can subsequently be enabled on a per-domain basis.
No such features are currently implemented on AMD hardware
Hi Jens,
I haven't checked whether the FFA driver is complaint with the spec. I
mainly checked whether the code makes sense from Xen PoV.
This is a fairly long patch to review. So I will split my review in
multiple session/e-mail.
On 22/06/2022 14:42, Jens Wiklander wrote:
Adds a FF-A vers
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 mappings used in Dom0 (for PV when in
strict mode; for PVH when not sharing page tables with HAP) ballooning
out of indi
x86_has_pat_wp() is using a wrong test, as it relies on the normal
PAT configuration used by the kernel. In case the PAT MSR has been
setup by another entity (e.g. Xen hypervisor) it might return false
even if the PAT configuration is allowing WP mappings. This due to the
fact that when running as
On 07.07.2022 11:22, Penny Zheng wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -245,6 +245,29 @@ static void populate_physmap(struct memop_args *a)
>
> mfn = _mfn(gpfn);
> }
> +else if ( is_domain_using_staticmem(d) )
> +
On 07.07.2022 11:22, Penny Zheng wrote:
> @@ -2692,6 +2690,14 @@ void free_domstatic_page(struct page_info *page)
>
> free_staticmem_pages(page, 1, need_scrub);
>
> +if ( likely(d) )
> +{
> +/* Add page on the resv_page_list *after* it has been freed. */
> +if ( !dr
On 07.07.2022 11:22, Penny Zheng wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1622,6 +1622,8 @@ void put_page(struct page_info *page)
>
> if ( unlikely((nx & PGC_count_mask) == 0) )
> {
> +if ( unlikely(nx & PGC_static) )
> +free_domstatic_page(pa
Hi Luca,
On 08/07/2022 13:01, Luca Fancellu wrote:
On 22 Jun 2022, at 14:42, Jens Wiklander wrote:
SMCCC v1.2 AArch64 allows x0-x17 to be used as both parameter registers
and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7
flight 171557 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171557/
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 Jens,
> On 22 Jun 2022, at 14:42, Jens Wiklander wrote:
>
> SMCCC v1.2 AArch64 allows x0-x17 to be used as both parameter registers
> and result registers for the SMC and HVC instructions.
>
> Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
> parameter and result regis
flight 171551 qemu-mainline real [real]
flight 171558 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171551/
http://logs.test-lab.xenproject.org/osstest/logs/171558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Stefano,
On 7/8/22 02:05, Stefano Stabellini wrote:
On Thu, 7 Jul 2022, Julien Grall wrote:
Hi Xenia,
On 07/07/2022 21:38, Xenia Ragiadakou wrote:
Add an arm subdirectory under automation/configs for the arm specific
configs
and add a config that enables static allocation.
Modify the buil
On 08/07/2022 10:00, Xenia Ragiadakou wrote:
+
+(grep -q "Xen dom0less mode detected" qemu-staticmem.serial) ||
exit 1
+
+for ((i=0; i<${#base[@]}; i++))
+do
+ start="$(printf "0x%016x" ${base[$i]})"
+ end="$(printf "0x%016x" $((${base[$i]} + ${size[$i]} - 1)))"
+ grep -q "node 0:
On 7/8/22 10:46, Julien Grall wrote:
On 08/07/2022 08:17, Xenia Ragiadakou wrote:
Hi Julien,
Hi Xenia,
On 7/8/22 01:26, Julien Grall wrote:
Hi Xenia,
On 07/07/2022 21:38, Xenia Ragiadakou wrote:
Add an arm subdirectory under automation/configs for the arm
specific configs
and add a c
On 08/07/2022 08:51, Jan Beulich wrote:
On 08.07.2022 09:35, Henry Wang wrote:
Proposed option 1: Wed Sep 28, 2022
(+9 months from Xen 4.16 release, after Xen Summit)
This would break our 8-month cadence or shorten 4.18 by a month (or
more, 4.16 was late in November already, and we're liabl
> On 8 Jul 2022, at 08:35, Henry Wang wrote:
>
> Hi,
>
> As discussed in the community call on July 7, the release schedule for Xen
> 4.17
> is proposed below. Please send comments ASAP and in any case by the end of
> Friday the 15th of July. I hope we can finalise the schedule then.
>
> Or
On 08.07.22 09:35, Henry Wang wrote:
Hi,
As discussed in the community call on July 7, the release schedule for Xen 4.17
is proposed below. Please send comments ASAP and in any case by the end of
Friday the 15th of July. I hope we can finalise the schedule then.
Original date following the 8 mo
On 08.07.2022 09:35, Henry Wang wrote:
> Proposed option 1: Wed Sep 28, 2022
> (+9 months from Xen 4.16 release, after Xen Summit)
This would break our 8-month cadence or shorten 4.18 by a month (or
more, 4.16 was late in November already, and we're liable to slip
anyway - simply based on history)
On 7/8/22 10:35, Julien Grall wrote:
Hi,
On 08/07/2022 00:05, Stefano Stabellini wrote:
On Thu, 7 Jul 2022, Julien Grall wrote:
+# Run the test
+rm -f qemu-staticmem.serial
+set +e
+echo " virtio scan; dhcp; tftpb 0x4000 boot.scr; source
0x4000"| \
+timeout -k 1 60 ./binaries/qem
On 08/07/2022 08:17, Xenia Ragiadakou wrote:
Hi Julien,
Hi Xenia,
On 7/8/22 01:26, Julien Grall wrote:
Hi Xenia,
On 07/07/2022 21:38, Xenia Ragiadakou wrote:
Add an arm subdirectory under automation/configs for the arm specific
configs
and add a config that enables static allocation.
On 08.07.2022 06:12, Juergen Gross wrote:
> As it is coming up basically every release cycle of Xen, add a
> reference to the discussion why the current release scheme has been
> selected in the release management documentation.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Hi Juergen,
> -Original Message-
> Subject: [PATCH] docs: add reference to release cycle discussion
>
> As it is coming up basically every release cycle of Xen, add a
> reference to the discussion why the current release scheme has been
> selected in the release management documentation.
Hi,
As discussed in the community call on July 7, the release schedule for Xen 4.17
is proposed below. Please send comments ASAP and in any case by the end of
Friday the 15th of July. I hope we can finalise the schedule then.
Original date following the 8 month release cycle (August 2022) is like
Hi,
On 08/07/2022 00:05, Stefano Stabellini wrote:
On Thu, 7 Jul 2022, Julien Grall wrote:
+# Run the test
+rm -f qemu-staticmem.serial
+set +e
+echo " virtio scan; dhcp; tftpb 0x4000 boot.scr; source 0x4000"| \
+timeout -k 1 60 ./binaries/qemu-system-aarch64 -nographic \
+-M virtu
Hi Julien,
On 7/8/22 01:26, Julien Grall wrote:
Hi Xenia,
On 07/07/2022 21:38, Xenia Ragiadakou wrote:
Add an arm subdirectory under automation/configs for the arm specific
configs
and add a config that enables static allocation.
Modify the build script to search for configs also in this
su
68 matches
Mail list logo
