flight 184734 linux-6.1 real [real]
flight 184747 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184734/
http://logs.test-lab.xenproject.org/osstest/logs/184747/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Fri, 23 Feb 2024 15:22:38 -0800 (PST) Stefano Stabellini
:
> Do you have a successful gitlab pipeline with this patch applied that
> you can give me as proof of testing and success?
Yes, all of them since the patch went out.
Olaf
pgpzXM2EomBWs.pgp
Description: Digitale Signatur von OpenPGP
flight 184745 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184745/
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
From: Alexei Starovoitov
vmap/vmalloc APIs are used to map a set of pages into contiguous kernel virtual
space.
get_vm_area() with appropriate flag is used to request an area of kernel
address range.
It'se used for vmalloc, vmap, ioremap, xen use cases.
- vmalloc use case dominates the usage.
From: Alexei Starovoitov
There are various users of get_vm_area() + ioremap_page_range() APIs.
Enforce that get_vm_area() was requested as VM_IOREMAP type and range passed to
ioremap_page_range() matches created vm_area to avoid accidentally ioremap-ing
into wrong address range.
Signed-off-by:
Dear All,
We send you a message few days ago.
We have major performance with XEN USB Drivers. We use your driver to load data
in a device and we need USB3 High Speed USB protocole
Do you have a new issue of the HCI and NEC USB Xen Driver ?
We hope you will contact us quickly.
Best regards
From: Alexei Starovoitov
xen grant table and xenbus ring are not ioremap the way arch specific code is
using it,
so let's add VM_XEN flag to separate them from VM_IOREMAP users.
xen will not and should not be calling ioremap_page_range() on that range.
/proc/vmallocinfo will print such region
From: Alexei Starovoitov
There are various users of kernel virtual address space: vmalloc, vmap,
ioremap, xen.
- vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag
and these areas are treated differently by KASAN.
- the areas created by vmap() function should be tagged
On Wed, 13 Dec 2023, Olaf Hering wrote:
> https://build.opensuse.org/request/show/1126240
>
> Signed-off-by: Olaf Hering
Hi Olaf,
Do you have a successful gitlab pipeline with this patch applied that
you can give me as proof of testing and success?
> ---
>
Shawn,
I am thinking of committing this, if you disagree please say something
in the next couple of days
On Tue, 19 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
> headline states:
> "A conversion shall
On Fri, 23 Feb 2024, Nicola Vetrini wrote:
> On 2024-02-19 16:14, Nicola Vetrini wrote:
> > The cache clearing and invalidation helpers in x86 and Arm didn't
> > comply with MISRA C Rule 17.7: "The value returned by a function
> > having non-void return type shall be used". On Arm they
> > were
On Fri, 23 Feb 2024, Nicola Vetrini wrote:
> Refactor cpu_notifier_call_chain into two functions:
> - the variant that is allowed to fail loses the nofail flag
> - the variant that shouldn't fail is encapsulated in a call
> to the failing variant, with an additional check.
>
> This prevents
flight 184739 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184739/
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
On Fri, 23 Feb 2024, Nicola Vetrini wrote:
> These functions never saw a usage of their return value since
> they were introduced, so it can be dropped since their usages
> violate MISRA C Rule 17.7:
> "The value returned by a function having non-void return type shall be used".
>
> No functional
On Fri, 23 Feb 2024, Federico Serafini wrote:
> Update ECLAIR configuration to fully deviate Rules 5.7 and 18.7
> as agreed during MISRA meeetings.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/deviations.ecl | 14
On Fri, 23 Feb 2024, Federico Serafini wrote:
> Update ECLAIR configuration to consider Rule 8.2 as clean.
>
> Signed-off-by: Federico Serafini
Acked-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Fri, 23 Feb 2024, Jan Beulich wrote:
> On 23.02.2024 02:32, Stefano Stabellini wrote:
> > On Tue, 24 Oct 2023, Jan Beulich wrote:
> >> On 24.10.2023 00:05, Stefano Stabellini wrote:
> >>> On Mon, 23 Oct 2023, Jan Beulich wrote:
> On 23.10.2023 17:23, Simone Ballarin wrote:
> > On
On Fri, 23 Feb 2024, Chen, Jiqian wrote:
> On 2024/2/23 08:40, Stefano Stabellini wrote:
> > On Fri, 12 Jan 2024, Jiqian Chen wrote:
> >> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
> >> a passthrough device by using gsi, see
> >> xen_pt_realize->xc_physdev_map_pirq and
> >>
flight 184733 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184733/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeatfail like 184511
test-amd64-amd64-xl-qemut-win7-amd64
Hi Peng,
We haven't tried to setup virtio-vsock yet.
In general, I am very supportive of using QEMU for virtio backends. We
use QEMU to provide virtio-net, virtio-block, virtio-console and more.
However, typically virtio-vsock comes into play for VM-to-VM
communication, which is different.
On Mon, 2024-02-19 at 09:06 +0100, Jan Beulich wrote:
> On 16.02.2024 12:16, Oleksii wrote:
> > On Thu, 2024-02-15 at 17:43 +0100, Jan Beulich wrote:
> > > On 15.02.2024 17:38, Oleksii wrote:
> > > > On Tue, 2024-02-13 at 14:33 +0100, Jan Beulich wrote:
> > > > > On 05.02.2024 16:32, Oleksii
On Thu, Feb 22, 2024 at 07:22:45AM +, Chen, Jiqian wrote:
> On 2024/2/21 23:03, Anthony PERARD wrote:
> > On Fri, Jan 12, 2024 at 02:13:17PM +0800, Jiqian Chen wrote:
> >> diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
> >> index a1c6e82631e9..4136a860a048 100644
> >>
Hi,
On 20/02/2024 12:17, Ayan Kumar Halder wrote:
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an undefined
flight 184732 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184732/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184729
flight 184736 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184736/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 11ad164bcea6b0ed3628d595090f84892c367086
baseline version:
ovmf
On Fri, Feb 23, 2024 at 09:45:15AM +, Ross Lagerwall wrote:
> On Thu, Nov 30, 2023 at 2:30 PM Roger Pau Monne wrote:
> >
> > 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
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
flight 184731 linux-linus real [real]
flight 184735 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184731/
http://logs.test-lab.xenproject.org/osstest/logs/184735/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 23.02.2024 13:18, Roger Pau Monné wrote:
> On Fri, Feb 23, 2024 at 11:43:14AM +0100, Jan Beulich wrote:
>> On 23.02.2024 10:19, Roger Pau Monné wrote:
>>> On Thu, Feb 22, 2024 at 05:55:00PM +0100, Jan Beulich wrote:
On 22.02.2024 17:44, Roger Pau Monne wrote:
> ---
>
> > > > As 1- and 2-byte cases are emulated I decided that is not to
> > > > provide
> > > > sfx argument for emulation macros as it will not have to much
> > > > affect on
> > > > emulated types and just consume more performance on acquire and
> > > > release
> > > > version of sc/ld
On Fri, Feb 23, 2024 at 11:43:14AM +0100, Jan Beulich wrote:
> On 23.02.2024 10:19, Roger Pau Monné wrote:
> > On Thu, Feb 22, 2024 at 05:55:00PM +0100, Jan Beulich wrote:
> >> On 22.02.2024 17:44, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/include/asm/alternative.h
> >>> +++
Hi All,
Has anyone make virtio-vsock on xen work? My dm args as below:
virtio = [
'backend=0,type=virtio,device,transport=pci,bdf=05:00.0,backend_type=qemu,grant_usage=true'
]
device_model_args = [
'-D', '/home/root/qemu_log.txt',
'-d',
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.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/spec_ctrl.c | 5 +
1
On 23/02/2024 11:35 am, Edwin Torok wrote:
>> On 31 Jan 2024, at 16:27, Edwin Torok wrote:
>>> On 31 Jan 2024, at 11:17, Christian Lindig
>>> wrote:
On 31 Jan 2024, at 10:52, Edwin Török wrote:
Now that we no longer have a hashtable inside we can make Quota.t pure,
and push
'*' sets the width field, which is the minimum number of characters to output,
but what we want in no_config_param() is the precision instead, which is '.*'
as it imposes a maximum limit on the output.
Fixes: 68d757df8dd2 ('x86/pv: Options to disable and/or compile out 32bit PV
support')
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH')
Signed-off-by: Roger
Hello,
A couple of improvements for the spec-ctrl command line parsing, and one
bugfix for no_config_param().
Thanks, Roger.
Roger Pau Monne (3):
xen/cmdline: fix printf format specifier in no_config_param()
x86/spec: fix BRANCH_HARDEN option to only be set when build-enabled
x86/spec:
> On 31 Jan 2024, at 16:27, Edwin Torok wrote:
>
>
>
>> On 31 Jan 2024, at 11:17, Christian Lindig
>> wrote:
>>
>>
>>
>>> On 31 Jan 2024, at 10:52, Edwin Török wrote:
>>>
>>> Now that we no longer have a hashtable inside we can make Quota.t pure,
>>> and push the mutable update to its
On 23/02/2024 11:11 am, Roger Pau Monné wrote:
> On Fri, Feb 23, 2024 at 10:26:15AM +, Andrew Cooper wrote:
>> On 23/02/2024 10:17 am, Roger Pau Monné wrote:
>>> On Fri, Feb 23, 2024 at 09:46:27AM +, Andrew Cooper wrote:
On 23/02/2024 9:42 am, Roger Pau Monne wrote:
> The current
On Fri, Feb 23, 2024 at 10:26:15AM +, Andrew Cooper wrote:
> On 23/02/2024 10:17 am, Roger Pau Monné wrote:
> > On Fri, Feb 23, 2024 at 09:46:27AM +, Andrew Cooper wrote:
> >> On 23/02/2024 9:42 am, Roger Pau Monne wrote:
> >>> The current logic to handle the BRANCH_HARDEN option will
On 30.11.2023 15:29, Roger Pau Monne wrote:
> 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
On Fri, Feb 23, 2024 at 10:35:50AM +, Andrew Cooper wrote:
> Right now, there's a mixup over the xen/ part of the path for new files.
>
> + NEW_FILES=./arch/x86/lp-hooks.o
> + for i in '$NEW_FILES'
> ++ dirname ./arch/x86/lp-hooks.o
> + mkdir -p output/./arch/x86
> + cp
On 23.02.2024 10:19, Roger Pau Monné wrote:
> On Thu, Feb 22, 2024 at 05:55:00PM +0100, Jan Beulich wrote:
>> On 22.02.2024 17:44, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/include/asm/alternative.h
>>> +++ b/xen/arch/x86/include/asm/alternative.h
>>> @@ -167,9 +167,25 @@ extern void
On Fri, Feb 23, 2024 at 10:35 AM Andrew Cooper
wrote:
>
> Right now, there's a mixup over the xen/ part of the path for new files.
>
> + NEW_FILES=./arch/x86/lp-hooks.o
> + for i in '$NEW_FILES'
> ++ dirname ./arch/x86/lp-hooks.o
> + mkdir -p output/./arch/x86
> + cp
Right now, there's a mixup over the xen/ part of the path for new files.
+ NEW_FILES=./arch/x86/lp-hooks.o
+ for i in '$NEW_FILES'
++ dirname ./arch/x86/lp-hooks.o
+ mkdir -p output/./arch/x86
+ cp patched/./arch/x86/lp-hooks.o output/./arch/x86/lp-hooks.o
cp: cannot stat
On Thu, Nov 30, 2023 at 2:31 PM Roger Pau Monne wrote:
>
> 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
On 23/02/2024 10:17 am, Roger Pau Monné wrote:
> On Fri, Feb 23, 2024 at 09:46:27AM +, Andrew Cooper wrote:
>> On 23/02/2024 9:42 am, Roger Pau Monne wrote:
>>> The current logic to handle the BRANCH_HARDEN option will report it as
>>> enabled
>>> even when build-time disabled. Fix this by
On Fri, Feb 23, 2024 at 09:46:27AM +, Andrew Cooper wrote:
> On 23/02/2024 9:42 am, Roger Pau Monne wrote:
> > The current logic to handle the BRANCH_HARDEN option will report it as
> > enabled
> > even when build-time disabled. Fix this by only allowing the option to be
> > set
> > when
On Thu, Nov 30, 2023 at 2:31 PM Roger Pau Monne wrote:
>
> The test code has a typo in using LIVEPATCH_APPLY_HOOK() instead of
> LIVEPATCH_REVERT_HOOK().
>
> Fixes: 6047104c3ccc ('livepatch: Add per-function applied/reverted state
> tracking marker')
> Signed-off-by: Roger Pau Monné
> ---
>
On Thu, Nov 30, 2023 at 2:30 PM Roger Pau Monne wrote:
>
> 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,
On Thu, Nov 30, 2023 at 2:30 PM Roger Pau Monne wrote:
>
> 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
>
On Fri, Feb 23, 2024 at 09:46:27AM +, Andrew Cooper wrote:
> On 23/02/2024 9:42 am, Roger Pau Monne wrote:
> > The current logic to handle the BRANCH_HARDEN option will report it as
> > enabled
> > even when build-time disabled. Fix this by only allowing the option to be
> > set
> > when
On 23/02/2024 9:42 am, Roger Pau Monne wrote:
> The current logic to handle the BRANCH_HARDEN option will report it as enabled
> even when build-time disabled. Fix this by only allowing the option to be set
> when support for it is built into Xen.
>
> Fixes: 2d6f36daa086 ('x86/nospec: Introduce
On Thu, Nov 30, 2023 at 2:30 PM Roger Pau Monne wrote:
>
> 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
> the point the livepatch is not in the virtual
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH')
Signed-off-by: Roger
Refactor cpu_notifier_call_chain into two functions:
- the variant that is allowed to fail loses the nofail flag
- the variant that shouldn't fail is encapsulated in a call
to the failing variant, with an additional check.
This prevents uses of the function that are not supposed to
fail from
MISRA C Rule 17.7 states: "The value returned by a function having non-void
return type shall be used". Therefore the functions that are subject to this
series are refactored to address these concerns.
Nicola Vetrini (2):
xen/console: drop return value from consoled_guest_rx/tx
xen/cpu:
These functions never saw a usage of their return value since
they were introduced, so it can be dropped since their usages
violate MISRA C Rule 17.7:
"The value returned by a function having non-void return type shall be used".
No functional change.
Signed-off-by: Nicola Vetrini
---
On Thu, Feb 22, 2024 at 05:55:00PM +0100, Jan Beulich wrote:
> On 22.02.2024 17:44, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/include/asm/alternative.h
> > +++ b/xen/arch/x86/include/asm/alternative.h
> > @@ -167,9 +167,25 @@ extern void alternative_branches(void);
> > #define ALT_CALL_arg5
On Tue, Jan 02, 2024 at 09:33:11PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Request Venus when initializing VirGL.
> >
> > Signed-off-by: Antonio Caggiano
> > Signed-off-by: Huang Rui
> > ---
> >
> >
Deviate Rules 5.7 and 18.7.
Tag Rule 8.2 ad clean.
Federico Serafini (2):
automation/eclair: fully deviate MISRA C:2012 Rules 5.7 and 18.7
automation/eclair: tag MISRA C:2012 Rule 8.2 as clean
automation/eclair_analysis/ECLAIR/deviations.ecl | 14 ++
Update ECLAIR configuration to consider Rule 8.2 as clean.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
Update ECLAIR configuration to fully deviate Rules 5.7 and 18.7
as agreed during MISRA meeetings.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 14 ++
1 file changed, 14 insertions(+)
diff --git
On Tue, Jan 02, 2024 at 08:49:54PM +0800, Marc-André Lureau wrote:
> Hi
>
> On Tue, Dec 19, 2023 at 11:55 AM Huang Rui wrote:
> >
> > From: Antonio Caggiano
> >
> > Enable resource UUID feature and implement command resource assign UUID.
> > This is done by introducing a hash table to map
64 matches
Mail list logo
