flight 180238 xen-unstable real [real]
flight 180254 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180238/
http://logs.test-lab.xenproject.org/osstest/logs/180254/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi Vikram,
> -Original Message-
> Subject: [XEN][PATCH v5 12/17] common/device_tree: Add rwlock for dt_host
>
> Dynamic programming ops will modify the dt_host and there might be other
> function which are browsing the dt_host at the same time. To avoid the race
> conditions, adding rw
Hi Vikram,
> -Original Message-
> Subject: [XEN][PATCH v5 11/17] asm/smp.h: Fix circular dependency for
> device_tree.h and rwlock.h
>
> Dynamic programming ops will modify the dt_host and there might be other
> function which are browsing the dt_host at the same time. To avoid the race
>
Hi Roger,
Roger Pau Monné writes:
> On Wed, Apr 12, 2023 at 09:54:12PM +, Volodymyr Babchuk wrote:
>>
>> Hi Roger,
>>
>> First of all, I want to provide link [1] to the RFC series where I tried
>> total PCI locking rework. After discussing with Jan, it became clear for
>> me, that task is
flight 180230 linux-linus real [real]
flight 180252 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180230/
http://logs.test-lab.xenproject.org/osstest/logs/180252/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 180250 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180250/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 55b67b6950e648338adfe8ec54aeb26ed89d2c97
baseline version:
ovmf d795fb571b9b2c2ee67ce
On Thu, 13 Apr 2023, Andrew Cooper wrote:
> On 13/04/2023 9:13 pm, Julien Grall wrote:
> >
> > On 13/04/2023 20:22, Andrew Cooper wrote:
> >> Despite rcu_read_unlock() being fully inlineable, the optimiser
> >> cannot fold
> >> these exit paths, because of the various compiler barriers providing RC
On 13/04/2023 9:13 pm, Julien Grall wrote:
>
> On 13/04/2023 20:22, Andrew Cooper wrote:
>> Despite rcu_read_unlock() being fully inlineable, the optimiser
>> cannot fold
>> these exit paths, because of the various compiler barriers providing RCU
>> safety. Help the compiler out.
>
> Please mentio
Hi Jens,
On 13/04/2023 08:14, Jens Wiklander wrote:
Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
[1] https://developer.arm.com/documentation/den0077/latest
Signed-off-by: Jens Wiklander
---
SUPPORT.md | 8
docs/man
Hi Jens,
On 13/04/2023 08:14, Jens Wiklander wrote:
Adds a comments with a list of unsupported FF-A interfaces and
limitations in the implemented FF-A interfaces.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 32
1 file changed, 32 insertions(+)
Hi Jens,
On 13/04/2023 08:14, Jens Wiklander wrote:
static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
uint8_t msg)
{
@@ -781,6 +862,400 @@ out:
resp.a4 & mask, resp.a5 & mask, resp.a6 & mask, resp.a7 & mask);
}
+
Hi Jens,
On 13/04/2023 08:14, Jens Wiklander wrote:
Adds support in the mediator to handle FFA_PARTITION_INFO_GET requests
from a guest. The requests are forwarded to the SPMC and the response is
translated according to the FF-A version in use by the guest.
Using FFA_PARTITION_INFO_GET changes
Hi Jens,
On 13/04/2023 08:14, Jens Wiklander wrote:
+static uint32_t handle_rxtx_map(uint32_t fid, register_t tx_addr,
+register_t rx_addr, uint32_t page_count)
+{
+uint32_t ret = FFA_RET_INVALID_PARAMETERS;
+struct domain *d = current->domain;
+struct
Hi Andrew,
You may want to update your runes to find the maintainers as you are
CCing the x86 folks but not the REST (the patch modifies common/ after all).
On 13/04/2023 20:22, Andrew Cooper wrote:
Despite rcu_read_unlock() being fully inlineable, the optimiser cannot fold
these exit paths,
flight 180231 qemu-mainline real [real]
flight 180249 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180231/
http://logs.test-lab.xenproject.org/osstest/logs/180249/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi Penny
On 2/23/23 00:41, Penny Zheng wrote:
> Static shared memory acts as reserved memory in guest, so it shall be
> excluded from extended regions.
>
> Extended regions are taken care of under three different scenarios:
> normal DomU, direct-map domain with iommu on, and direct-map domain
> w
Hi Penny
On 2/23/23 00:41, Penny Zheng wrote:
> In order to support static shared memory when host address not provided,
> we shall do the following modification:
> - we shall let Xen allocate memory from heap for static shared memory
> at first domain, no matter it is owner or borrower.
> - In ac
Hi Penny
On 2/23/23 00:40, Penny Zheng wrote:
> This commit introduces a set of separate data structures to deal with
> static shared memory at different stages.
>
> In boot-time host device tree parsing, we introduce a new structure
> "struct shm_node" and a new field "shm_info" in bootinfo to d
Hi Luca,
On 13/04/2023 15:35, Luca Fancellu wrote:
On 13 Apr 2023, at 14:11, Julien Grall wrote:
On 12/04/2023 10:49, Luca Fancellu wrote:
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum
Hi Luca,
On 13/04/2023 17:10, Luca Fancellu wrote:
Can we move this somewhere else to avoid adding extra padding? Also shouldn't
this be protected with #ifdef CONFIG_ARM_64 to make clear this is not supported
on Xen 32-bit?
Yes, I’ll move it and protect with CONFIG_ARM_64, is it ok for y
Hi Luca,
On 13/04/2023 15:05, Luca Fancellu wrote:
On 13 Apr 2023, at 14:30, Julien Grall wrote:
On 13/04/2023 14:24, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
@@ -594,6 +597,7 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
unsigned int max_vcpus;
flight 180248 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180248/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d795fb571b9b2c2ee67ceaef372d5cc461767859
baseline version:
ovmf 42b0443599a69c7030340
Hi Michal,
On 4/13/23 2:58 AM, Michal Orzel wrote:
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
Introduce a config option where the user can enable support for adding/removing
device tree nodes using a device tree binary overlay.
Signed-off-by: Vikram Garhwal
---
SUPPORT.md
Despite rcu_read_unlock() being fully inlineable, the optimiser cannot fold
these exit paths, because of the various compiler barriers providing RCU
safety. Help the compiler out.
This compiles to marginally better code in all cases. No functional change.
Signed-off-by: Andrew Cooper
---
CC: J
flight 180227 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180227/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15 migrate-s
Restructure the code so that one can use pa_range_info[] table for both
ARM_32 as well as ARM_64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_root_level can be obtained from pa_range_info[].sl0.
R
Refer ARM DDI 0406C.d ID040418, B3-1345,
"A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
- With a first-level lookup, accessing a first-level translation
table with 2-16 entries.
- With a second-level lookup, accessing a set of concatenated
handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
parameters. Then frame numbers are obtained from addr and len by right shifting
with PAGE_SHIFT. The page frame numbers are saved using unsigned long.
Now if 64-bit >> PAGE_SHIFT, the result will have 52-bits as valid. On a
As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring the declaring an array
of p
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
configs to choose if the physic
dt_device_get_address() can accept uint64_t only for address and size.
However, the address/size denotes physical addresses. Thus, they should
be represented by 'paddr_t'.
Consequently, we introduce a wrapper for dt_device_get_address() ie
dt_device_get_paddr() which accepts address/size as paddr_t
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.
This also helps us as p2maddr is 'paddr_t' (wh
rangeset_{xxx}_range() functions are invoked with 'start' and 'size' as
arguments which are either 'uint64_t' or 'paddr_t'. However, the function
accepts 'unsigned long' for 'start' and 'size'. 'unsigned long' is 32 bits for
Arm32. Thus, there is an implicit downcasting from 'uint64_t'/'paddr_t' to
The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
currently accept or return 64-bit values.
In future when we support 32-bit physical address, these DT functions are
expected to accept/return 32-bit or 64-bit values (depending on the width of
physical address). Also, we
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32-bit
physical addresses and has no suppor
>
>
>>
Can we move this somewhere else to avoid adding extra padding? Also
shouldn't this be protected with #ifdef CONFIG_ARM_64 to make clear this
is not supported on Xen 32-bit?
>>> Yes, I’ll move it and protect with CONFIG_ARM_64, is it ok for you if I
>>> move it after:
>>>
flight 180237 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180237/
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 Thu, 13 Apr 2023, Marek Marczykowski-Górecki wrote:
> This should give a lot more useful information in case of a failure, and
> also enable some asserts for extra checks.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/gitlab-ci/test.yaml | 8
On Wed, Apr 12, 2023 at 09:54:12PM +, Volodymyr Babchuk wrote:
>
> Hi Roger,
>
> First of all, I want to provide link [1] to the RFC series where I tried
> total PCI locking rework. After discussing with Jan, it became clear for
> me, that task is much harder, than I anticipated. So, it was d
The Long Mode consistency checks exist to "ensure that the processor does not
enter an undefined mode or state that results in unpredictable behavior". APM
Vol2 Table 14-5 "Long-Mode Consistency Checks" lists them, but there is no row
preventing the OS from trying to exit Long mode while in 64bit
> On 13 Apr 2023, at 14:11, Julien Grall wrote:
>
>
>
> On 12/04/2023 10:49, Luca Fancellu wrote:
>> Save/restore context switch for SVE, allocate memory to contain
>> the Z0-31 registers whose length is maximum 2048 bits each and
>> FFR who can be maximum 256 bits, the allocated memory depen
flight 180225 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180225/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail in
180211 pass in 180225
test-amd64-am
Hi Henry,
On Thu, Apr 13, 2023 at 1:47 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 15/22] xen/arm: ffa: add defines for sharing memory
> >
> > Adds defines needed for sharing using the function FFA_MEM_SHARE and
> > friends.
>
> Same as my comment
> On 13 Apr 2023, at 14:30, Julien Grall wrote:
>
>
>
> On 13/04/2023 14:24, Luca Fancellu wrote:
>> Hi Julien,
>
> Hi Luca,
>
@@ -594,6 +597,7 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
unsigned int max_vcpus;
unsigned int fla
Hi Henry,
On Thu, Apr 13, 2023 at 1:31 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 14/22] xen/arm: move regpair_to_uint64() and
> > uint64_to_regpair() to regs.h
> >
> > Moves the two helper functions regpair_to_uint64() and
> > uint64_to_regpair(
Hi Henry,
On Thu, Apr 13, 2023 at 1:24 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 21/22] xen/arm: ffa: list current limitations
> >
> > Adds a comments with a list of unsupported FF-A interfaces and
>
> Typo: s/a comments/comments/
OK
>
> > lim
Hi Henry,
On Thu, Apr 13, 2023 at 1:20 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 22/22] docs: add Arm FF-A mediator
> >
> > Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
> > Partition in secure world.
> >
> > [1] https:/
Hi Henry,
On Thu, Apr 13, 2023 at 12:55 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 07/22] xen/arm: ffa: enforce dependency on 4k pages
> >
> > Adds a BUILD_BUG_ON() to assert the dependency on 4k pages in the FF-A
> > mediator since the current i
Hi Jens,
> -Original Message-
> From: Jens Wiklander
> Subject: Re: [XEN PATCH v8 05/22] xen/arm: ffa: add flags for
> FFA_PARTITION_INFO_GET
> > > +#define FFA_PART_PROP_DIRECT_REQ_RECV BIT(0, U)
> > > +#define FFA_PART_PROP_DIRECT_REQ_SEND BIT(1, U)
> > > +#define FFA_PART_PROP_INDI
Hi Henry,
On Thu, Apr 13, 2023 at 12:51 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 06/22] xen/arm: ffa: add defines for framework direct
> > request/response messages
> >
> > Adds defines for framework direct request/response messages.
>
> Same h
On Thu, Apr 13, 2023 at 12:28 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 05/22] xen/arm: ffa: add flags for
> > FFA_PARTITION_INFO_GET
> >
> > Defines flags used for the function FFA_PARTITION_INFO_GET.
>
> Nit: Similarly as my comment for patch #
Hi,
> On 13 Apr 2023, at 15:27, Julien Grall wrote:
>
>
>
> On 13/04/2023 14:20, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 13 Apr 2023, at 15:15, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 13/04/2023 08:14, Jens Wiklander wrote:
Adds support for sending a FF-A direct request. Checks
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
>
>
> Add device_tree_find_node_by_path() to find a matching node with path for a
> dt_device_node.
>
> Reason behind this function:
> Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
> device_tree_flattened) is cre
Hi Henry,
On Thu, Apr 13, 2023 at 12:18 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 04/22] xen/arm: ffa: add remaining SMC function IDs
> >
> > Adds the remaining SMC function IDs from FF-A 1.1 specification.
>
> Nit: I would suggest that in commi
On 13/04/2023 14:24, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
@@ -594,6 +597,7 @@ int arch_sanitise_domain_config(struct
xen_domctl_createdomain *config)
unsigned int max_vcpus;
unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
unsigned int flags
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -2160,6 +2160,13 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>> perfc_incr(trap_sysreg);
>> do_sysreg(regs, hsr);
>> break;
>> +case HSR_EC_SVE:
>> +GUEST_BUG_ON(regs_mode_is_32bit(r
On 13/04/2023 1:26 pm, Julien Grall wrote:
>> +static int ffa_domain_init(struct domain *d)
>> +{
>> + struct ffa_ctx *ctx;
>> +
>> + if ( !ffa_version )
>> + return -ENODEV;
>> +
>> + ctx = xzalloc(struct ffa_ctx);
>> + if ( !ctx )
>> + return -ENOMEM;
>> +
>> + d->arc
On 13/04/2023 14:20, Bertrand Marquis wrote:
Hi Julien,
On 13 Apr 2023, at 15:15, Julien Grall wrote:
Hi,
On 13/04/2023 08:14, Jens Wiklander wrote:
Adds support for sending a FF-A direct request. Checks that the SP also
supports handling a 32-bit direct request. 64-bit direct requests a
Hi Julien,
>> @@ -594,6 +597,7 @@ int arch_sanitise_domain_config(struct
>> xen_domctl_createdomain *config)
>> unsigned int max_vcpus;
>> unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
>> unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu |
>> XEN_DOM
Hi,
On 13/04/2023 08:14, Jens Wiklander wrote:
+static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
+ uint8_t msg)
+{
+uint32_t exp_resp = FFA_MSG_FLAG_FRAMEWORK;
+int32_t res;
+
+if ( msg == FFA_MSG_SEND_VM_CREATED )
+ex
Hi Julien,
> On 13 Apr 2023, at 15:15, Julien Grall wrote:
>
> Hi,
>
> On 13/04/2023 08:14, Jens Wiklander wrote:
>> Adds support for sending a FF-A direct request. Checks that the SP also
>> supports handling a 32-bit direct request. 64-bit direct requests are
>> not used by the mediator itsel
Hi,
On 13/04/2023 08:14, Jens Wiklander wrote:
Adds support for sending a FF-A direct request. Checks that the SP also
supports handling a 32-bit direct request. 64-bit direct requests are
not used by the mediator itself so there is not need to check for that.
Signed-off-by: Jens Wiklander
---
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
>
>
> Rename overlay_get_target() to fdt_overlay_target_offset() and remove static
> function type.
>
> This is done to get the target path for the overlay nodes which is very useful
> in many cases. For example, Xen hypervisor needs it when
On 12/04/2023 10:49, Luca Fancellu wrote:
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how ma
Hi,
On 12/04/2023 10:49, Luca Fancellu wrote:
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
Changes from v4:
- No changes
Changes from v3:
- No changes
Changes from v2:
- No changes
Changes from v1:
- No
Hi,
On 12/04/2023 10:49, Luca Fancellu wrote:
Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
to allow the domain to have an information about the SVE feature
and the number of SVE register bits that are allowed for this
domain.
sve_vl field is the vector length in bits divide
Hi Luca,
> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>
> Enable Xen to handle the SVE extension, add code in cpufeature module
> to handle ZCR SVE register, disable trapping SVE feature on system
> boot only when SVE resources are accessed.
> While there, correct coding style for the commen
Hi Luca,
> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>
> Add sve_vl field to arch_domain and xen_arch_domainconfig struct,
> to allow the domain to have an information about the SVE feature
> and the number of SVE register bits that are allowed for this
> domain.
>
Please mention in the c
Hi Luca,
> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>
> When a guest is allowed to use SVE, expose the SVE features through
> the identification registers.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> CHanges from v4:
> - no changes
> Changes
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [XEN PATCH v8 08/22] xen/arm: ffa: add support for FFA_ID_GET
> >> +static uint16_t get_vm_id(const struct domain *d)
> >> +{
> >> +/* +1 since 0 is reserved for the hypervisor in FF-A */
> >> +return d->domain_id
On 13/04/2023 12:07, Henry Wang wrote:
Hi Jens,
-Original Message-
Subject: [XEN PATCH v8 08/22] xen/arm: ffa: add support for FFA_ID_GET
Adds support for the FF-A function FFA_ID_GET to return the ID of the
calling client.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.
Hi Jens,
Mainly reviewing this patch from a Xen PoV. I will leave the others to
review the patch from a spec-compliance PoV.
On 13/04/2023 08:14, Jens Wiklander wrote:
+struct ffa_ctx {
+/* FF-A version used by the guest */
+uint32_t guest_vers;
+};
+
+/* Negotiated FF-A version to us
On 13/04/2023 1:23 pm, Marek Marczykowski-Górecki wrote:
> This should give a lot more useful information in case of a failure, and
> also enable some asserts for extra checks.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
I'll merge this shortly.
This should give a lot more useful information in case of a failure, and
also enable some asserts for extra checks.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/gitlab-ci/test.yaml | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/automation/gitlab-ci/test.y
On 12/04/2023 7:35 pm, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 1454c1732d95..3c8d28a2d8be 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2340,6 +2340,21 @@ int hvm_set_cr0(unsigned long value, bool may_defer)
> }
>
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 03/22] tools: add Arm FF-A mediator
>
> Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
> guest is trusted to use FF-A.
>
> Signed-off-by: Jens Wiklander
> Reviewed-by: Bertrand Marquis
Reviewed-by: Henry Wan
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 16/22] xen/arm: ffa: add ABI structs for sharing
> memory
>
> Adds the ABI structs used by function FFA_MEM_SHARE and friends for
> sharing memory.
>
> Signed-off-by: Jens Wiklander
> Reviewed-by: Bertrand Marquis
Reviewed-by: Hen
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 15/22] xen/arm: ffa: add defines for sharing memory
>
> Adds defines needed for sharing using the function FFA_MEM_SHARE and
> friends.
Same as my comments in previous patches, I would suggest to also mention
the references in commit
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 14/22] xen/arm: move regpair_to_uint64() and
> uint64_to_regpair() to regs.h
>
> Moves the two helper functions regpair_to_uint64() and
> uint64_to_regpair() from xen/arch/arm/tee/optee.c to the common arm
> specific regs.h. This enab
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 21/22] xen/arm: ffa: list current limitations
>
> Adds a comments with a list of unsupported FF-A interfaces and
Typo: s/a comments/comments/
> limitations in the implemented FF-A interfaces.
>
> Signed-off-by: Jens Wiklander
> --
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 22/22] docs: add Arm FF-A mediator
>
> Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
>
> [1] https://developer.arm.com/documentation/den0077/latest
> Signed-off-by: Jens Wiklander
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 09/22] xen/arm: ffa: add direct request support
>
> Adds support for sending a FF-A direct request. Checks that the SP also
> supports handling a 32-bit direct request. 64-bit direct requests are
> not used by the mediator itself so t
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 08/22] xen/arm: ffa: add support for FFA_ID_GET
>
> Adds support for the FF-A function FFA_ID_GET to return the ID of the
> calling client.
>
> Signed-off-by: Jens Wiklander
> ---
> xen/arch/arm/tee/ffa.c | 21 +
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 07/22] xen/arm: ffa: enforce dependency on 4k pages
>
> Adds a BUILD_BUG_ON() to assert the dependency on 4k pages in the FF-A
> mediator since the current implementation only works if Xen page size is
> the same as the FFA page size.
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 06/22] xen/arm: ffa: add defines for framework direct
> request/response messages
>
> Adds defines for framework direct request/response messages.
Same here, it actually took me a while to find the related chapters
about this patch,
Hi,
Gitlab has started very occasionally failing with this:
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/4104532296
While the individual log lines appear to be in the right order, the
build is clearly failing because compiling decode.o is happening before
the x86-emulate.h symlink is
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 05/22] xen/arm: ffa: add flags for
> FFA_PARTITION_INFO_GET
>
> Defines flags used for the function FFA_PARTITION_INFO_GET.
Nit: Similarly as my comment for patch #4, I would suggest that in
commit message you can mention the documen
Hi Jens,
> -Original Message-
> Subject: [XEN PATCH v8 04/22] xen/arm: ffa: add remaining SMC function IDs
>
> Adds the remaining SMC function IDs from FF-A 1.1 specification.
Nit: I would suggest that in commit message you can mention the documentation
number you used. During my review
Hi,
On 11/04/2023 20:16, Vikram Garhwal wrote:
Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to unflatten_device_tree().
2. Remove static function type.
3. Add handling of memory allocation. This will be useful in dynamic node
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
>
>
> Introduce a config option where the user can enable support for
> adding/removing
> device tree nodes using a device tree binary overlay.
>
> Signed-off-by: Vikram Garhwal
> ---
> SUPPORT.md | 6 ++
> xen/arch/arm/Kcon
Hi,
On 13/04/2023 10:45, Michal Orzel wrote:
On 11/04/2023 21:16, Vikram Garhwal wrote:
Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to unflatten_device_tree().
2. Remove static function type.
I think there was no need to touch th
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
>
>
> Following changes are done to __unflatten_device_tree():
> 1. __unflatten_device_tree() is renamed to unflatten_device_tree().
> 2. Remove static function type.
I think there was no need to touch this function in patch 1 if you
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
>
>
> Remove __init from following function to access during runtime:
> 1. map_irq_to_domain()
> 2. handle_device_interrupt()
s/interrupt/interrupts/ since there is no handle_device_interrupt() function.
> 3. map_range_to_domain(
flight 180220 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180220/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180207
test-amd64-amd64-xl-qemuu-ws16-amd6
On Wed, 12 Apr 2023 at 20:01, David Woodhouse wrote:
>
> On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> > On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
> > >
> > > Some Coverity fixes and minor cleanups. And most notably, dropping
> > > support for Xen libraries older than 4.7.1
flight 180229 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180229/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 42b0443599a69c703034079cf2bd389fa3a6bfde
baseline version:
ovmf 5430f7f60dee3747fff90
flight 180222 linux-linus real [real]
flight 180228 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180222/
http://logs.test-lab.xenproject.org/osstest/logs/180228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Adds defines needed for sharing using the function FFA_MEM_SHARE and
friends.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 74b8c517afb
Moves the two helper functions regpair_to_uint64() and
uint64_to_regpair() from xen/arch/arm/tee/optee.c to the common arm
specific regs.h. This enables reuse of these functions in the FF-A
mediator in a subsequent patch.
Signed-off-by: Jens Wiklander
Reviewed-by: Michal Orzel
Reviewed-by: Bertr
1 - 100 of 121 matches
Mail list logo
