From: Dmytro Semenets
Use spin-up cpu with disabled interrupts instead PSCI CPU OFF
halt and reboot procedures. Some platforms can't stop CPU via PSCI
because Thrusted OS can't migrate execution to other CPU.
Signed-off-by: Dmytro Semenets
---
xen/arch/arm/shutdown.c | 7 ++-
1 file change
On 16.06.2022 13:31, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 11:45:54AM +0200, Jan Beulich wrote:
>> On 14.06.2022 11:38, Roger Pau Monné wrote:
>>> On Tue, Jun 14, 2022 at 11:13:07AM +0200, Jan Beulich wrote:
On 14.06.2022 10:32, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 1
flight 171303 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171303/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171301
test-armhf-armhf-libvirt 16 sav
> On 21 Jun 2022, at 15:01, Andrew Cooper wrote:
>
> 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 ha
On 21.06.2022 15:48, Roger Pau Monné wrote:
> 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 mercuria
On 17.06.2022 05:26, Henry Wang wrote:
> It seems that this series [1] has been stale for more than a month and also
> this series seems to be properly reviewed and acked already.
>
> From what Jan has replied to Roger and Andrew:
> "... this addition the series would now look to be ready to go i
On 22/06/2022 09:41, Jan Beulich wrote:
> On 21.06.2022 15:48, Roger Pau Monné wrote:
>> 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 so
On 17.05.2022 16:33, Matias Ezequiel Vara Larsen wrote:
> @@ -287,6 +288,10 @@ static inline void vcpu_runstate_change(
> }
>
> v->runstate.state = new_state;
> +
> +// WIP: use a different interface
> +runstate = (uint64_t*)v->stats.va;
> +memcpy(runstate, &v->runstate.time
On 22.06.22 09:38, Juergen Gross wrote:
Hello Juergen
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 re
On Wed, Jun 22, 2022 at 10:04:19AM +0200, Jan Beulich wrote:
> On 16.06.2022 13:31, Roger Pau Monné wrote:
> > On Tue, Jun 14, 2022 at 11:45:54AM +0200, Jan Beulich wrote:
> >> On 14.06.2022 11:38, Roger Pau Monné wrote:
> >>> On Tue, Jun 14, 2022 at 11:13:07AM +0200, Jan Beulich wrote:
> On 1
On 20.06.2022 04:44, Penny Zheng wrote:
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -35,6 +35,18 @@ void arch_get_domain_info(const struct domain *d,
> /* Should domain memory be directly mapped? */
> #define CDF_directmap(1U << 1)
> #endif
> +/* Is domain
On 20.06.2022 04:44, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2498,6 +2498,10 @@ void free_domheap_pages(struct page_info *pg, unsigned
> int order)
> }
>
> free_heap_pages(pg, order, scrub);
> +
> +/* Add page on the resv
Hi Stefano,
> On 22 Jun 2022, at 01:00, Stefano Stabellini wrote:
>
> 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 comman
On 20.06.2022 04:44, Penny Zheng wrote:
> When a static domain populates memory through populate_physmap at runtime,
> it shall retrieve reserved pages from resv_page_list to make sure that
> guest RAM is still restricted in statically configured memory regions.
> This commit also introduces a new
On 22.06.2022 11:09, Roger Pau Monné wrote:
> On Wed, Jun 22, 2022 at 10:04:19AM +0200, Jan Beulich wrote:
>> On 16.06.2022 13:31, Roger Pau Monné wrote:
>>> On Tue, Jun 14, 2022 at 11:45:54AM +0200, Jan Beulich wrote:
On 14.06.2022 11:38, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 1
On 22.06.2022 10:47, Andrew Cooper wrote:
> On 22/06/2022 09:41, Jan Beulich wrote:
>> On 21.06.2022 15:48, Roger Pau Monné wrote:
>>> 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 be
On 17.06.2022 12:47, Andrew Cooper wrote:
> This is a continuation of the cleanup and commenting in:
> 9186e96b199e ("x86/pv: Clean up _get_page_type()")
> 8cc5036bc385 ("x86/pv: Fix ABAC cmpxchg() race in _get_page_type()")
>
> With the re-arranged and newly commented logic, it's far more cle
On Wed, Jun 22, 2022 at 11:33:32AM +0200, Jan Beulich wrote:
> On 22.06.2022 11:09, Roger Pau Monné wrote:
> > On Wed, Jun 22, 2022 at 10:04:19AM +0200, Jan Beulich wrote:
> >> On 16.06.2022 13:31, Roger Pau Monné wrote:
> >>> On Tue, Jun 14, 2022 at 11:45:54AM +0200, Jan Beulich wrote:
> On 1
flight 171306 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171306/
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 22 Jun 2022, at 09:59, Jan Beulich wrote:
>
[snip]
> In general I also have to admit that I'm not sure the exposed data really
> qualifies as a "resource", and hence I'm not really convinced of your use
> of the resource mapping interface as a vehicle.
I’m not sure if I’d call any of the
On 22.06.2022 12:05, George Dunlap wrote:
>> On 22 Jun 2022, at 09:59, Jan Beulich wrote:
>>
> [snip]
>> In general I also have to admit that I'm not sure the exposed data really
>> qualifies as a "resource", and hence I'm not really convinced of your use
>> of the resource mapping interface as a
On 22/06/2022 10:58, Jan Beulich wrote:
> On 17.06.2022 12:47, Andrew Cooper wrote:
>> This is a continuation of the cleanup and commenting in:
>> 9186e96b199e ("x86/pv: Clean up _get_page_type()")
>> 8cc5036bc385 ("x86/pv: Fix ABAC cmpxchg() race in _get_page_type()")
>>
>> With the re-arrange
On 20.06.2022 09:02, Michal Orzel wrote:
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -211,8 +211,8 @@ struct physdev_manage_pci_ext {
> /* IN */
> uint8_t bus;
> uint8_t devfn;
> -unsigned is_extfn;
> -unsigned is_virtfn;
> +unsigned int
On 22.06.22 09:38, Juergen Gross wrote:
Hello Juergen
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 fl
On 20.06.2022 09:02, Michal Orzel wrote:
> This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
> cppcheck 2.7 with misra addon, for Arm (arm32/arm64 - target allyesconfig).
> Fixing this rule comes down to replacing implicit 'unsigned' with explicit
> 'unsigned int' type as th
On 20.06.2022 09: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 explicit 'unsigned int'.
>
> Signed-off-by: Michal Orzel
> ---
> This patc
Julien,
could you please test the attached patches?
Juergen
From 7d6734e517b65c3702a279fc2c1fff5ba7927ef9 Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Wed, 22 Jun 2022 12:19:55 +0200
Subject: [PATCH 1/2] x86/xen: use clear_bss() for Xen PV guests
Instead of clearing the bss area in asse
On 22/06/2022 11:45, Juergen Gross wrote:
Julien,
Hi Juergen,
could you please test the attached patches?
I am getting the following error:
(XEN) d0v0 Unhandled: vec 14, #PF[0003]
(XEN) Pagetable walk from 84001000:
(XEN) L4[0x1ff] = 00046c004067 4004
(XEN) L3[
On 22.06.2022 12:16, Jan Beulich wrote:
> On 20.06.2022 09:02, Michal Orzel wrote:
>> --- a/xen/include/public/physdev.h
>> +++ b/xen/include/public/physdev.h
>> @@ -211,8 +211,8 @@ struct physdev_manage_pci_ext {
>> /* IN */
>> uint8_t bus;
>> uint8_t devfn;
>> -unsigned is_e
On 22.06.2022 12:36, Jan Beulich wrote:
> On 20.06.2022 09: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 explicit 'unsigned int'.
>>
flight 171305 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171305/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-vhd7 xen-installfail pass in 171295
Tests which did not succeed, but
On 22.06.2022 13:09, Michal Orzel wrote:
> On 22.06.2022 12:36, Jan Beulich wrote:
>> On 20.06.2022 09:02, Michal Orzel wrote:
>>> --- a/xen/drivers/acpi/tables/tbutils.c
>>> +++ b/xen/drivers/acpi/tables/tbutils.c
>>> @@ -481,7 +481,7 @@ acpi_tb_parse_root_table(acpi_physical_address
>>> rsdp_add
On 28-04-22, 16:52, Oleksandr Tyshchenko wrote:
> FYI, currently we are working on one feature to restrict memory access
> using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1].
> And there is a working PoC on Arm based on an updated virtio-disk. As for
> libraries, there is a
On 22.06.22 12:50, Julien Grall wrote:
On 22/06/2022 11:45, Juergen Gross wrote:
Julien,
Hi Juergen,
could you please test the attached patches?
I am getting the following error:
(XEN) d0v0 Unhandled: vec 14, #PF[0003]
(XEN) Pagetable walk from 84001000:
(XEN) L4[0x1ff] = 0
Hi Andrew and Christopher,
I will not dig into the details of the issues you currently have
but it seems you are trying to re-do the work we already did
and have been using for quite a while.
Currently we maintain the xtf on arm code in gitlab and we
recently rebased it on the latest xtf master:
Hi Anthony,
On 21.06.2022 12:11, Anthony PERARD wrote:
> 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
Hi Jan,
On 22.06.2022 12:25, Jan Beulich wrote:
> On 20.06.2022 09:02, Michal Orzel wrote:
>> This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
>> cppcheck 2.7 with misra addon, for Arm (arm32/arm64 - target allyesconfig).
>> Fixing this rule comes down to replacing implici
On 22.06.2022 14:55, Michal Orzel wrote:
> On 22.06.2022 12:25, Jan Beulich wrote:
>> On 20.06.2022 09:02, Michal Orzel wrote:
>>> This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
>>> cppcheck 2.7 with misra addon, for Arm (arm32/arm64 - target allyesconfig).
>>> Fixing thi
Hi Juergen,
On 22/06/2022 13:13, Juergen Gross wrote:
On 22.06.22 12:50, Julien Grall wrote:
On 22/06/2022 11:45, Juergen Gross wrote:
Julien,
Hi Juergen,
could you please test the attached patches?
I am getting the following error:
(XEN) d0v0 Unhandled: vec 14, #PF[0003]
(XEN) Pageta
Hi,
This patch sets add a FF-A [1] mediator modeled after the TEE mediator
already present in Xen. The FF-A mediator implements the subset of the FF-A
1.1 specification needed to communicate with OP-TEE using FF-A as transport
mechanism instead of SMC/HVC as with the TEE mediator. It allows a simi
SMCCC v1.2 AArch64 allows x0-x17 to be used as both parameter registers
and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
parameter and result registers.
Let us add new interface to support this extended set of input/outp
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
The implementation is the bare minimum to be able to communicate with
OP-TEE running as an SPMC at S-EL1.
This is loosely based on the TEE mediator framework and the OP-TEE
mediator.
[1] https://develope
Hi Jan,
> On 22 Jun 2022, at 14:01, Jan Beulich wrote:
>
> On 22.06.2022 14:55, Michal Orzel wrote:
>> On 22.06.2022 12:25, Jan Beulich wrote:
>>> On 20.06.2022 09:02, Michal Orzel wrote:
This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
cppcheck 2.7 with misra
flight 171308 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171308/
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 1
On 22.06.2022 15:55, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 22 Jun 2022, at 14:01, Jan Beulich wrote:
>>
>> On 22.06.2022 14:55, Michal Orzel wrote:
>>> On 22.06.2022 12:25, Jan Beulich wrote:
On 20.06.2022 09:02, Michal Orzel wrote:
> This series fixes all the findings for MISRA C 20
On 22.06.22 15:20, Julien Grall wrote:
Hi Juergen,
On 22/06/2022 13:13, Juergen Gross wrote:
On 22.06.22 12:50, Julien Grall wrote:
On 22/06/2022 11:45, Juergen Gross wrote:
Julien,
Hi Juergen,
could you please test the attached patches?
I am getting the following error:
(XEN) d0v0 U
Hi,
> On 22 Jun 2022, at 15:10, Jan Beulich wrote:
>
> On 22.06.2022 15:55, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 22 Jun 2022, at 14:01, Jan Beulich wrote:
>>>
>>> On 22.06.2022 14:55, Michal Orzel wrote:
On 22.06.2022 12:25, Jan Beulich wrote:
> On 20.06.2022 09:02, Michal Or
On 22.06.22 11:03, Oleksandr wrote:
On 22.06.22 09:38, Juergen Gross wrote:
Hello Juergen
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_PL
The purpose of this patch series is to add static event channel signaling
support to Xen on Arm based on design doc [1].
This patch series depends on patch series [2] to create event channel in Xen.
[1] https://lists.xenproject.org/archives/html/xen-devel/2022-05/msg01160.html
[2] https://patchw
Event channel support will be added for dom0less domains to allocate
static event channel. It is necessary to have access to the
evtchn_bind_interdomain function to do that, so make
evtchn_bind_interdomain global and also make it __must_check.
Signed-off-by: Rahul Singh
---
xen/common/event_chan
evtchn_alloc_unbound() always allocates the next available port. Static
event channel support for dom0less domains requires allocating a
specified port.
Modify the evtchn_alloc_unbound() to accept the port number as an
argument and allocate the specified port if available. If the port
number argum
evtchn_bind_interdomain() always allocates the next available local
port. Static event channel support for dom0less domains requires
allocating a specified port.
Modify the evtchn_bind_interdomain to accept the port number as an
argument and allocate the specified port if available. If the port
nu
evtchn_bind_interdomain() finds the local domain from "current->domain"
pointer.
evtchn_bind_interdomain() will be called from the XEN to support static
event channel during domain creation. "current" pointer is not valid at
that time, therefore modify the evtchn_bind_interdomain() to pass
domain
Guest can request the Xen to close the event channels. Ignore the
request from guest to close the static channels as static event channels
should not be closed.
Add the new bool variable "is_static" in "struct evtchn" to mark the
event channel static when creating the event channel.
Signed-off-by
On 22.06.2022 16:27, Bertrand Marquis wrote:
> Hi,
>
>> On 22 Jun 2022, at 15:10, Jan Beulich wrote:
>>
>> On 22.06.2022 15:55, Bertrand Marquis wrote:
>>> Hi Jan,
>>>
On 22 Jun 2022, at 14:01, Jan Beulich wrote:
On 22.06.2022 14:55, Michal Orzel wrote:
> On 22.06.2022 12:25,
On 22.06.2022 14:35, Michal Orzel wrote:
> Hi Anthony,
>
> On 21.06.2022 12:11, Anthony PERARD wrote:
>> 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:
>>
Introduce a new "xen,enhanced" dom0less property value "evtchn" to
enable/disable event-channel interfaces for dom0less guests.
The configurable option is for domUs only. For dom0 we always set the
corresponding property in the Xen code to true.
Signed-off-by: Rahul Singh
---
xen/arch/arm/domai
Introduce a new sub-node under /chosen node to establish static event
channel communication between domains on dom0less systems.
An event channel will be created beforehand to allow the domains to
send notifications to each other.
Signed-off-by: Rahul Singh
---
docs/misc/arm/device-tree/booting
evtchn_bind_interdomain() sets the notification on the local port to
handle the lost notification on remote unbound port.
Static event-channel will be created during domain creation, there is no
need to set the notification as remote domain is not alive.
Signed-off-by: Rahul Singh
---
xen/commo
Hi,
On 22/06/2022 15:37, Rahul Singh wrote:
evtchn_alloc_unbound() always allocates the next available port. Static
event channel support for dom0less domains requires allocating a
specified port.
Modify the evtchn_alloc_unbound() to accept the port number as an
argument and allocate the specif
Hi,
On 22/06/2022 15:38, Rahul Singh wrote:
Guest can request the Xen to close the event channels. Ignore the
request from guest to close the static channels as static event channels
should not be closed.
Why do you want to prevent the guest to close static ports? The problem
I can see is...
On Wed, Jun 22, 2022 at 2:49 PM Viresh Kumar
wrote:
> On 28-04-22, 16:52, Oleksandr Tyshchenko wrote:
> > FYI, currently we are working on one feature to restrict memory access
> > using Xen grant mappings based on xen-grant DMA-mapping layer for Linux
> [1].
> > And there is a working PoC on Arm
Include header so that the declarations of the functions
machine_halt() and machine_restart(), which have external linkage, are visible
before the function definitions.
Signed-off-by: Xenia Ragiadakou
---
xen/arch/arm/shutdown.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/s
Include header so that the declarations of functions gzip_check()
and perform_gunzip(), which have external linkage, are visible before the
function definitions.
Signed-off-by: Xenia Ragiadakou
---
xen/common/gunzip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/gunzip.c b/xen
Include header so that the declaration of the function
list_sort(), which has external linkage, is visible before the function
definition.
Signed-off-by: Xenia Ragiadakou
---
xen/lib/list-sort.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/lib/list-sort.c b/xen/lib/list-sort.c
index
The function __dt_n_size_cells() is referenced only in device_tree.c.
Change the linkage of the function from external to internal by adding
the storage-class specifier static to the function definition.
This patch aims to resolve indirectly a MISRA C 2012 Rule 8.4 violation
warning.
Signed-off-b
On 22.06.22 17:35, Juergen Gross wrote:
Hello Juergen
On 22.06.22 11:03, Oleksandr wrote:
On 22.06.22 09:38, Juergen Gross wrote:
Hello Juergen
Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using
Xen grant mappings") introduced a new requirement for using virtio
devi
Hi Xenia,
> On 22 Jun 2022, at 16:15, Xenia Ragiadakou wrote:
>
> Include header so that the declarations of the functions
> machine_halt() and machine_restart(), which have external linkage, are visible
> before the function definitions.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Bertr
Hi Xenia,
> On 22 Jun 2022, at 16:15, Xenia Ragiadakou wrote:
>
> Include header so that the declaration of the function
> list_sort(), which has external linkage, is visible before the function
> definition.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
Hi Xenia,
> On 22 Jun 2022, at 16:15, Xenia Ragiadakou wrote:
>
> Include header so that the declarations of functions
> gzip_check()
> and perform_gunzip(), which have external linkage, are visible before the
> function definitions.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Bertrand
On Wed, Jun 15, 2022 at 04:25:54PM +0200, Jan Beulich wrote:
> On 07.06.2022 16:30, Marek Marczykowski-Górecki wrote:
> > From: Connor Davis
> > --- /dev/null
> > +++ b/xen/drivers/char/xue.c
> > @@ -0,0 +1,957 @@
> > +/*
> > + * drivers/char/xue.c
> > + *
> > + * Xen port for the xue debugger
>
A Linux kernel 5.19 can only be loaded as dom0, if it has been
built with CONFIG_AMD_MEM_ENCRYPT enabled. This is due to the
fact that otherwise the (relevant) last section of the built
kernel has the NOLOAD flag set (it is still marked with
SHF_ALLOC).
I think at least the hypervisor needs to be
The brk area needs to be zeroed initially, like the .bss section.
Juergen Gross (2):
x86/xen: use clear_bss() for Xen PV guests
x86: fix setup of brk area
arch/x86/include/asm/setup.h | 3 +++
arch/x86/kernel/head64.c | 4 +++-
arch/x86/xen/enlighten_pv.c | 8 ++--
arch/x86/xen/x
Commit e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for older binutils")
put the brk area into the .bss segment, causing it not to be cleared
initially. As the brk area is used to allocate early page tables, these
might contain garbage in not explicitly written entries.
This is especially a problem fo
Instead of clearing the bss area in assembly code, use the clear_bss()
function.
This requires to pass the start_info address as parameter to
xen_start_kernel() in order to avoid the xen_start_info being zeroed
again.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/setup.h | 3 +++
arch/
On 22/06/2022 13:32, Bertrand Marquis wrote:
> Hi Andrew and Christopher,
>
> I will not dig into the details of the issues you currently have
> but it seems you are trying to re-do the work we already did
> and have been using for quite a while.
>
> Currently we maintain the xtf on arm code in git
flight 171307 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171307/
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
Hi Andrew,
> On 22 Jun 2022, at 17:28, Andrew Cooper wrote:
>
> On 22/06/2022 13:32, Bertrand Marquis wrote:
>> Hi Andrew and Christopher,
>>
>> I will not dig into the details of the issues you currently have
>> but it seems you are trying to re-do the work we already did
>> and have been usin
Hi Stefano,
On 15/06/2022 01:32, Stefano Stabellini wrote:
On Tue, 14 Jun 2022, Julien Grall wrote:
From: Julien Grall
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupt
On 15/06/2022 01:23, Stefano Stabellini wrote:
On Tue, 14 Jun 2022, Michal Orzel wrote:
On 14.06.2022 13:08, Julien Grall wrote:
+ unsigned int rc = 0;
... here you are setting rc to 0 even though it will be reassigned.
Furthermore, if rc is used only in case of CPU_UP_PREPARE, why not m
Hi Dmytro,
Title: It seems to suggest we are completely removing PSCI CPU off. I
would suggest to rename to:
xen/arm: Don't use stop_cpu() in halt_this_cpu()
On 22/06/2022 08:24, dmitry.semen...@gmail.com wrote:
From: Dmytro Semenets
Use spin-up cpu with disabled interrupts instead PSCI CP
+Roberto
Hi Roberto,
A quick question about Rule 8.1.
Michal sent a patch series to fix Xen against Rule 8.1 (here is a link
if you are interested: https://marc.info/?l=xen-devel&m=165570851227125)
Although we all generally agree that the changes are a good thing, there
was a question about t
On Wed, 22 Jun 2022, Xenia Ragiadakou wrote:
> Include header so that the declaration of the function
> list_sort(), which has external linkage, is visible before the function
> definition.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Stefano Stabellini
> ---
> xen/lib/list-sort.c | 1 +
On Wed, 22 Jun 2022, Xenia Ragiadakou wrote:
> Include header so that the declarations of functions
> gzip_check()
> and perform_gunzip(), which have external linkage, are visible before the
> function definitions.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Stefano Stabellini
> ---
>
On Wed, 22 Jun 2022, Xenia Ragiadakou wrote:
> The function __dt_n_size_cells() is referenced only in device_tree.c.
> Change the linkage of the function from external to internal by adding
> the storage-class specifier static to the function definition.
>
> This patch aims to resolve indirectly a
flight 171311 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171311/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3930d1791a0657a422d50f4d2e2d2683c36e34b8
baseline version:
ovmf b97243dea3c95ad923fa4
On Wed, Jun 22, 2022 at 9:40 AM Bertrand Marquis
wrote:
>
> Hi Andrew,
>
> > On 22 Jun 2022, at 17:28, Andrew Cooper wrote:
> >
> > On 22/06/2022 13:32, Bertrand Marquis wrote:
> >> Hi Andrew and Christopher,
> >>
> >> I will not dig into the details of the issues you currently have
> >> but it s
flight 171314 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171314/
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 1
On Wed, 22 Jun 2022, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 22 Jun 2022, at 01:00, Stefano Stabellini wrote:
> >
> > 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 C
flight 171315 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171315/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f304308e1cb21846a79fc8e4aa9ffa2cb1db3e4c
baseline version:
ovmf 3930d1791a0657a422d50
flight 171309 linux-5.4 real [real]
flight 171317 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171309/
http://logs.test-lab.xenproject.org/osstest/logs/171317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
flight 171310 xen-unstable real [real]
flight 171316 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171310/
http://logs.test-lab.xenproject.org/osstest/logs/171316/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 171313 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171313/
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
flight 171312 qemu-mainline real [real]
flight 171321 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171312/
http://logs.test-lab.xenproject.org/osstest/logs/171321/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi Jan (and Andrew),
> -Original Message-
> From: Jan Beulich
> On 17.06.2022 05:26, Henry Wang wrote:
> > It seems that this series [1] has been stale for more than a month and also
> > this series seems to be properly reviewed and acked already.
> >
> > From what Jan has replied to Roge
On 22-06-22, 18:05, Oleksandr Tyshchenko wrote:
> Even leaving
> aside the fact that restricted virtio memory access in the guest means that
> not all of guest memory can be accessed, so even having pre-maped guest
> memory in advance, we are not able to calculate a host pointer as we don't
> know
96 matches
Mail list logo
