flight 171302 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 171277
test-amd64-amd64-do
Instead of an all or nothing approach add support for requiring
restricted memory access per device.
Changes in V3:
- new patches 1 + 2
- basically complete rework of patch 3
Juergen Gross (3):
virtio: replace restricted mem access flag with callback
kernel: remove platform_has() infrastructu
The only use case of the platform_has() infrastructure has been
removed again, so remove the whole feature.
Signed-off-by: Juergen Gross
---
MAINTAINERS| 8
include/asm-generic/Kbuild | 1 -
include/asm-generic/platform-feature.h | 8
Instead of having a global flag to require restricted memory access
for all virtio devices, introduce a callback which can select that
requirement on a per-device basis.
For convenience add a common function returning always true, which can
be used for use cases like SEV.
Per default use a callba
Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM
feature.
This is an undue requirement for non-PV guests, as those can be operated
with e
flight 171304 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171304/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b97243dea3c95ad923fa4ca190940158209e8384
baseline version:
ovmf cfe165140a7c140c2d2f3
unmap_grant_pages() currently waits for the pages to no longer be used.
In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
deadlock against i915: i915 was waiting for gntdev's MMU notifier to
finish, while gntdev was waiting for i915 to free its pages. I also
believe this is re
The EFI System Resource Table (ESRT) is necessary for fwupd to identify
firmware updates to install. According to the UEFI specification §23.4,
the ESRT shall be stored in memory of type EfiBootServicesData. However,
memory of type EfiBootServicesData is considered general-purpose memory
by Xen,
flight 171301 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171301/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171288
test-armhf-armhf-libvirt 16 sav
On Sun, 19 Jun 2022, Xenia Ragiadakou wrote:
> Direct mapping for dom0less VMs is disabled by default in XEN and can be
> enabled through the 'direct-map' property.
> Add a new config parameter DOMU_DIRECT_MAP to be able to enable or disable
> direct mapping, i.e set to 1 for enabling and to 0 for
On Sun, 19 Jun 2022, Xenia Ragiadakou wrote:
> When the parameter DOM0_KERNEL is not specified and NUM_DOMUS is not 0,
> instead of failing the script, just skip any dom0 specific setup.
> This way the script can be used to boot XEN in dom0less mode.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-
On Fri, 10 Jun 2022, Bertrand Marquis wrote:
> cppcheck MISRA addon can be used to check for non compliance to some of
> the MISRA standard rules.
>
> Add a CPPCHECK_MISRA variable that can be set to "y" using make command
> line to generate a cppcheck report including cppcheck misra checks.
>
>
On Tue, 21 Jun 2022, Xenia Ragiadakou wrote:
> The header file is already included above and can be removed
> here.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/vtimer.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/xen/arch/arm/vtimer
On Tue, 21 Jun 2022, Xenia Ragiadakou wrote:
> Include vtimer.h so that the declarations of vtimer functions with external
> linkage are visible before the function definitions.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/vtimer.c | 1 +
> 1 file
flight 171300 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 171277
test-amd64-amd64-do
On Tue, Jun 21, 2022 at 7:05 AM Julien Grall wrote:
>
> Hi Andrew,
>
> On 21/06/2022 14:30, Andrew Cooper wrote:
> > On 21/06/2022 13:07, Julien Grall wrote:
> >> On 21/06/2022 12:27, Andrew Cooper wrote:
> >>> Hello,
> >>> I tried to have a half hour respite from security and push forward
> >>> w
flight 171299 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 171277
test-amd64-amd64-xl
Include vtimer.h so that the declarations of vtimer functions with external
linkage are visible before the function definitions.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/arm/vtimer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 5bb59
The header file is already included above and can be removed here.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/arm/vtimer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 5f26463354..6b78fea77d 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen
On Mon, Jun 20, 2022 at 3:03 AM Michal Orzel wrote:
>
> According to MISRA C 2012 Rule 8.1, types shall be explicitly
> specified. Fix all the findings reported by cppcheck with misra addon
> by substituting implicit type 'unsigned' to explicit 'unsigned int'.
>
> Signed-off-by: Michal Orzel
Rev
Hi Andrew,
On 21/06/2022 14:30, Andrew Cooper wrote:
On 21/06/2022 13:07, Julien Grall wrote:
On 21/06/2022 12:27, Andrew Cooper wrote:
Hello,
I tried to have a half hour respite from security and push forward
with XTF-on-ARM, but the result was a mess.
https://github.com/andyhhp/xtf/commit/b
On 21/06/2022 14:48, Roger Pau Monné wrote:
> Hello,
>
> Last week we had a bit of an emergency when a web crawler started
> indexing all our mercurial repositories on xenbits, as caused the load
> on xenbits to go beyond what it can handle.
>
> As a temporary solution we decided to remove access t
Hi Mykyta,
> On 21 Jun 2022, at 10:38 am, Mykyta Poturai wrote:
>
>> Thanks for testing the patch.
>>> But not fixed the "Unexpected Global fault" that occasionally happens when
>>> destroying
>>> the domain with an actively working GPU. Although, I am not sure if this
>>> issue
>>> is relevan
Hello,
Last week we had a bit of an emergency when a web crawler started
indexing all our mercurial repositories on xenbits, as caused the load
on xenbits to go beyond what it can handle.
As a temporary solution we decided to remove access to mercurial
repositories, but the contents there are AFA
On 21/06/2022 13:07, Julien Grall wrote:
>
>
> On 21/06/2022 12:27, Andrew Cooper wrote:
>> Hello,
>
> Hi,
>
>> I tried to have a half hour respite from security and push forward
>> with XTF-on-ARM, but the result was a mess.
>>
>> https://github.com/andyhhp/xtf/commit/bc86e2d271f2107da9b1c9bc55a05
flight 171296 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 171277
test-amd64-amd64-xl
Hi Andrew,
On 21.06.2022 13:27, Andrew Cooper wrote:
> Hello,
>
> I tried to have a half hour respite from security and push forward with
> XTF-on-ARM, but the result was a mess.
>
> https://github.com/andyhhp/xtf/commit/bc86e2d271f2107da9b1c9bc55a050dbdf07c6c6
> is the absolute bare minimum s
On 21/06/2022 12:27, Andrew Cooper wrote:
Hello,
Hi,
I tried to have a half hour respite from security and push forward with
XTF-on-ARM, but the result was a mess.
https://github.com/andyhhp/xtf/commit/bc86e2d271f2107da9b1c9bc55a050dbdf07c6c6
is the absolute bare minimum stub VM, which
Hi,
On 21/06/2022 11:05, Dmytro Semenets wrote:
but machine_halt() doesn't work at al
... this should also be the case here because machine_halt() could also
be called from cpu0. So I am a bit confused why you are saying it never
works.
If machine_halt() called on a CPU other than CPU0 it caus
flight 171295 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171295/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 171283
test-armhf-armhf-libvirt 16 save
On Fri, Jun 17, 2022 at 03:13:33PM -0400, Chuck Zmudzinski wrote:
> Currently we are creating a register group for the Intel IGD OpRegion
> for every device we pass through, but the XEN_PCI_INTEL_OPREGION
> register group is only valid for an Intel IGD. Add a check to make
> sure the device is an I
The command line generated for headers++.chk by make is quite long,
and in some environment it is too long. This issue have been seen in
Yocto build environment.
Error messages:
make[9]: execvp: /bin/sh: Argument list too long
make[9]: *** [include/Makefile:181: include/headers++.chk] Erro
Hi Julien,
>
> Hi Dmytro,
>
>
> Hi,
>
> On 17/06/2022 10:10, Volodymyr Babchuk wrote:
> > Julien Grall writes:
> >
> >> On 16/06/2022 19:40, Volodymyr Babchuk wrote:
> >>> Hi Julien,
> >>
> >> Hi Volodymyr,
> >>
> >>> Julien Grall writes:
>
flight 171297 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 21/06/2022 09:55, Dmytro Semenets wrote:
Hi Julien,
Hi Dmytro,
Hi,
On 17/06/2022 10:10, Volodymyr Babchuk wrote:
Julien Grall writes:
On 16/06/2022 19:40, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi,
On 16/06/2022 14:55, dmitry.semen...@gmail
> Thanks for testing the patch.
>> But not fixed the "Unexpected Global fault" that occasionally happens when
>> destroying
>> the domain with an actively working GPU. Although, I am not sure if this
>> issue
>> is relevant here.
>
> Can you please if possible share the more details and logs so t
Hi Julien,
> >>
> >> Hi,
> >>
> >> On 17/06/2022 10:10, Volodymyr Babchuk wrote:
> >>> Julien Grall writes:
> >>>
> On 16/06/2022 19:40, Volodymyr Babchuk wrote:
> > Hi Julien,
>
> Hi Volodymyr,
>
> > Julien Grall writes:
> >
> >> Hi,
> >>
> >> On 16/06
On 21.06.22 10:43, Andrew Cooper wrote:
On 21/06/2022 08:23, Juergen Gross wrote:
diff --git a/e820.c b/e820.c
index ad91e00b..49b16878 100644
--- a/e820.c
+++ b/e820.c
@@ -29,6 +29,38 @@
#include
#include
+static unsigned long e820_initial_reserved_pfns;
+
+unsigned long e820_get_curr
On 21/06/2022 09:43, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 20.06.2022 11:54, Julien Grall wrote:
Hi Michal,
On 20/06/2022 08:02, Michal Orzel wrote:
According to MISRA C 2012 Rule 8.1, types shall be explicitly
specified. Fix all the findings reported by cppcheck with misra addo
Hi Julien,
On 20.06.2022 11:54, Julien Grall wrote:
> Hi Michal,
>
> On 20/06/2022 08:02, Michal Orzel wrote:
>> According to MISRA C 2012 Rule 8.1, types shall be explicitly
>> specified. Fix all the findings reported by cppcheck with misra addon
>> by substituting implicit type 'unsigned' to ex
On 21/06/2022 08:23, Juergen Gross wrote:
> diff --git a/e820.c b/e820.c
> index ad91e00b..49b16878 100644
> --- a/e820.c
> +++ b/e820.c
> @@ -29,6 +29,38 @@
> #include
> #include
>
> +static unsigned long e820_initial_reserved_pfns;
> +
> +unsigned long e820_get_current_pages(void)
> +{
> +
flight 171298 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171298/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cfe165140a7c140c2d2f382113abd6e9ac89ce77
baseline version:
ovmf e8034b534ab51635b62dc
Update include/xen/arch-x86/hvm/start_info.h to the newest version
from the Xen tree.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
include/xen/arch-x86/hvm/start_info.h | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/include/xen/a
There is a subtle bug in ballooning code for PVH: in case ballooning
extends above a non-RAM area of the memory map, wrong pages will be
used.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
V2:
- new patch
---
balloon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
When getting the current allocation from Xen, this value includes the
pages allocated in the MMIO area. Fix the highest available RAM page
by subtracting the size of that area.
This requires to read the E820 map before needing this value. Add two
functions returning the current and the maximum num
Do some memory map related changes/fixes for PVH mode:
- Prefer the memory map delivered via start-info over the one obtained
from the hypervisor. This is a prerequisite for Xenstore-stubdom
live-update with rising the memory limit.
- Fix a bug related to ballooning in PVH mode: PVH Xenstore-
Since some time now a guest started in PVH mode will get the memory
map from Xen via the start_info structure.
Modify the PVH initialization to prefer this memory map over the one
obtained via hypercall, as this will allow to add information to the
memory map for a new kernel when supporting kexec
On 21.06.22 00:43, Samuel Thibault wrote:
Juergen Gross, le dim. 19 juin 2022 08:52:52 +0200, a ecrit:
When getting the current allocation from Xen, this value includes the
pages allocated in the MMIO area. Fix the highest available RAM page
by subtracting the size of that area.
This requires t
48 matches
Mail list logo
