flight 185741 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185741/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185737
flight 185739 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185739/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt 5
flight 185740 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185740/
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
flight 185737 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185737/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185731
On Fri, Apr 19, 2024 at 4:27 PM Nick Rosbrook wrote:
>
> On Fri, Apr 19, 2024 at 10:00 AM George Dunlap
> wrote:
> >
> > In a handful of cases, it was decided to return a pointer to a
> > structure rather than the plain structure itself, due to the size.
> > However, in these cases the
On Fri, Apr 19, 2024 at 4:29 PM George Dunlap wrote:
>
> On Fri, Jul 7, 2023 at 3:56 PM George Dunlap wrote:
> >> >>> Xen's public interface offers access to the featuresets known / found /
> >> >>> used by the hypervisor. See XEN_SYSCTL_get_cpu_featureset, accessible
> >> >>> via
On Fri, Apr 19, 2024 at 10:00 AM George Dunlap wrote:
>
> Signed-off-by: George Dunlap
> ---
> CC: Nick Rosbrook
> CC: Anthony PERARD
> ---
> tools/golang/xenlight/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
On Fri, Apr 19, 2024 at 10:00 AM George Dunlap wrote:
>
> Go has always interpreted a comment directly before a function as a
> docstring, so having the C function prototypes which the golang method
> is meant to wrap in the comment before was always a bit non-standard.
> However, recent versions
On Fri, Jul 7, 2023 at 3:56 PM George Dunlap wrote:
>> >>> Xen's public interface offers access to the featuresets known / found /
>> >>> used by the hypervisor. See XEN_SYSCTL_get_cpu_featureset, accessible
>> >>> via xc_get_cpu_featureset().
>> >>>
>> >>
>> >> Are any of these exposed in dom0
On Fri, Apr 19, 2024 at 10:00 AM George Dunlap wrote:
>
> In a handful of cases, it was decided to return a pointer to a
> structure rather than the plain structure itself, due to the size.
> However, in these cases the structure was never allocated, leading to
> a nil pointer exception when
Hi all,
The last posting date for Xen 4.19 is Apr 26, 2024. If you want your
features to be included for the release, please make sure they are
posted for the first time before Fri Apr 26, 2024.
Have a good weekned!
Best regards,
Oleksii
On 19.04.2024 12:50, Roger Pau Monné wrote:
> On Fri, Apr 19, 2024 at 12:15:19PM +0200, Jan Beulich wrote:
>> On 19.04.2024 12:02, Roger Pau Monne wrote:
>>> Livepatch payloads containing symbols that belong to init sections can only
>>> lead to page faults later on, as by the time the livepatch
On 19.04.2024 12:16, Andrew Cooper wrote:
> On 19/04/2024 11:12 am, Jan Beulich wrote:
>> On 19.04.2024 12:08, Andrew Cooper wrote:
>>> On 19/04/2024 11:02 am, Roger Pau Monne wrote:
Start by declaring the beginning and end of the init section.
No functional change intended.
On 19.04.2024 15:01, Nicola Vetrini wrote:
> On 2024-04-19 11:21, Jan Beulich wrote:
>> On 19.04.2024 09:49, Nicola Vetrini wrote:
>>> On 2024-04-19 09:35, Jan Beulich wrote:
On 19.04.2024 09:16, Nicola Vetrini wrote:
> The ECLAIR service STD.emptrecd is being deprecated; hence, as a
Update the argument of the as-insn for the Zbb case to verify that
Zbb is supported not only by a compiler, but also by an assembler.
Also, check-extenstion(ext_name, "insn") helper macro is introduced
to check whether extension is supported by a compiler and an assembler.
Signed-off-by: Oleksii
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
CC: Anthony PERARD
---
tools/golang/xenlight/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index c5bb6b94a8..645e7b3a82 100644
--- a/tools/golang/xenlight/Makefile
In a handful of cases, it was decided to return a pointer to a
structure rather than the plain structure itself, due to the size.
However, in these cases the structure was never allocated, leading to
a nil pointer exception when calling the relevant `fromC` method.
Allocate structures before
Go has always interpreted a comment directly before a function as a
docstring, so having the C function prototypes which the golang method
is meant to wrap in the comment before was always a bit non-standard.
However, recent versions of `go fmt` now attempt to normalize these
docstrings as well,
On 2024-04-19 11:21, Jan Beulich wrote:
On 19.04.2024 09:49, Nicola Vetrini wrote:
On 2024-04-19 09:35, Jan Beulich wrote:
On 19.04.2024 09:16, Nicola Vetrini wrote:
The ECLAIR service STD.emptrecd is being deprecated; hence, as a
preventive
measure, STD.anonstct is used here, which for Xen's
Thank you for the fast response, George. I can confirm that I can call all
three functions without errors now and this patch fixes the errors I
encountered.
Am 19. April 2024 12:50:35 MESZ schrieb George Dunlap :
>In a handful of cases, it was decided to return a pointer to a
>structure rather
On 4/19/24 12:08, Pavel Begunkov wrote:
Please, don't take directly, conflicts with io_uring.
When everyone is happy with the patches, Jens and Jakub will hopefully
help to merge them. E.g. first staging net/ specific changes [1] and then
handling all conflicts on the io_uring side.
[1]
At the moment an skb can only have one ubuf_info associated with it,
which might be a performance problem for zerocopy sends in cases like
TCP via io_uring. Add a callback for assigning ubuf_info to skb, this
way we will implement smarter assignment later like linking ubuf_info
together.
Note,
The network stack allows only one ubuf_info per skb, and unlike
MSG_ZEROCOPY, each io_uring zerocopy send will carry a separate
ubuf_info. That means that send requests can't reuse a previosly
allocated skb and need to get one more or more of new ones. That's fine
for large sends, but otherwise it
Please, don't take directly, conflicts with io_uring.
To have per request buffer notifications each zerocopy io_uring send
request allocates a new ubuf_info. However, as an skb can carry only
one uarg, it may force the stack to create many small skbs hurting
performance in many ways.
The
We'll need to associate additional callbacks with ubuf_info, introduce
a structure holding ubuf_info callbacks. Apart from a more smarter
io_uring notification management introduced in next patches, it can be
used to generalise msg_zerocopy_put_abort() and also store
->sg_from_iter, which is
io_notif_flush() is partially duplicating io_tx_ubuf_complete(), so
instead of duplicating it, make the flush call io_tx_ubuf_complete.
Reviewed-by: Jens Axboe
Signed-off-by: Pavel Begunkov
---
io_uring/notif.c | 6 +++---
io_uring/notif.h | 9 +++--
2 files changed, 6 insertions(+), 9
On Fri, Apr 19, 2024 at 11:59 AM George Dunlap wrote:
>
> No functional change.
>
> Signed-off-by: George Dunlap
> ---
> CC: Nick Rosbrook
> CC: Anthony PERARD
> ---
> tools/golang/xenlight/xenlight.go | 55 +--
> 1 file changed, 30 insertions(+), 25 deletions(-)
>
No functional change.
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
CC: Anthony PERARD
---
tools/golang/xenlight/xenlight.go | 55 +--
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/tools/golang/xenlight/xenlight.go
In a handful of cases, it was decided to return a pointer to a
structure rather than the plain structure itself, due to the size.
However, in these cases the structure was never allocated, leading to
a nil pointer exception when calling the relevant `fromC` method.
Allocate structures before
Signed-off-by: George Dunlap
---
CC: Nick Rosbrook
CC: Anthony PERARD
---
tools/golang/xenlight/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
index c5bb6b94a8..645e7b3a82 100644
--- a/tools/golang/xenlight/Makefile
On Fri, Apr 19, 2024 at 12:15:19PM +0200, Jan Beulich wrote:
> On 19.04.2024 12:02, Roger Pau Monne wrote:
> > Livepatch payloads containing symbols that belong to init sections can only
> > lead to page faults later on, as by the time the livepatch is loaded init
> > sections have already been
On Fri, Apr 19, 2024 at 11:10:33AM +0100, Andrew Cooper wrote:
> On 19/04/2024 11:02 am, Roger Pau Monne wrote:
> > Livepatch payloads containing symbols that belong to init sections can only
> > lead to page faults later on, as by the time the livepatch is loaded init
> > sections have already
On Fri, 2024-04-19 at 12:26 +0200, Oleksii Kurochko wrote:
> Update the argument of the as-insn for the Zbb case to verify that
> Zbb is supported not only by a compiler, but also by an assembler.
>
> Also, check_extenstion(ext_name, "insn") helper macro is introduced
> to check whether extension
Update the argument of the as-insn for the Zbb case to verify that
Zbb is supported not only by a compiler, but also by an assembler.
Also, check_extenstion(ext_name, "insn") helper macro is introduced
to check whether extension is supported by a compiler and an assembler.
Signed-off-by: Oleksii
18.04.24 14:16, Jan Beulich:
On 16.04.2024 08:20, Sergiy Kibrik wrote:
From: Xenia Ragiadakou
Introduce two new Kconfig options, SVM and VMX, to allow code
specific to each virtualization technology to be separated and, when not
required, stripped.
CONFIG_SVM will be used to enable virtual
On 19/04/2024 11:12 am, Jan Beulich wrote:
> On 19.04.2024 12:08, Andrew Cooper wrote:
>> On 19/04/2024 11:02 am, Roger Pau Monne wrote:
>>> Start by declaring the beginning and end of the init section.
>>>
>>> No functional change intended.
>>>
>>> Requested-by: Andrew Cooper
>>> Signed-off-by:
On 19.04.2024 12:02, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
>
> Refuse to resolve such symbols and return an error instead.
On 19.04.2024 12:08, Andrew Cooper wrote:
> On 19/04/2024 11:02 am, Roger Pau Monne wrote:
>> Start by declaring the beginning and end of the init section.
>>
>> No functional change intended.
>>
>> Requested-by: Andrew Cooper
>> Signed-off-by: Roger Pau Monné
>
> TYVM for doing this. There's
On 19/04/2024 11:02 am, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
>
> Refuse to resolve such symbols and return an error
On 19/04/2024 11:02 am, Roger Pau Monne wrote:
> Start by declaring the beginning and end of the init section.
>
> No functional change intended.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
TYVM for doing this. There's a lot of cleanup which can follow on for it.
Start by declaring the beginning and end of the init section.
No functional change intended.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/arch/arm/mmu/setup.c | 3 +--
xen/arch/x86/setup.c | 3 +--
xen/include/xen/sections.h | 17 +
3 files
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
Hello,
Previously a single patch, now with a pre-patch to place the init
section markers into a common file.
Thanks, Roger.
Roger Pau Monne (2):
xen: introduce header file with section related symbols
livepatch: refuse to resolve symbols that belong to init sections
flight 185738 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185738/
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
flight 185736 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185736/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185641
test-amd64-amd64-libvirt-xsm 15
On 19.04.2024 09:42, Roger Pau Monné wrote:
> On Tue, Apr 02, 2024 at 11:49:20AM +0200, Jan Beulich wrote:
>> On 28.03.2024 16:35, Roger Pau Monne wrote:
>>> There's no reason to assume VGA text mode 3 to be unconditionally available.
>>> With the addition of booting Xen itself in PVH mode there's
On 19.04.2024 09:49, Nicola Vetrini wrote:
> On 2024-04-19 09:35, Jan Beulich wrote:
>> On 19.04.2024 09:16, Nicola Vetrini wrote:
>>> The ECLAIR service STD.emptrecd is being deprecated; hence, as a
>>> preventive
>>> measure, STD.anonstct is used here, which for Xen's purposes has
>>>
18.04.24 14:31, Jan Beulich:
On 16.04.2024 08:25, Sergiy Kibrik wrote:
Use altp2m index only when it is supported by the platform, i.e. VMX.
The puspose of that is the possiblity to disable VMX support and
exclude its code from the build completely.
I'm afraid this description doesn't make
On Fri, Apr 19, 2024 at 09:34:21AM +0100, Anthony PERARD wrote:
> On Mon, Apr 08, 2024 at 10:29:08AM +0100, Anthony PERARD wrote:
> > On Fri, Apr 05, 2024 at 04:54:30PM +0100, Anthony PERARD wrote:
> > > On Thu, Mar 28, 2024 at 05:54:04PM +, Anthony PERARD wrote:
> > > > On Mon, Mar 18, 2024
On Mon, Apr 08, 2024 at 10:29:08AM +0100, Anthony PERARD wrote:
> On Fri, Apr 05, 2024 at 04:54:30PM +0100, Anthony PERARD wrote:
> > On Thu, Mar 28, 2024 at 05:54:04PM +, Anthony PERARD wrote:
> > > On Mon, Mar 18, 2024 at 04:55:09PM +, Anthony PERARD wrote:
> >
> > I've now pushed
> >
18.04.24 14:18, Jan Beulich:
On 16.04.2024 08:22, Sergiy Kibrik wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -156,9 +156,9 @@ static int __init cf_check hvm_enable(void)
{
const struct hvm_function_table *fns = NULL;
-if ( cpu_has_vmx )
+if (
On 2024-04-19 09:35, Jan Beulich wrote:
On 19.04.2024 09:16, Nicola Vetrini wrote:
The ECLAIR service STD.emptrecd is being deprecated; hence, as a
preventive
measure, STD.anonstct is used here, which for Xen's purposes has
equivalent
functionality.
I'm sorry, but no, this still does not
On Tue, Apr 02, 2024 at 11:49:20AM +0200, Jan Beulich wrote:
> On 28.03.2024 16:35, Roger Pau Monne wrote:
> > There's no reason to assume VGA text mode 3 to be unconditionally available.
> > With the addition of booting Xen itself in PVH mode there's a boot path that
> > explicitly short-circuits
On 19.04.2024 09:16, Nicola Vetrini wrote:
> The ECLAIR service STD.emptrecd is being deprecated; hence, as a preventive
> measure, STD.anonstct is used here, which for Xen's purposes has equivalent
> functionality.
I'm sorry, but no, this still does not clarify things enough. It is still
On 19.04.2024 09:05, Nicola Vetrini wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -457,6 +457,7 @@ static int domain_teardown(struct domain *d)
>
> for_each_vcpu ( d, v )
> {
> +/* SAF-5-safe MISRA C Rule 16.2: switch label enclosed by for
>
On Tue, Apr 02, 2024 at 11:43:49AM +0200, Jan Beulich wrote:
> On 02.04.2024 11:38, Jan Beulich wrote:
> > On 28.03.2024 16:35, Roger Pau Monne wrote:
> >> Currently the offsets into the boot_video_info struct are manually encoded
> >> in
> >> video.S, which is fragile. Generate them in
The ECLAIR service STD.emptrecd is being deprecated; hence, as a preventive
measure, STD.anonstct is used here, which for Xen's purposes has equivalent
functionality. This new service is already supported by the current version
of ECLAIR.
No functional change.
Signed-off-by: Nicola Vetrini
MISRA C Rule 16.2 states:
"A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement".
The PROGRESS_VCPU local helper specifies a case that is directly
inside the compound statement of a for loop, hence violating the rule.
To avoid
flight 185731 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185731/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185712
On 18.04.2024 18:07, Jason Andryuk wrote:
> Switch to unsigned int for the dom0 e820 index. This eliminates the
> potential for array underflows, and the compiler might be able to
> generate better code.
>
> Requested-by: Jan Beulich
> Signed-off-by: Jason Andryuk
Acked-by: Jan Beulich
18.04.24 14:36, Jan Beulich:
On 16.04.2024 08:29, Sergiy Kibrik wrote:
Move altp2m code from generic p2m.c file to altp2m.c, so that VMX-specific
code is kept separately and can possibly be disabled in the build.
The code movement is desirable, but the reasoning isn't quite right (see
replies
Hi Jan,
On 4/19/2024 2:18 PM, Jan Beulich wrote:
On 19.04.2024 04:31, Henry Wang wrote:
On 4/18/2024 8:54 PM, Jan Beulich wrote:
On 09.04.2024 06:53, Henry Wang wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -21,6 +21,7 @@
#define XENMEM_increase_reservation
On 18.04.2024 20:33, Andrew Cooper wrote:
> On 18/04/2024 8:39 am, Jan Beulich wrote:
>> On 15.04.2024 17:44, Andrew Cooper wrote:
>>> On 15/04/2024 10:56 am, Federico Serafini wrote:
Mark the whole gzip folder as adopted code and remove the redundant
deviation of file inflate.
On 18.04.2024 17:52, Roger Pau Monne wrote:
> It's currently too restrictive by just checking whether there's a BHB clearing
> sequence selected. It should instead check whether BHB clearing is used on
> entry from PV or HVM specifically.
>
> Switch to use opt_bhb_entry_{pv,hvm} instead, and
On 19.04.2024 04:31, Henry Wang wrote:
> On 4/18/2024 8:54 PM, Jan Beulich wrote:
>> On 09.04.2024 06:53, Henry Wang wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -21,6 +21,7 @@
>>> #define XENMEM_increase_reservation 0
>>> #define
On 19.04.2024 04:27, Henry Wang wrote:
> On 4/18/2024 8:37 PM, Jan Beulich wrote:
>> On 09.04.2024 06:53, Henry Wang wrote:
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -223,6 +223,13 @@ typedef uint64_t xen_pfn_t;
>>>*/
>>> #define
66 matches
Mail list logo
