to
do_IRQ() instead of do_sgi(). The latter still handles the statically
assigned SGI handlers like for instance GIC_SGI_CALL_FUNCTION.
[1] https://developer.arm.com/documentation/den0094/
Signed-off-by: Jens Wiklander
Acked-by: Julien Grall
Cheers,
--
Julien Grall
d or Rahul.
Cheers,
--
Julien Grall
Hi Edgar,
On 22/05/2024 14:28, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Move more functions that are only called at init to
the .init.text section.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Julien Grall
This also needs a reviewed-by from either Bertrand or Rahu
Hi Volodymyr,
On 04/06/2024 12:56, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi Volodymyr,
On 31/05/2024 18:49, Volodymyr Babchuk wrote:
Extend TEE mediator interface with two functions :
- tee_get_type_from_dts() returns TEE type based on input string
is not
preemptible and therefore some work is needed to handle such superpages,
for which at some point Xen might end up freeing memory and therefore
for such a big mapping it could end up in a very long operation.
Signed-off-by: Penny Zheng
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
Cheers
On 03/06/2024 10:50, Jens Wiklander wrote:
Hi Julien,
Hi Jens,
On Mon, Jun 3, 2024 at 11:12 AM Julien Grall wrote:
Hi Jens,
On 03/06/2024 10:01, Jens Wiklander wrote:
On Fri, May 31, 2024 at 4:28 PM Bertrand Marquis
wrote:
Hi Jens,
On 29 May 2024, at 09:25, Jens Wiklander
activated in libxl.
Also, arm/arch_sanitise_domain_config is extended to not allow requesting
non-zero altp2ms.
Signed-off-by: Petr Beneš
For the small change in Arm:
Acked-by: Julien Grall # arm
Cheers,
--
Julien Grall
+++---
tools/ocaml/libs/xc/xenctrl_stubs.c | 4 +++-
xen/arch/arm/domain.c | 2 +-
For the small change in Arm:
Acked-by: Julien Grall # arm
xen/arch/x86/domain.c | 4 ++--
xen/arch/x86/hvm/hvm.c | 2 +-
xen/include/public/domctl.h | 4
_vcpu_ioreq_completion(enum vio_completion completion);
+extern bool (*arch_vcpu_ioreq_completion)(enum vio_completion completion);
int arch_ioreq_server_map_pages(struct ioreq_server *s);
void arch_ioreq_server_unmap_pages(struct ioreq_server *s);
void arch_ioreq_server_enable(struct ioreq_server *s);
--
Julien Grall
d_cfg.arch.tee_type = XEN_DOMCTL_CONFIG_TEE_NONE;
+}
+
if ( dt_property_read_bool(node, "direct-map") )
{
if ( !(flags & CDF_staticmem) )
Cheers,
---
Julien Grall
created. Although, the latter is rather unlikely.
So what if the new domain has FFA enabled? Is there any potential
security issue?
Cheers,
--
Julien Grall
Hi Bertrand,
On 30/05/2024 14:22, Bertrand Marquis wrote:
On 30 May 2024, at 12:35, Julien Grall wrote:
Hi Bertrand,
On 30/05/2024 10:40, Bertrand Marquis wrote:
But we are making assumption that all TEE implementation will have its
node inside "/firmware/". I am not
/irq.c, and into .rodata for good
measure.
No functional change, but a whole lot less tangled.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
, export the existing {ack,end}_none() helpers, gaining an irq_
prefix for consisntency with everything else in no_irq_type.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
nted extra clarify, we could spell out at the beginning
of the file that this is the versions are confident with.
Cheers,
--
Julien Grall
aceholder, but AFAIK this is only for a
property. You also need to know the size in advance.
Cheers,
--
Julien Grall
On 29/05/2024 22:34, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi Volodymyr,
Can you clarify whether this is intended for the next release cycle?
Well, I don't think that this patch should be committed ASAP if this is
what you are asking about.
On 29
mulation */
bool vpl011;
+/* TEE type */
+uint16_t tee_type;
+
/* Enable/Disable PV drivers interfaces */
uint16_t dom0less_feature;
Cheers,
--
Julien Grall
, Jan Beulich wrote:
On 29.05.2024 11:59, Julien Grall wrote:
I didn't realise this was an existing comment. I think the
suggestion is
a little bit odd because you could use the atomic version of
the
helper.
Looking at Linux, the second sentence was dropped. But not
the
first
one. I would suggest
basic.c | 18
xen/arch/x86/mm/p2m.c | 68 +++--
xen/include/public/domctl.h | 20 -
xen/include/public/hvm/params.h | 9 +---
12 files changed, 215 insertions(+), 41 deletions(-)
--
Julien Grall
Hi,
On 29/05/2024 09:36, Jan Beulich wrote:
On 29.05.2024 09:50, Oleksii K. wrote:
On Tue, 2024-05-28 at 09:53 +0100, Julien Grall wrote:
+/**
+ * generic_test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ *
+ * This operation
Hi Roger,
On 28/05/2024 08:11, Roger Pau Monné wrote:
On Mon, May 27, 2024 at 10:14:59PM +0100, Julien Grall wrote:
Hi Roger,
On 23/05/2024 08:55, Roger Pau Monné wrote:
On Wed, May 22, 2024 at 06:59:20PM -0400, Stewart Hildebrand wrote:
From: Volodymyr Babchuk
Guest can try to read
the Arm version which is a no-go.
Cheers,
--
Julien Grall
);
+r = r & GENMASK_ULL((1U << dabt.size) * 8 - 1, 0);
... in some case we need to sign extend up to the width of the register
(even if the access is 8-byte). So we would need to do the masking
*before* calling sign_extend().
Cheers,
--
Julien Grall
sed:
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
but it is currently
unsupported. For now return errors for not-1:1 mapped domains.
Signed-off-by: Henry Wang
Signed-off-by: Vikram Garhwal
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 25/05/2024 00:02, Stefano Stabellini wrote:
On Fri, 24 May 2024, Julien Grall wrote:
Hi Stefano,
On 24/05/2024 23:49, Stefano Stabellini wrote:
On Fri, 24 May 2024, Julien Grall wrote:
Hi Henry,
+ Juergen as the Xenstore maintainers. I'd like his opinion on the
approach
d->arch.hvm.params[HVM_PARAM_STORE_PFN] = ~0ULL;
+
+rc = alloc_xenstore_page(d);
+if ( rc < 0 )
+return rc;
}
return rc;
--
Julien Grall
Hi Stefano,
On 24/05/2024 23:49, Stefano Stabellini wrote:
On Fri, 24 May 2024, Julien Grall wrote:
Hi Henry,
+ Juergen as the Xenstore maintainers. I'd like his opinion on the approach.
The documentation of the new logic is in:
https://lore.kernel.org/xen-devel/20240517032156.1490515-5
< 0 )
+ return rc;
}
return rc;
Cheers,
--
Julien Grall
sending. Anyway, I
will correct this in v4 with your Reviewed-by tag taken. Thanks for
pointing this out.
I don't think there is a need to resend a patch just for fixing this typo. It
can be done on commit.
Fixed and committed.
Cheers,
~Michal
--
Julien Grall
physical host bridge.
So, all access to the host bridge itself needs to be trapped and
emulated.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
Acked-by: Roger Pau Monné
For Arm:
Acked-by: Julien Grall
One unrelated question below
-by: Stewart Hildebrand
With one remark below, for Arm:
Acked-by: Julien Grall
[...]
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index 23722634d50b..98b294f09688 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -81,6 +81,30 @@ static int add_virtual_device
f the LGTM to me but I don't feel confortable to do all those
changes on commit. So this will want a respin.
For simplicity, you can only resend this patch.
Cheers,
--
Julien Grall
domu.dtbo >
/sys/kernel/config/device-tree/overlays/new_overlay/dtbo
+
+Finally, if needed, the relevant Linux kernel drive can be probed:
+
+(domU) modprobe module_name.ko
+
+[1] https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt
Cheers,
--
Julien Grall
OMAIN indicates the presence of
+ * libxl_dt_overlay_domain.
+ */
+#define LIBXL_HAVE_OVERLAY_DOMAIN 1
I think this wants to gain DT_ just before OVERLAY. So from the name it
is clearer we are talking about the Device-Tree overlay and not
filesystem (or anything else where overlays are involved).
Che
t_size == 0 || op->overlay_fdt_size > KB(500) )
Please add #define DT_OVERLAY_MAX_SIZE KB(500) and use it here and the
other place.
Cheers,
--
Julien Grall
wants to be:
/*
* libxl_domain_build_info has the arch_arm.nr_spis field
*/
#define LIBXL_HAVE_BUILDINFO_ARCH_NR_SPIS 1
This would also clarify that the field is Arm specific.
Cheers,
--
Julien Grall
Hi Oleksii,
On 24/05/2024 09:58, Oleksii K. wrote:
On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
#include
+/**
+ * generic__test_and_set_bit - Set a bit and return its old
value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic
l.h
index 62cb07dea6..6cc6d6bf6a 100644
--- a/tools/include/libxl.h
+++ b/tools/include/libxl.h
I think you also need to introduce LIBXL_HAVE_...
Cheers,
--
Julien Grall
.c
+++ b/tools/xl/xl_parse.c
@@ -2935,6 +2935,9 @@ skip_usbdev:
}
}
+if (!xlu_cfg_get_long (config, "nr_spis", , 0))
+b_info->arch_arm.nr_spis = l;
+
parse_vkb_list(config, d_config);
d_config->virtios = NULL;
Cheers,
--
Julien Grall
dom0) xl dt-overlay detach overlay.dtbo $domid
+(dom0) xl dt-overlay remove overlay.dtbo
I assume we have safety check in place to ensure we can't remove the
device if it is already attached. Is that correct?
Cheers,
--
Julien Grall
size. */
#define XEN_DOMCTL_DT_OVERLAY_ATTACH1
-uint8_t overlay_op; /* IN: Attach. */
+#define XEN_DOMCTL_DT_OVERLAY_DETACH2
+uint8_t overlay_op; /* IN: Attach/Detach. */
Changing the comment for every operation we add is not really scalable
:). If you want an explanation, can it be generic?
uint8_t pad[3]; /* IN: Must be zero. */
};
#endif
Cheers,
--
Julien Grall
domctl(struct domain *d, struct xen_domctl_dt_overlay *op);
#else
#include
static inline long dt_overlay_sysctl(struct xen_sysctl_dt_overlay *op)
{
return -EOPNOTSUPP;
}
NIT: Newline here please.
+static inline long dt_overlay_domctl(struct domain *d,
+ struct xen_domctl_dt_overlay *op)
+{
+return -EOPNOTSUPP;
+}
#endif
#endif /* __XEN_DT_OVERLAY_H__ */
Cheers,
--
Julien Grall
lly functional, so I didn't
split the toolstack patch (#8).
So I was asking to split so we can get some of the work merged for 4.19.
Can you clarify, whether the intention is to merge only patches #1-5?
Cheers,
--
Julien Grall
:
Reviewed-by: Julien Grall
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index b9463a5f27..048e12c562 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -876,8 +876,11 @@ int vgic_connect_hw_irq(struct domain *d, struct vcpu
*vcpu,
if ( connect
; and "disable". Set the XEN_DOMCTL_CDF_iommu at domain
construction time based on the property.
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
On 23/05/2024 15:11, Oleksii K. wrote:
On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
Hi Oleksii,
Hi Julien,
On 17/05/2024 14:54, Oleksii Kurochko wrote:
diff --git a/xen/arch/arm/arm64/livepatch.c
b/xen/arch/arm/arm64/livepatch.c
index df2cebedde..4bc8ed9be5 100644
--- a/xen
what Jan wrote. I don't have any strong opinion on which
order they should be merged. But, if your series is intended to be
merged before Andrew's one then please rebase to vanilla staging.
I looked at the rest of the patch and it LGTM.
Cheers,
--
Julien Grall
he only two reasons I am not providing an ack is the:
* Explanation for the removal of asm/bitops.h in livepatch.c
* The placement of the comments
There are not too important for me.
Cheers,
--
Julien Grall
Hi Oleksii,
On 23/05/2024 09:04, Oleksii K. wrote:
On Wed, 2024-05-22 at 21:50 +0100, Julien Grall wrote:
Hi,
Adding Oleksii as the release manager.
On 22/05/2024 19:27, Tamas K Lengyel wrote:
On Fri, May 10, 2024 at 8:32 AM Alessandro Zucchelli
wrote:
In order to comply to MISRA C:2012
you want to be release-ack every bug until the hard code freeze?
Or would you be fine to levea the decision to the maintainers?
Cheers,
--
Julien Grall
On 22/05/2024 14:47, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
On 22 May 2024, at 14:25, Julien Grall wrote:
diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c
index 41fcca011cf4..b496266deef6 100644
--- a/xen/arch/arm/mmu/p2m.c
+++ b/xen/arch/arm/mmu/p2m.c
@@ -753,17 +753,9
every 2MB rather than just for the
p2m_is_foreign().
BTW, p2m_put_l3_page() has also another case. Should we consider to
handle preemption for it too?
+ hypercall_preempt_check() )
{
rc = -ERESTART;
break;
Cheers,
--
Julien Grall
Hi Henry,
On 22/05/2024 02:22, Henry Wang wrote:
On 5/22/2024 9:16 AM, Stefano Stabellini wrote:
On Wed, 22 May 2024, Henry Wang wrote:
Hi Julien,
On 5/21/2024 8:30 PM, Julien Grall wrote:
Hi,
On 21/05/2024 05:35, Henry Wang wrote:
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic
more data than requested: i.e. guest issues LDRB instruction
to read one byte, but we are writing 0x in the target
register.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
Acked-by: Julien Grall
Cheers,
--
Julien Grall
a concern if we don't
reset them?
Cheers,
--
Julien Grall
Hi Henry,
On 20/05/2024 02:01, Henry Wang wrote:
Hi Julien,
On 5/19/2024 7:08 PM, Julien Grall wrote:
Hi,
On 17/05/2024 07:03, Henry Wang wrote:
@@ -444,14 +444,18 @@ int vgic_connect_hw_irq(struct domain *d,
struct vcpu *v, unsigned int virq,
{
/* The VIRQ should
;
+
This is not quite the samem position as x86. The system state will be
updated just before do_presmp_initcalls().
Can you explain the difference?
Cheers,
--
Julien Grall
id != desc->irq &&
+ (irq->active || irq->pending_latch) )
Same here, this should be
+ if ( (desc && irq->hwintid != desc->irq) ||
+ irq->active || irq->pending_latch )
I think the new vGIC doesn't have the same problem because it looks like
the IRQ lock will be taken for any access to 'irq'.
Cheers,
--
Julien Grall
the
"passthrough" flag separately?
Also, shouldn't we throw a panic if passthrough = "enabled" but the
IOMMU is enabled?
d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
if ( !dt_property_read_u32(node, "nr_spis", _cfg.arch.nr_spis) )
Cheers,
--
Julien Grall
. So fix the issue by
releasing the lock after handle_device().
Fixes: 7e5c4a8b86f1 ("xen/arm: Implement device tree node removal
functionalities")
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Luca,
On 15/05/2024 11:05, Luca Fancellu wrote:
On 14 May 2024, at 22:06, Julien Grall wrote:
Hi,
On 14/05/2024 08:53, Luca Fancellu wrote:
Hi Julien,
Thanks for having a look on the patch,
On 13 May 2024, at 22:54, Julien Grall wrote:
Hi Luca,
On 25/04/2024 14:11, Luca Fancellu
The series is now committed. Thanks for the clean-up!
Cheers,
--
Julien Grall
Hi,
On 14/05/2024 08:53, Luca Fancellu wrote:
Hi Julien,
Thanks for having a look on the patch,
On 13 May 2024, at 22:54, Julien Grall wrote:
Hi Luca,
On 25/04/2024 14:11, Luca Fancellu wrote:
Currently the code is listing device tree reserve map regions
as reserved memory for Xen
would agree it could be common.
Cheers,
--
Julien Grall
more data than requested: i.e. guest issues LDRB instruction
to read one byte, but we are writing 0x in the target
register.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
With one remark below:
Acked-by: Julien Grall
---
v9->10:
* New patch in
Hi Stefano,
On 14/05/2024 01:09, Stefano Stabellini wrote:
On Mon, 13 May 2024, Julien Grall wrote:
Hi Stefano,
title: Is this the only violation we have in Xen? If so, then please add the
subsystem in the title.
The only remaining violations are about the use of the "toupper&q
;open" objections.
I don't view Jan's objections as unreasonable in particular for the
consistency part.
As a separate aspect: I can't assume anymore that it is just coincidence
that you taking such a controversial action is at a time when I'm away.
Cheers,
--
Julien Grall
ap_pages);
}
mi->nr_mods = 0;
@@ -702,7 +743,7 @@ void __init populate_boot_allocator(void)
}
#endif
-fw_unreserved_regions(s, e, init_boot_pages, 0);
+ fw_unreserved_regions(s, e, init_boot_pages);
s = n;
}
}
Cheers,
--
Julien Grall
this
by adding them to the bootinfo.reserved_mem at early stage.
Do we have enough space in bootinfo.reserved_mem for them?
The rest of the changes LGTM.
Cheers,
--
Julien Grall
of the code, we have:
#define switch_code (opt_conswitch[0] - 'a' + 1)
Can you confirm whether this is not somehow adding a new violation?
Cheers,
--
Julien Grall
all the mappings, find some space for the hypervisor
regions.
Any other suggestions?
Cheers,
--
Julien Grall
rvisor to provide a large enough region. So we should
check the offset against the size.
Cheers,
--
Julien Grall
e them as suggested if both of you are
ok with moving them to the arch header.
... I don't think they should be shared.
Cheers,
--
Julien Grall
) reserved space that will be allocated on
demand (IOW there is no associated physical memory). If it doesn't work
for direct mapped domain, then another solution is to have a toolstack
hypercall to allocate a GFN (they don't need to be contiguous) and the
backing memory.
Cheers,
--
Julien Grall
internal decision
of the toolstack. For the rest of the system, they need to access
HVM_PARAM_*. So it doesn't feel like they should be part of the shared
headers.
If there is a strong reason to include them, then I think they all
should be prefixed with GUEST_MAGIC_*.
Cheers,
+
#define GUEST_RAM_BANKS 2
/*
--
Julien Grall
we injected the IRQ. Instead, the
pending_irq is just in list, so we will possibly need to store the vCPU
ID for convenience.
Cheers,
--
Julien Grall
Hi Roger,
On 09/05/2024 13:58, Roger Pau Monné wrote:
On Thu, May 09, 2024 at 01:12:00PM +0100, Julien Grall wrote:
Hi,
On 09/05/2024 12:28, Roger Pau Monné wrote:
On Thu, May 09, 2024 at 10:50:56AM +0100, Julien Grall wrote:
On 09/05/2024 09:13, Roger Pau Monné wrote:
On Wed, May 08
On 10/05/2024 22:11, Andrew Cooper wrote:
On 10/05/2024 10:08 pm, Julien Grall wrote:
Hi Juergen,
On 10/05/2024 15:16, Juergen Gross wrote:
With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit
(or other x86 maintainers) to confirm they are happy with the
proposed x86 security supported limit the SUPPORT.md.
For Arm (only):
Acked-by: Julien Grall
---
V5:
- new patch (Jan Beulich)
V7:
- add SUPPORT.md and CHANGELOG.md entries
---
CHANGELOG.md | 2 ++
SUPPORT.md | 5 +
xen
on commit.
Cheers,
--
Julien Grall
Hi,
On 09/05/2024 16:31, Henry Wang wrote:
On 5/9/2024 4:46 AM, Julien Grall wrote:
Hi Henry,
[...]
we have 3 possible states which can be read from LR for this case :
active, pending, pending and active.
- I don't think we can do anything about the active state, so we
should return -EBUSY
Hi,
On 09/05/2024 12:28, Roger Pau Monné wrote:
On Thu, May 09, 2024 at 10:50:56AM +0100, Julien Grall wrote:
On 09/05/2024 09:13, Roger Pau Monné wrote:
On Wed, May 08, 2024 at 11:11:04PM +0100, Julien Grall wrote:
Also the interactions with the remote domain would need to be audited
/
#endif /* _ASM_ARM_MEM_ACCESS_H */
/*
Cheers,
--
Julien Grall
On 09/05/2024 09:13, Roger Pau Monné wrote:
On Wed, May 08, 2024 at 11:11:04PM +0100, Julien Grall wrote:
Hi,
CC-ing Roger as he is working on adding support for the foreign mapping on
x86. Although, I am not expecting any implication as only 4KB mapping should
be supported.
I don't think
Hi,
CC-ing Roger as he is working on adding support for the foreign mapping
on x86. Although, I am not expecting any implication as only 4KB mapping
should be supported.
On 08/05/2024 22:05, Julien Grall wrote:
On 07/05/2024 14:30, Luca Fancellu wrote:
On 7 May 2024, at 14:20, Julien Grall
On 07/05/2024 14:30, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
On 7 May 2024, at 14:20, Julien Grall wrote:
Hi Luca,
On 23/04/2024 09:25, Luca Fancellu wrote:
From: Penny Zheng
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could
Hi Henry,
On 08/05/2024 08:49, Henry Wang wrote:
On 5/8/2024 5:54 AM, Julien Grall wrote:
Hi Henry,
What if the DT overlay is unloaded and then reloaded? Wouldn't the
same interrupt be re-used? As a more generic case, this could also
be a new bitstream for the FPGA.
But even
Hi Tamas,
On 08/05/2024 17:01, Tamas K Lengyel wrote:
On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli
wrote:
On 2024-05-03 11:32, Julien Grall wrote:
Hi,
On 03/05/2024 08:09, Alessandro Zucchelli wrote:
On 2024-04-29 17:58, Jan Beulich wrote:
On 29.04.2024 17:45, Alessandro
Hi Henry,
On 06/05/2024 09:32, Henry Wang wrote:
On 5/1/2024 4:13 AM, Julien Grall wrote:
Hi Henry,
On 30/04/2024 04:50, Henry Wang wrote:
On 4/25/2024 10:28 PM, Julien Grall wrote:
Thanks for your feeedback. After checking the b8577547236f commit
message I think I now understand your point
On 07/05/2024 17:55, Edgar E. Iglesias wrote:
On Tue, May 7, 2024 at 11:57 AM Julien Grall wrote:
Hi Julien,
Hi Edgar,
The reason I choose FUNC for the start of the symbol is because these
symbols contain
executable code (not only a table of pointers to code somewhere else)
and the ELF
Instead, we should introduce a new XL configuration to let the user
decide the number of SPIs. I would suggest to name "nr_spis" to match
the DT bindings.
Cheers,
--
Julien Grall
. put_page() can free memory.
This could be a very long operation.
Have you benchmark how long it would take?
Cheers,
--
Julien Grall
value, then let's spell it out in the description.
Cheers,
--
Julien Grall
Hi Stefano,
On 03/05/2024 20:07, Stefano Stabellini wrote:
On Fri, 3 May 2024, Julien Grall wrote:
[...]
So are you saying that from Xen point of view, you are expecting no difference
between 256 and 512. And therefore you would be happy if to backport patches
if someone find differences
o the rest of bpi.S.
So I think we want to switch all the ENTRY() to LABEL().
Cheers,
--
Julien Grall
)
*/
init_maintenance_interrupt();
init_timer_interrupt();
+init_tee_interrupt();
local_abort_enable();
And plumb through the TEE subsystem.
Cheers,
--
Julien Grall
for the lock. From my
understanding, dt_host_lock is meant to ensure that the DT node will not
disappear behind your back. So in theory, shouldn't the lock be taken as
soon as you get hold of device_node?
Cheers,
--
Julien Grall
rq_enable, _info, 1);
+if (!irq_info.called)
+printk(XENLOG_ERR "ffa: on_selected_cpus(cpumask_of(%u)) failed\n",
+ cpu);
+/*
+ * The irqaction is unused and must be freed if irq_info.action is
+ * non-NULL at this stage.
+ */
+XFREE(irq_info.action);
+break;
+default:
+break;
+}
+
+return 0;
+}
Cheers,
--
Julien Grall
1 - 100 of 10605 matches
Mail list logo
