flight 185701 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185701/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 61185f1d501512f35621d0fdc5f17503c77bf449
baseline version:
ovmf
flight 185695 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 185285
Tests which
branch xen-4.16-testing
xenbranch xen-4.16-testing
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
flight 185674 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185674/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 12 debian-di-install fail in 185635 pass in 185674
test-amd64-amd64-xl-vhd 12
On Tue, 16 Apr 2024, Peng Fan wrote:
> > Subject: [PATCH] xen/arm: imx8qm: Re-license file to GPL-2.0-only
> >
> > New contributions are recommended to be under GPL-2.0-only [1], since this
> > code piece originally came from the NXP tree the original license was
> > retained.
> >
> > However, as
On Tue, 16 Apr 2024, Andrew Cooper wrote:
> Misra Rule 21.16 doesn't like the use of memcmp() between a string literal and
> a UINT8 array. Rewrite using plain compares.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Jan Beulich
> CC:
flight 185684 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185684/
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
branch xen-4.15-testing
xenbranch xen-4.15-testing
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid guest-saverestore
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux
Also add two specific project-wide deviations for R21.6 and R21.15.
Signed-off-by: Stefano Stabellini
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 32b02905d1..9123c8edb5 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -387,6 +387,22 @@
On Tue, Apr 16, 2024 at 3:29 AM Andrew Cooper wrote:
>
> On 16/04/2024 7:31 am, Sergiy Kibrik wrote:
> > Instead of using generic CONFIG_HVM option switch to a bit more specific
> > CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
> > altp2m routines, so that it can be
flight 185671 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185671/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fcfdbe29874320e9f876baa7afebc3fca8f4a7df
baseline version:
ovmf
Misra Rule 21.16 doesn't like the use of memcmp() between a string literal and
a UINT8 array. Rewrite using plain compares.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: consult...@bugseng.com
CC: Roberto Bagnara
CC:
flight 185641 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185641/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185412
test-amd64-amd64-libvirt-xsm 15
On 4/16/24 4:25 PM, Vaishali Thakkar wrote:
On 4/16/24 4:12 PM, Andrew Cooper wrote:
On 16/04/2024 9:54 am, Vaishali Thakkar wrote:
Currently, Xen always starts the ASID allocation at 1. But
for SEV technologies the ASID space is divided. This is
because it's a security issue if a guest is
On 4/16/24 4:12 PM, Andrew Cooper wrote:
On 16/04/2024 9:54 am, Vaishali Thakkar wrote:
Currently, Xen always starts the ASID allocation at 1. But
for SEV technologies the ASID space is divided. This is
because it's a security issue if a guest is started as
ES/SNP and is migrated to SEV-only.
On 4/16/24 3:38 PM, Andrew Cooper wrote:
On 16/04/2024 10:08 am, Vaishali Thakkar wrote:
TLB Flush by ASID is missing in the list of supported features
here. So, add it.
Signed-off-by: Vaishali Thakkar
---
xen/arch/x86/hvm/svm/svm.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On 16/04/2024 9:54 am, Vaishali Thakkar wrote:
> Currently, Xen always starts the ASID allocation at 1. But
> for SEV technologies the ASID space is divided. This is
> because it's a security issue if a guest is started as
> ES/SNP and is migrated to SEV-only. So, the types are
> tracked
> Subject: [PATCH] xen/arm: imx8qm: Re-license file to GPL-2.0-only
>
> New contributions are recommended to be under GPL-2.0-only [1], since this
> code piece originally came from the NXP tree the original license was
> retained.
>
> However, as discussed both Peng [2] and I [3] are ok with
New contributions are recommended to be under GPL-2.0-only [1], since this
code piece originally came from the NXP tree the original license was
retained.
However, as discussed both Peng [2] and I [3] are ok with GPL-2.0.-only
as a license. Change the license.
Cc: Peng Fan
Link:
On 16/04/2024 10:08 am, Vaishali Thakkar wrote:
> TLB Flush by ASID is missing in the list of supported features
> here. So, add it.
>
> Signed-off-by: Vaishali Thakkar
> ---
> xen/arch/x86/hvm/svm/svm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c
On 16/04/2024 7:46 am, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> To be able to use cpu_has_{svm/vmx}_* macros in common code without enclosing
> them inside #ifdef guards when the respective virtualization technology is
> not enabled, define corresponding helper routines as false when not
flight 185635 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185635/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-vhd 12 debian-di-installfail REGR. vs. 185281
flight 185658 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185658/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b6cd5ddce9ade43e4215836f12b43ebbb90eecf2
baseline version:
ovmf
branch xen-4.16-testing
xenbranch xen-4.16-testing
job test-amd64-amd64-xl-pvhv2-intel
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On 16/04/2024 7:35 am, Sergiy Kibrik wrote:
> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
> index 35561fe51d..d3d7b8fb2e 100644
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -10,4 +10,6 @@ obj-y += intel.o
> obj-y += intel_cacheinfo.o
> obj-y +=
On 16/04/2024 8:11 am, Juergen Gross wrote:
> diff --git a/arch/x86/sched.c b/arch/x86/sched.c
> index dabe6fd6..460dea2e 100644
> --- a/arch/x86/sched.c
> +++ b/arch/x86/sched.c
> @@ -119,20 +113,12 @@ struct thread* arch_create_thread(char *name, void
> (*function)(void *),
>
> void
> On 16 Apr 2024, at 10:06, Julien Grall wrote:
>
>
>
> On 16/04/2024 09:59, Luca Fancellu wrote:
>>> On 16 Apr 2024, at 09:50, Julien Grall wrote:
>>>
>>>
>>>
>>> On 16/04/2024 07:27, Luca Fancellu wrote:
Hi Julien,
>>>
>>> Hi Luca,
>>>
> On 15 Apr 2024, at 19:41, Julien
On 16/04/2024 7:31 am, Sergiy Kibrik wrote:
> Instead of using generic CONFIG_HVM option switch to a bit more specific
> CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
> altp2m routines, so that it can be disabled completely in the build.
>
> Signed-off-by: Sergiy Kibrik
16.04.24 12:36, Andrew Cooper:
Everything else seems ok, but there's no inherent dependency between
VMX/SVM and IOMMUs. There are certain features (HAP/IOMMU pagetable
sharing, posted interrupts) which do depend on both, but the vast
majority of functionality is independent.
It would be a
hi Teddy,
16.04.24 11:40, Teddy Astie:
Hello Sergiy,
Also make INTEL_IOMMU/AMD_IOMMU options dependant on VMX/SVM options.
The discussion in the RFC series stated the IOMMU may be used with PV
guests, and doesn't rely on VMX/SVM support (in fact, it can be used
without HVM support in Xen).
On 16/04/2024 7:50 am, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> Provide the user with configuration control over the cpu virtualization
> support
> in Xen by making SVM and VMX options user selectable.
>
> To preserve the current default behavior, both options depend on HVM and
>
flight 185649 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185649/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6363872629cd58636128824977e56eea15b97a15
baseline version:
ovmf
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
[v2]
1- Removed unnecessary NULL initialization.
2- Used static at the beginning of type struct declaration.
3- Corrected switch\case indentations.
4- Removed redundant checks.
5- Corrected label
Update microcode version check at Intel and AMD Level by:
Preventing the low level code from sending errors if the microcode
version provided is not a newer version. Other errors will be sent like before.
When the provided microcode version is the same as the current one, code
to point to
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
Fouad Hilly (5):
x86: Update x86 low level version check of
Introduce --force option to xen-ucode to force skipping microcode version
check, which allows the user to update x86 microcode even if both versions
are the same.
[v2]
1- Changed data type from uint32_t to unsigned int.
2- Corrected line length.
3- Removed XENPF_UCODE_FLAG_FORCE_NOT_SET.
4-
Refactor microcode_update() hypercall by adding flags field.
Introduce XENPF_microcode_update2 hypercall to handle flags field.
struct xenpf_microcode_update updated to have uint32_t flags at
the end of the sturcture.
[v2]
1- Update message description to highlight interface change.
2- Removed
Refactor xen-ucode tool by adding usage() to handle usage\help messages
As we add more command options this will keep help\usage messages in common
block
[v2]
1- Improved message description.
2- Fixed formatting and indentation.
3- Error message to print to stderr.
Signed-off-by: Fouad Hilly
TLB Flush by ASID is missing in the list of supported features
here. So, add it.
Signed-off-by: Vaishali Thakkar
---
xen/arch/x86/hvm/svm/svm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index a745acd903..4719fffae5 100644
---
On 16/04/2024 09:59, Luca Fancellu wrote:
On 16 Apr 2024, at 09:50, Julien Grall wrote:
On 16/04/2024 07:27, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
On 15 Apr 2024, at 19:41, Julien Grall wrote:
Hi Luca,
On 09/04/2024 12:45, Luca Fancellu wrote:
Currently Xen is not exporting
> On 16 Apr 2024, at 09:50, Julien Grall wrote:
>
>
>
> On 16/04/2024 07:27, Luca Fancellu wrote:
>> Hi Julien,
>
> Hi Luca,
>
>>> On 15 Apr 2024, at 19:41, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 09/04/2024 12:45, Luca Fancellu wrote:
Currently Xen is not exporting the
Hi Julien,
On 16/04/2024 10:50, Julien Grall wrote:
>
>
> On 16/04/2024 07:27, Luca Fancellu wrote:
>> Hi Julien,
>
> Hi Luca,
>
>>
>>> On 15 Apr 2024, at 19:41, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 09/04/2024 12:45, Luca Fancellu wrote:
Currently Xen is not exporting the
Currently, Xen always starts the ASID allocation at 1. But
for SEV technologies the ASID space is divided. This is
because it's a security issue if a guest is started as
ES/SNP and is migrated to SEV-only. So, the types are
tracked explicitly.
Thus, in preparation of SEV support in Xen, add
On 16/04/2024 07:27, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
On 15 Apr 2024, at 19:41, Julien Grall wrote:
Hi Luca,
On 09/04/2024 12:45, Luca Fancellu wrote:
Currently Xen is not exporting the static shared memory regions
to the device tree as /memory node, this commit is fixing
Hello Sergiy,
> Also make INTEL_IOMMU/AMD_IOMMU options dependant on VMX/SVM options.
The discussion in the RFC series stated the IOMMU may be used with PV
guests, and doesn't rely on VMX/SVM support (in fact, it can be used
without HVM support in Xen).
However, in the discussion, posted
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros when and add missing
code symbol annotations.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/arm64/entry.S | 72 +-
1 file changed, 48 insertions(+), 24 deletions(-)
diff --git
From: "Edgar E. Iglesias"
On the way towards Xen safety certification we're evaluating the use
of tools to collect code-coverage/profiling information from execution
traces. Some tools rely on ELF symbols for code being declared with
type FUNC and having a symbol size.
We currently annotate
flight 185632 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185632/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 185427
test-amd64-amd64-xl-vhd
Hi Stefano,
> On 14 Mar 2024, at 22:50, Stefano Stabellini wrote:
>
>
> Signed-off-by: Stefano Stabellini
Acked-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Changes in v2:
> - mention -Werror
> - change the position of the in-code comment in the example
> - use "notifier pattern" in the
Hi Stefano,
> On 15 Mar 2024, at 01:35, Stefano Stabellini wrote:
>
> Signed-off-by: Stefano Stabellini
With the semicolon comment from Jan addressed:
Acked-by: Bertrand Marquis
Cheers
Bertrand
flight 185643 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185643/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70892b13b28cdb0a10c82f3d3aca560a38dce5c9
baseline version:
ovmf
Instead of having #ifdefs sprinkled around in x86 code, add some
macros defining constants for asm statements to address differences
between 32- and 64-bit mode.
Modify existing code to use those macros.
Signed-off-by: Juergen Gross
---
arch/x86/sched.c | 32 +---
From: Xenia Ragiadakou
Provide the user with configuration control over the cpu virtualization support
in Xen by making SVM and VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to Y.
To prevent users from unknowingly disabling
Hi Julien, John,
> Subject: Re: [PATCH v4 1/3] xen/arm: Add imx8q{m,x} platform glue
>
> Hi John,
>
> On 15/04/2024 12:17, John Ernberg wrote:
> > Hi Julien,
> >
> > On 4/15/24 1:03 PM, Julien Grall wrote:
> >>
> >>
> >> On 15/04/2024 11:50, Andrew Cooper wrote:
> >>> On 15/04/2024 11:25 am,
From: Xenia Ragiadakou
VIO_realmode_completion is specific to vmx realmode, so guard the completion
handling code with CONFIG_VMX. Also, guard VIO_realmode_completion itself by
CONFIG_VMX, instead of generic CONFIG_X86.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
From: Xenia Ragiadakou
To be able to use cpu_has_{svm/vmx}_* macros in common code without enclosing
them inside #ifdef guards when the respective virtualization technology is
not enabled, define corresponding helper routines as false when not applicable.
No functional change intended.
Instead of directly accessing control variables from vmcs macros let
intermediate helper routine vmx_ctrl_has_feature() do it. This way
we can turn all the VMX-related macros off, if building for non VT-d platform,
by tweaking only a single helper's function behaviour.
No functional change
From: Xenia Ragiadakou
The symbol svm_stgi_label is AMD-V specific so guard its usage in common code
with CONFIG_SVM.
Since SVM depends on HVM, it can be used alone.
Also, use #ifdef instead of #if.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
From: Xenia Ragiadakou
The functions svm_load_segs() and svm_load_segs_prefetch() are AMD-V specific
so guard their calls in common code with CONFIG_SVM.
Since SVM depends on HVM, it can be used alone.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy
From: Xenia Ragiadakou
The functions vmx_vmcs_enter() and vmx_vmcs_exit() are VT-x specific.
Guard their calls with CONFIG_VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/traps.c | 8 ++--
1 file changed, 2 insertions(+),
Build AMD vPMU when CONFIG_SVM is on, and Intel vPMU when CONFIG_VMX is on
respectively, allowing for a plaftorm-specific build. Also separate
arch_vpmu_ops initializers using these options and static inline stubs.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
From: Xenia Ragiadakou
The functions ept_p2m_init() and ept_p2m_uninit() are VT-x specific.
Do build-time checks and skip these functions execution when !VMX.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/p2m-basic.c | 4 ++--
Instead of using generic CONFIG_HVM option switch to a bit more specific
CONFIG_VMX option for altp2m support, as it depends on VMX. Also guard
altp2m routines, so that it can be disabled completely in the build.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/include/asm/altp2m.h | 5 -
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.
No functional change intended.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/altp2m.c | 631 ++
Hi Julien,
> On 15 Apr 2024, at 19:41, Julien Grall wrote:
>
> Hi Luca,
>
> On 09/04/2024 12:45, Luca Fancellu wrote:
>> Currently Xen is not exporting the static shared memory regions
>> to the device tree as /memory node, this commit is fixing this
>> issue.
>> The static shared memory banks
Initialize and bring down altp2m 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.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/mm/p2m-basic.c | 19 +++
1 file
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.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/hvm/monitor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Xenia Ragiadakou
Since start_svm() is AMD-V specific while start_vmx() is Intel VT-x specific,
one can be excluded from build completely with CONFIG_SVM and CONFIG_VMX,
respectively.
No functional change intended.
Signed-off-by: Xenia Ragiadakou
Signed-off-by: Sergiy Kibrik
---
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 machine extensions on platforms that
implement the AMD Virtualization
This series aims to continue what Xenia started a year ago:
https://lore.kernel.org/xen-devel/20230213145751.1047236-1-burzalod...@gmail.com/
Here's an attempt to provide a means to render the cpu virtualization
technology support in Xen configurable.
Currently, irrespectively of the target
70 matches
Mail list logo
