flight 174986 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174986/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c8c978d32882413eeaf2b9917409af83af68cb5d
baseline version:
ovmf ae3bc559f98e68983df0a
flight 174984 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174984/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken in 174977
Tests whi
A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/
This commit is to drop redundancy in the function vpl011_mmio_write
and vpl011_mmio_read:
- In vpl011_mmio_read switch block, all cases have a return. So the
outside one can be removed.
- Each switch case checks access by the same if statments. So we can
just use one and put it before the switc
When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
Linux SBSA PL011 driver will access PL011 DMACR register in some
functions. As chapter "B Generic UART" in "ARM Server Base System
Architecture"[1] documentation describes, SBSA UART doesn't support
DMA. In current code, when the
Hi all,
This patch is the version 3 for "xen/arm: vpl011: Make access to DMACR
write-ignore" [1].
[1]
https://patchwork.kernel.org/project/xen-devel/patch/20221122054644.1092173-1-jiamei@arm.com/
Thanks,
Jiamei Xie
v2 -> v3
- emulate non-SBSA registers as WI/RAZ in default case
- update c
flight 174983 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174983/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae3bc559f98e68983df0a4b223dad7afeb6eee2c
baseline version:
ovmf d992163da6cb3c6e91c24
flight 174982 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174982/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
On Mon, Nov 28, 2022 at 11:18:00AM -0500, Alex Deucher wrote:
> On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
> wrote:
> >
> > Dear Christian:
> >
> > What is the status of the AMDGPU work for Xen dom0? That was mentioned in
> > https://lore.kernel.org/dri-devel/b2dec9b3-03a7-e7ac-306e-1da02
On Mon, 28 Nov 2022, Luca Fancellu wrote:
> This serie introduces a way to suppress a static analyser finding providing a
> proper justification for it.
> The process is explained in the docs/misra/documenting-violations.rst document
> that this serie will provide.
> The tools currently supported a
On Mon, 28 Nov 2022, Luca Fancellu wrote:
> Eclair and Coverity found violation of the MISRA rule 8.6 for the
> symbols _start, _end, start, _stext, _etext, _srodata, _erodata,
> _sinittext, _einittext which are declared in
> xen/include/xen/kernel.h.
> All those symbols are defined by the liker sc
On Mon, 28 Nov 2022, Luca Fancellu wrote:
> Add new script for coverity/eclair analysis tool that will enable
> the procedure to suppress findings when these tool are used.
> The procedure is documented in docs/misra/documenting-violations.rst
> and the script is documented in docs/misra/xen-static
From: Stefano Stabellini
Add the new MISRA C rules agreed by the MISRA C working group to
docs/misra/rules.rst.
Add a comment for Rule 19.1 to explain that Eclair's findings are
"caution" reports, not violations.
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 36
flight 174981 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174981/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174767
test-amd64-amd64-qemuu-nested-am
flight 174979 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken
test-arm64-arm64-examine 8 reboo
On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
wrote:
>
> Dear Christian:
>
> What is the status of the AMDGPU work for Xen dom0? That was mentioned in
> https://lore.kernel.org/dri-devel/b2dec9b3-03a7-e7ac-306e-1da024af8...@amd.com/
> and there have been bug reports to Qubes OS about problem
Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR[31:0].
AArch64 System register ICH_LR_EL2 bits [63:32] are architecturally
mapped to AArch32 System register ICH_L
Define missing assembly aliases for GIC registers on arm32, taking the ones
defined already for arm64 as a base. Aliases are defined according to the
GIC Architecture Specification ARM IHI 0069H.
Defined the following registers:-
1. Interrupt Controller Interrupt Priority Mask Register
2. Interrup
One can now use GICv3 on AArch32 systems. However, ITS is not supported.
The reason being currently we are trying to validate GICv3 on an AArch32_v8R
system. Refer ARM DDI 0568A.c ID110520, B1.3.1,
"A Generic Interrupt Controller (GIC) implemented with an Armv8-R PE must not
implement LPI support."
On AArch32, ldrd/strd instructions are not atomic when used to access MMIO.
Furthermore, ldrd/strd instructions are not decoded by Arm when running as
a guest to access emulated MMIO region.
Thus, we have defined readq_relaxed_non_atomic()/writeq_relaxed_non_atomic()
which in turn calls readl_relax
Refer "Arm IHI 0069H ID020922", 12.4.6, Interrupt Controller List Registers
AArch64 System register ICH_LR_EL2 bits [31:0] are architecturally
mapped to AArch32 System register ICH_LR[31:0].
AArch64 System register ICH_LR_EL2 bits [63:32] are architecturally
mapped to AArch32 System register ICH_L
Adapt save_aprn_regs()/restore_aprn_regs() for AArch32.
For which we have defined the following registers:-
1. Interrupt Controller Hyp Active Priorities Group0 Registers 0-3
2. Interrupt Controller Hyp Active Priorities Group1 Registers 0-3
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
AArch32 systems. Thus, the function needs to change to reflect this.
The reason being 'register_t' is defined as 'u32' on AArch32.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
---
Chan
'unsigned long long' is defined as 64 bit across both AArch32 and AArch64.
So, use 'ULL' for 64 bit word instead of UL which is 32 bits for AArch32.
GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
---
Refer ARM DDI 0487I.a ID081822, G8-9650, G8.2.113
Aff3 does not exist on AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-1644, B4.1.106
Aff3 does not exist on Armv7 (ie arm32).
Thus, access to aff3 has been protected with "#ifdef CONFIG_ARM_64".
Also, v->arch.vmpidr is a 32 bit register on AArch
In some situations (e.g. GICR_TYPER), the hypervior may need to emulate
64bit registers in AArch32 mode. In such situations, the hypervisor may
need to read/modify the lower or upper 32 bits of the 64 bit register.
In AArch32, 'unsigned long' is 32 bits. Thus, we cannot use it for 64 bit
registers
Sysreg emulation is 64-bit specific, so guard the calls to
vgic_v3_emulate_sysreg() as well as the function itself with
"#ifdef CONFIG_ARM_64".
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
---
Changes from -
v1 - 1. Updated the commit message.
v2 - 1. Upda
Refer ARM DDI 0487I.a ID081822, G8-9817, G8.2.169
Affinity level 3 is not present in AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-1644, B4.1.106,
Affinity level 3 is not present in Armv7 (ie arm32).
Thus, any access to affinity level 3 needs to be guarded within
"ifdef CONFIG_ARM_64".
Signed-
Hi All,
Please find the following patches to enable GICv3 for AArch32.
This is a pre-requisite to support Xen on Cortex-R52 (AArch32-v8R system)
Let me know your thoughts.
Changes from -
v1 :-
1. Updated in the changelog for each of the patches.
v2 :-
1. Dropped "xen/Arm: GICv3: Move the macr
> On 28 Nov 2022, at 15:19, Jan Beulich wrote:
>
> On 28.11.2022 15:10, Luca Fancellu wrote:
>> Change cppcheck invocation method by using the xen-analysis.py
>> script using the arguments --run-cppcheck.
>>
>> Now cppcheck analysis will build Xen while the analysis is performed
>> on the sour
On 28.11.2022 15:10, Luca Fancellu wrote:
> Eclair and Coverity found violation of the MISRA rule 8.6 for the
> symbols _start, _end, start, _stext, _etext, _srodata, _erodata,
> _sinittext, _einittext which are declared in
> xen/include/xen/kernel.h.
> All those symbols are defined by the liker sc
On 28.11.2022 15:10, Luca Fancellu wrote:
> Change cppcheck invocation method by using the xen-analysis.py
> script using the arguments --run-cppcheck.
>
> Now cppcheck analysis will build Xen while the analysis is performed
> on the source files, it will produce a text report and an additional
>
Eclair and Coverity found violation of the MISRA rule 8.6 for the
symbols _start, _end, start, _stext, _etext, _srodata, _erodata,
_sinittext, _einittext which are declared in
xen/include/xen/kernel.h.
All those symbols are defined by the liker script so we can deviate
from the rule 8.6 for these c
Add new script for coverity/eclair analysis tool that will enable
the procedure to suppress findings when these tool are used.
The procedure is documented in docs/misra/documenting-violations.rst
and the script is documented in docs/misra/xen-static-analysis.rst.
Add in docs/misra/ the files safe.
Change cppcheck invocation method by using the xen-analysis.py
script using the arguments --run-cppcheck.
Now cppcheck analysis will build Xen while the analysis is performed
on the source files, it will produce a text report and an additional
html output when the script is called with --cppcheck-
Currently the script convert_misra_doc.py is using a loop through
range(1,22) to enumerate rules that needs to be skipped, however
range function does not include the stop counter in the enumeration
ending up into list rules until 21.21 instead of including rule 22.
Fix the issue using a dictionar
This serie introduces a way to suppress a static analyser finding providing a
proper justification for it.
The process is explained in the docs/misra/documenting-violations.rst document
that this serie will provide.
The tools currently supported are eclair, coverity and cppcheck, but the design
is
On Mon, Nov 21, 2022 at 05:16:37PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Nov 21, 2022 at 10:41:34AM -0500, Jason Andryuk wrote:
> > On Sat, Nov 19, 2022 at 11:33 AM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Sat, Nov 19, 2022 at 09:36:54AM -0500, Jason Andryuk wrote:
> > > >
On 11/11/2022 17:53, Julien Grall wrote:
Hi,
Hi Julien,
I need a clarification.
On 11/11/2022 17:37, Ayan Kumar Halder wrote:
On 11/11/2022 16:17, Xenia Ragiadakou wrote:
Hi Ayan,
Hi Xenia,
On 11/11/22 16:17, Ayan Kumar Halder wrote:
On AArch32, ldrd/strd instructions are not atomic
On 28.11.2022 12:06, Roger Pau Monné wrote:
> On Mon, Nov 28, 2022 at 09:21:47AM +0100, Jan Beulich wrote:
>> On 26.11.2022 23:19, Julien Grall wrote:
>>> On 25/11/2022 14:15, Per Bilse wrote:
This patch modifies ioreq_broadcast() to allow partial success.
>>>
>>> The commit message is quite v
On Mon, Nov 28, 2022 at 09:56:58AM +, osstest service owner wrote:
> flight 174977 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/174977/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not b
On Mon, Nov 28, 2022 at 09:21:47AM +0100, Jan Beulich wrote:
> On 26.11.2022 23:19, Julien Grall wrote:
> > On 25/11/2022 14:15, Per Bilse wrote:
> >> A change to XAPI varstored causes
> >
> > For those unfamiliar with XAPI (like me), can you explain what was the
> > change made?
One ioreq clien
flight 174980 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174980/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d992163da6cb3c6e91c24938ad4b8804227eafd8
baseline version:
ovmf 85d805ed3201de16c4dcb
All,
the release is due in a couple of weeks time; ideally we'd get it out
before the year end break.
Please point out backports you find missing from the respective staging
branch, but which you consider relevant.
Jan
On 28/11/2022 08:21, Jan Beulich wrote:
> On 26.11.2022 23:19, Julien Grall wrote:
>>
>> The commit message is quite vague, so it is hard to know what you are
>> trying to solve exactly. AFAIU, there are two reasons for
>> ioreq_broadcast to fails:
>>1) The IOREQ server didn't register the bufi
flight 174977 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174977/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel broken
Tests which are
On 22/11/2022 20:37, Julien Grall wrote:
Hi Ayan,
Hi Julien,
I need a clarification.
On 11/11/2022 14:17, Ayan Kumar Halder wrote:
Refer ARM DDI 0487I.a ID081822, G8-9650, G8.2.113
Aff3 does not exist on AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-1644, B4.1.106
Aff3 does not exist
Hi Viresh,
On 25/11/2022 06:45, Viresh Kumar wrote:
On 24-11-22, 20:19, Julien Grall wrote:
Unfortunately, we had some delay for releasing 4.17. So I have pushed this
series in a branch for-next/4.18.
Thanks.
This will be applied to staging once the
tree has re-opened.
I don't see the bra
On 27/11/2022 14:32, Ayan Kumar Halder wrote:
On 17/11/2022 13:39, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 11/11/2022 15:17, Ayan Kumar Halder wrote:
Refer ARM DDI 0487I.a ID081822, G8-9817, G8.2.169
Affinity level 3 is not present in AArch32.
Also, refer ARM DDI 0406C.d ID040418, B4-
flight 174976 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174976/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174963
test-armhf-armhf-libvirt 16 sav
On 24.11.2022 22:29, Julien Grall wrote:
> On 19/10/2022 09:43, Jan Beulich wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1563,7 +1563,82 @@ int map_guest_area(struct vcpu *v, paddr
>> struct guest_area *area,
>> void (*populate)(v
flight 174978 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174978/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85d805ed3201de16c4dcbfc4b886a0d11ad5885c
baseline version:
ovmf 6ae2b6648eb4b42b5a133
flight 174975 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174975/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
On 26.11.2022 23:19, Julien Grall wrote:
> On 25/11/2022 14:15, Per Bilse wrote:
>> A change to XAPI varstored causes
>
> For those unfamiliar with XAPI (like me), can you explain what was the
> change made?
>
>> an unnecessary error message
>> to be logged in hypervisor.log whenever an RTC time
54 matches
Mail list logo
