flight 184785 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-amd64-libvirt-q
From: Juergen Gross
Add a memory region which can be used to automatically map granted
memory. It is starting at 0x8000ULL in order to be able to
distinguish it from normal RAM.
For this reason the xen.ram memory region is expanded, which has no
further impact as it is used just as a
From: Juergen Gross
Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
case it can't find a matching entry for a pointer value. Both cases
are bad, so change that to return an invalid address instead.
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
hw/xen/x
From: Juergen Gross
Add the callbacks for mapping/unmapping guest memory via grants to the
special grant memory region.
Signed-off-by: Juergen Gross
Signed-off-by: Vikram Garhwal
---
hw/xen/xen-mapcache.c | 176 +-
system/physmem.c | 11 ++-
2 fil
flight 184790 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184790/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aceb3490a2a350b128156fd4e36e53fc19739e4e
baseline version:
ovmf ba9c3ceaf83d3ee448b2f
flight 184784 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184784/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184529
test-armhf-armhf-libvirt 16
On Tue, 27 Feb 2024, Jan Beulich wrote:
> On 27.02.2024 00:48, Stefano Stabellini wrote:
> > On Mon, 26 Feb 2024, Jan Beulich wrote:
> >> On 23.02.2024 23:36, Stefano Stabellini wrote:
> >>> On Fri, 23 Feb 2024, Jan Beulich wrote:
> On 23.02.2024 02:32, Stefano Stabellini wrote:
> > On Tue
On Tue, 27 Feb 2024, Jan Beulich wrote:
> On 27.02.2024 12:52, Julien Grall wrote:
> > Hi Jan,
> >
> > On 27/02/2024 07:28, Jan Beulich wrote:
> >> On 27.02.2024 01:26, Stefano Stabellini wrote:
> >>> On Mon, 26 Feb 2024, Jan Beulich wrote:
> On 23.02.2024 10:35, Nicola Vetrini wrote:
> >
On Tue, 27 Feb 2024, Jan Beulich wrote:
> On 26.02.2024 23:49, Stefano Stabellini wrote:
> > On Mon, 26 Feb 2024, Jan Beulich wrote:
> >> On 26.02.2024 09:23, Nicola Vetrini wrote:
> >>> On 2024-02-26 09:00, Jan Beulich wrote:
> On 23.02.2024 23:56, Stefano Stabellini wrote:
> > On Fri, 23
In the common sysctl command XEN_SYSCTL_physinfo, the value of
cores_per_socket is calculated based on the cpu_core_mask of CPU0.
Currently on Arm this is a fixed value 1 (can be checked via xl info),
which is not correct. This is because during the Arm CPU online
process at boot time, setup_cpu_si
On Tue, Feb 27, 2024 at 9:59 AM Christoph Hellwig wrote:
>
> > privately-managed pages into a sparse vm area with the following steps:
> >
> > area = get_vm_area(area_size, VM_SPARSE); // at bpf prog verification
> > time
> > vm_area_map_pages(area, kaddr, 1, page); // on demand
> >
flight 184783 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184783/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184553
test-amd64-amd64-xl-qemut-ws16-a
flight 184798 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184798/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Wed, 21 Feb 2024 13:58:41 +0100, Christoph Hellwig wrote:
> this series converts xen-blkfront to the new atomic queue limits update
> API in the block tree. I don't have a Xen setup so this is compile
> tested only.
>
> Changes since v1:
> - constify the info argument to blkif_set_queue_lim
flight 184793 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 184781
build-arm64-
On Tue, Feb 27, 2024 at 01:26:28PM +, Fouad Hilly wrote:
> diff --git a/tools/libs/stat/xenstat_linux.c b/tools/libs/stat/xenstat_linux.c
> index cbba54aa83ee..6d82e204aad4 100644
> --- a/tools/libs/stat/xenstat_linux.c
> +++ b/tools/libs/stat/xenstat_linux.c
> @@ -390,6 +390,38 @@ void xenstat
> privately-managed pages into a sparse vm area with the following steps:
>
> area = get_vm_area(area_size, VM_SPARSE); // at bpf prog verification time
> vm_area_map_pages(area, kaddr, 1, page); // on demand
> // it will return an error if kaddr is out of range
> vm_a
flight 184780 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184780/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184776
test-amd64-amd64-xl-qemut-win7-amd64
Hi Oleksii,
On 2/20/24 9:20 AM, Oleksii wrote:
> Hi Shawn,
>
> Could you please take a look at the patch and PPC-related changes (
> xen/arch/ppc/include/asm/bitops.h )?
>
Hi Oleksii,
Sorry for the delay. This all looks good to me:
Acked-by: Shawn Anastasio
> Thanks in advance.
>
> ~ Oleks
On Tue, Feb 27, 2024 at 01:32:05PM +, Ross Lagerwall wrote:
> On Wed, Jan 31, 2024 at 4:58 PM Roger Pau Monne wrote:
> >
> > XenServer uses quite long Xen version names, and encode such in the
> > livepatch
> > filename, and it's currently running out of space in the file name.
> >
> > Bump m
On Tue, Feb 27, 2024 at 09:57:43AM -0500, Stewart Hildebrand wrote:
> The recent vPCI locking broke the vPCI unit tests. Fix it to unblock CI.
>
> Fixes: 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
> structure")
> Reported-by: Andrew Cooper
> Signed-off-by: Stewart Hildebrand
>
flight 184787 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 184781
build-arm64-
>From v6.8-rc8
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/intel-family.h | 38 ++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/include/asm/intel-family.h
b/xen/arch/x86/in
Jens,
can you pick this up with the Xen maintainer review in place?
On 27/02/2024 3:36 pm, Simone Ballarin wrote:
> The list of function/macro properties is not MISRA-specific documentation.
> Their addition was directly motivated to address MISRA findings and they
> are not used elsewhere. For this reason, this patch moves these properties
> in docs/misra.
>
> Thi
On 26/02/24 16:44, Andrew Cooper wrote:
On 02/02/2024 3:16 pm, Simone Ballarin wrote:
From: Maria Celeste Cesario
Function and macro properties contained in ECLAIR/call_properties.ecl are of
general interest: this patch moves these annotations in a generaric JSON file
in docs. In this way, the
The list of function/macro properties is not MISRA-specific documentation.
Their addition was directly motivated to address MISRA findings and they
are not used elsewhere. For this reason, this patch moves these properties
in docs/misra.
This patch also fixes a Sphinx warning caused by the missing
flight 184782 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184782/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ba9c3ceaf83d3ee448b2fd38bc9ad28b690c697a
baseline version:
ovmf 74b5309da9fb7a919bec5
The recent vPCI locking broke the vPCI unit tests. Fix it to unblock CI.
Fixes: 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci structure")
Reported-by: Andrew Cooper
Signed-off-by: Stewart Hildebrand
---
tools/tests/vpci/emul.h | 9 -
tools/tests/vpci/main.c | 2 +-
2 file
On 27/02/2024 1:19 pm, Jan Beulich wrote:
> All,
>
> the release is due in two to three weeks. Please point out backports you find
> missing from the respective staging branch, but which you consider relevant.
>
> Jan
>
Looking at the XenServer patchqueue, a couple to consider but nothing
jumps ou
Hi Jan,
On 2/27/2024 9:51 PM, Jan Beulich wrote:
On 27.02.2024 14:35, Henry Wang wrote:
Hi Jan,
On 2/27/2024 9:27 PM, Jan Beulich wrote:
On 27.02.2024 14:24, Henry Wang wrote:
On 2/26/2024 4:25 PM, Jan Beulich wrote:
On 26.02.2024 02:19, Henry Wang wrote:
--- a/xen/common/memory.c
+++ b/xe
On 27.02.2024 14:35, Henry Wang wrote:
> Hi Jan,
>
> On 2/27/2024 9:27 PM, Jan Beulich wrote:
>> On 27.02.2024 14:24, Henry Wang wrote:
>>> On 2/26/2024 4:25 PM, Jan Beulich wrote:
On 26.02.2024 02:19, Henry Wang wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@
flight 184781 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184781/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Hi Jan,
On 2/27/2024 9:27 PM, Jan Beulich wrote:
On 27.02.2024 14:24, Henry Wang wrote:
On 2/26/2024 4:25 PM, Jan Beulich wrote:
On 26.02.2024 02:19, Henry Wang wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -219,7 +219,7 @@ static void populate_physmap(struct memop_args *a)
On Wed, Jan 31, 2024 at 4:58 PM Roger Pau Monne wrote:
>
> XenServer uses quite long Xen version names, and encode such in the livepatch
> filename, and it's currently running out of space in the file name.
>
> Bump max filename size to 128, so it also matches the patch name length in the
> hyperv
From: Pritha Srivastava
xl now knows how to drive tapdisk, so modify libxenstat to
understand vbd3 statistics.
Signed-off-by: Pritha Srivastava
Signed-off-by: Jorge Martin
Signed-off-by: Fouad Hilly
---
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
v2:
- Fix order of SoB
- Fix Syntax
-
Hi Michal,
On 2/26/2024 6:29 PM, Michal Orzel wrote:
Hi Henry,
On 26/02/2024 02:19, Henry Wang wrote:
An error message can seen from the init-dom0less application on
direct-mapped 1:1 domains:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc magic pa
On 27.02.2024 14:24, Henry Wang wrote:
> On 2/26/2024 4:25 PM, Jan Beulich wrote:
>> On 26.02.2024 02:19, Henry Wang wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -219,7 +219,7 @@ static void populate_physmap(struct memop_args *a)
>>> }
>>> else
>>>
Hi Jan,
On 2/26/2024 4:25 PM, Jan Beulich wrote:
On 26.02.2024 02:19, Henry Wang wrote:
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -428,6 +428,19 @@ static inline void page_set_xenheap_gfn(struct page_info
*p, gfn_t gfn)
} while ( (y = cmpxchg(&p->u.inuse.
On 27.02.2024 12:20, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 01:54:54PM +0100, Jan Beulich wrote:
>> On 26.02.2024 12:07, Roger Pau Monne wrote:
>>> Now that the thunk built-in enable is printed as part of the "Compiled-in
>>> support:" line, avoid printing anything in "Xen settings:" if t
All,
the release is due in two to three weeks. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
Jan
(-RISC-V and PPC people to avoid spamming their inbox as this is quite
Arm specific)
Hi Julien,
On 2/26/2024 5:13 PM, Julien Grall wrote:
Hi Henry,
Welcome back!
Thanks!
On 26/02/2024 01:19, Henry Wang wrote:
An error message can seen from the init-dom0less application on
direct-mapped 1
On 27/02/2024 11:25 am, Roger Pau Monne wrote:
> diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
> index ddac5c9147e5..e3a4dc8540df 100644
> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
>
>
> +#ifdef CONFIG_LIVEPATCH
> void unregister_virtual_regi
Hi Stefano,
On 13/02/2024 22:33, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On 27.02.2024 12:52, Julien Grall wrote:
> Hi Jan,
>
> On 27/02/2024 07:28, Jan Beulich wrote:
>> On 27.02.2024 01:26, Stefano Stabellini wrote:
>>> On Mon, 26 Feb 2024, Jan Beulich wrote:
On 23.02.2024 10:35, Nicola Vetrini wrote:
> Refactor cpu_notifier_call_chain into two functions:
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-46841 / XSA-451
version 2
x86: shadow stack vs exceptions from emulation stubs
UPDATES IN VERSION 2
Largely cosmetic adjustment in patches.
Pu
Hi Jan,
On 27/02/2024 07:28, Jan Beulich wrote:
On 27.02.2024 01:26, Stefano Stabellini wrote:
On Mon, 26 Feb 2024, Jan Beulich wrote:
On 23.02.2024 10:35, Nicola Vetrini wrote:
Refactor cpu_notifier_call_chain into two functions:
- the variant that is allowed to fail loses the nofail flag
-
It seems the build variables for those tests where copy-pasted from
xen_action_hooks_marker-objs and not adjusted to use the correct source files.
Fixes: 6047104c3ccc ('livepatch: Add per-function applied/reverted state
tracking marker')
Signed-off-by: Roger Pau Monné
Reviewed-by: Ross Lagerwall
When checking if an address belongs to a patch, or when resolving a symbol,
take into account all loaded livepatch payloads, even if not applied.
This is required in order for the pre-apply and post-revert hooks to work
properly, or else Xen won't detect the instruction pointer belonging to those
Group the payload hooks between the pre/post handlers, and the apply/revert
replacements. Also attempt to comment the context in which the hooks are
executed.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/include/xen/livepatch_payloa
The purpose of the norevert test is to install a dummy handler that replaces
the internal Xen revert code, and then perform the revert in the post-revert
hook. For that purpose the usage of the previous common_livepatch_revert() is
not enough, as that just reverts specific functions, but not the w
Hello,
The follow series contain a misc of fixes mostly related to the usage of
the pre-apply / post-revert hooks. The norevert test is also fixed to
work as I think was expected. Finally both the no{apply,revert}
tests are fixed to build properly, as the files where previously
unhooked from the
Currently livepatch regions are registered as virtual regions only after the
livepatch has been applied.
This can lead to issues when using the pre-apply or post-revert hooks, as at
that point the livepatch is not in the virtual regions list. If a livepatch
pre-apply hook contains a WARN() it wou
Hi,
On 13/02/2024 11:13, Jens Wiklander wrote:
When an FF-A enabled guest is destroyed it may leave behind memory
shared with SPs. This memory must be reclaimed before it's reused or an
SP may make changes to memory used by a new unrelated guest. So when the
domain is teared down add FF-A reques
On Mon, Feb 26, 2024 at 01:54:54PM +0100, Jan Beulich wrote:
> On 26.02.2024 12:07, Roger Pau Monne wrote:
> > Now that the thunk built-in enable is printed as part of the "Compiled-in
> > support:" line, avoid printing anything in "Xen settings:" if the thunk is
> > disabled at build time.
>
> Wh
On Mon, Feb 26, 2024 at 01:50:46PM +0100, Jan Beulich wrote:
> On 26.02.2024 12:07, Roger Pau Monne wrote:
> > Attempt to provide a more helpful error message when the user attempts to
> > set
> > spec-ctrl=bti-thunk option but the support is build-time disabled.
> >
> > While there also adjust t
On Mon, Feb 26, 2024 at 01:39:49PM +0100, Jan Beulich wrote:
> On 26.02.2024 12:07, Roger Pau Monne wrote:
> > Just like it's done for INDIRECT_THUNK and SHADOW_PAGING.
> >
> > Reported-by: Jan Beulich
> > Signed-off-by: Roger Pau Monné
>
> In principle
> Reviewed-by: Jan Beulich
> but ...
>
On Mon, Feb 26, 2024 at 03:47:17PM +0100, Jan Beulich wrote:
> On 21.02.2024 03:45, Stewart Hildebrand wrote:
> > From: Oleksandr Andrushchenko
> >
> > Use the per-domain PCI read/write lock to protect the presence of the
> > pci device vpci field. This lock can be used (and in a few cases is use
On Tue, Feb 20, 2024 at 09:45:03PM -0500, Stewart Hildebrand wrote:
> From: Oleksandr Andrushchenko
>
> Use the per-domain PCI read/write lock to protect the presence of the
> pci device vpci field. This lock can be used (and in a few cases is used
> right away) so that vpci removal can be perfor
Hi everyone,
*Just a reminder that our CFP for Xen Summit 2024 is at the end of this
week! *
Please submit your talks before then:
https://events.linuxfoundation.org/xen-project-summit/program/cfp/
We look forward to seeing you.
Many thanks,
Kelly Choi
Community Manager
Xen Project
flight 184778 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184778/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 74b5309da9fb7a919bec5a8b5a63d1ede5eb6745
baseline version:
ovmf 33c81c25bbd55141ad395
flight 184776 xen-unstable real [real]
flight 184779 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184776/
http://logs.test-lab.xenproject.org/osstest/logs/184779/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, Feb 27, 2024 at 09:53:24AM +0100, Jan Beulich wrote:
> On 27.02.2024 09:15, Roger Pau Monné wrote:
> > On Mon, Feb 26, 2024 at 01:36:32PM +0100, Jan Beulich wrote:
> >> On 26.02.2024 12:32, Roger Pau Monné wrote:
> >>> On Tue, Feb 13, 2024 at 04:58:38PM +0100, Jan Beulich wrote:
> On 0
On 27.02.2024 09:15, Roger Pau Monné wrote:
> On Mon, Feb 26, 2024 at 01:36:32PM +0100, Jan Beulich wrote:
>> On 26.02.2024 12:32, Roger Pau Monné wrote:
>>> On Tue, Feb 13, 2024 at 04:58:38PM +0100, Jan Beulich wrote:
On 07.02.2024 15:55, Roger Pau Monne wrote:
> The minimal function size
On Mon, Feb 26, 2024 at 01:36:32PM +0100, Jan Beulich wrote:
> On 26.02.2024 12:32, Roger Pau Monné wrote:
> > On Tue, Feb 13, 2024 at 04:58:38PM +0100, Jan Beulich wrote:
> >> On 07.02.2024 15:55, Roger Pau Monne wrote:
> >>> The minimal function size requirements for an x86 livepatch are either 5
65 matches
Mail list logo
