Hi Stefano,
On 06/06/2019 23:21, Stefano Stabellini wrote:
On Thu, 6 Jun 2019, Julien Grall wrote:
On 06/06/2019 09:42, Jan Beulich wrote:
On 05.06.19 at 23:38, wrote:
On 6/5/19 9:29 PM, Stefano Stabellini wrote:
My vote is to backport to both. Jan/others please express your opinion.
To
On 06/06/2019 17:02, Julien Grall wrote:
Hi Volodymyr,
On 5/21/19 10:25 PM, Volodymyr Babchuk wrote:
+static inline bool tee_handle_call(struct cpu_user_regs *regs)
+{
+ return false;
+}
+
+static inline int tee_domain_init(struct domain *d, uint16_t tee_type)
+{
+ return -ENODEV
(+ Committers)
Ping again... I have quite a few patches blocked on this work.
Cheers,
On 29/05/2019 17:44, Julien Grall wrote:
Gentle ping.
On 20/05/2019 20:53, Julien Grall wrote:
Hi,
On 20/05/2019 19:56, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The AIVIVT is a
/archives/html/xen-devel/2019-05/msg01708.html
On 29/05/2019 17:44, Julien Grall wrote:
Gentle ping
On 14/05/2019 13:11, Julien Grall wrote:
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB
(+ Committers)
Ping again... I have some upcoming patches that are blocked on this work...
Cheers,
On 29/05/2019 18:23, Julien Grall wrote:
Hi,
Gentle ping...
Cheers,
On 14/05/2019 13:31, Julien Grall wrote:
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
Hi,
On 05/06/2019 11:19, Julien Grall wrote:
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the
nt vCPU. So this could be a way to delay work on the CPU.
I wanted to make the context switch mostly lockless and therefore avoiding to
introduce a spinlock.
[1] https://lists.xen.org/archives/html/xen-devel/2017-11/msg00942.html
--
Julien Grall
_
On 6/10/19 7:20 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
Hi,
On 21/05/2019 22:25, Volodymyr Babchuk wrote:
This header files describes protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the
On 6/10/19 12:23 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 02.06.19 13:26, Julien Grall wrote:
+ * This should only be called with interrupt routed to guest. The flow
+ * of interrupt routed to Xen any software change of the state.
Sorry I can't parse the last sentence. It see
. This means the fixmap table will need to be hooked before
any use. For simplicity, setup_fixmap() will now do that job.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 13 +++--
1 file changed, 11
Adjust the coding style used in the comments within create_pages_tables()
Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within the function, so it does
not need to be part of the common register.
Signed-off-by: Julien Grall
Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 19
code.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index a5147c8d80..fd432ee15d 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen
A branch in the success case can be avoided by inverting the branch
condition. At the same time, remove a pointless comment as Xen can only
run at EL2.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 15
.
Lastly, document the behavior and the main registers usage within the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64
save and restore it.
While the comment state x3 will be clobbered, this is not the case. So
PRINT will use x3 to preserve lr.
Lastly, take the opportunity to move the comment on top of PRINT and use
PRINT in init_uart. Both changes will be helpful in a follow-up patch.
Signed-off-by: Julien Grall
/head.S.
For convenience I provided a branch based on staging:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch boot/arm64/v1
Cheers,
Julien Grall (17):
xen/arm64: head Mark the end of subroutines with ENDPROC
xen/arm64: head: Don't clobber x30/lr in the macro PRINT
xen/
mapping
is duplicated for each path. This is because in the future we will need
to stay longer in the ID mapping for the boot CPU.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 57 ---
1 file changed, 49 insertions(+), 8 deletions(-)
diff
the
function.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 87fcd3be6c..6aa3148192 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm
The ID map may clash with other parts of the Xen virtual memory layout.
At the moment, Xen is handling the clash by only creating a mapping to
the runtime virtual address before enabling the MMU.
The rest of the mappings (such as the fixmap) will be mapped after the
MMU is enabled. However, the co
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.
Per the Image protocol [1], the state of the cache for BSS region is not
known because it is not part of the "loaded kernel image".
This means that the cac
latter
will be clobbered by the macro print_reg.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 84e26582c4..9142b4a774 100644
impossible here as the ID map may clash
with other mappings in the runtime page-tables. This will require more
rework to avoid the problem. So for now add a TODO in the code.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 33 +
1 file changed, 17
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 7b92c1c8eb..d673f7c0d8 100644
--- a/xen/arch
After the recent rework, the CPUID is only used at the very beginning of
the secondary CPUs boot path. So there is no need to "reserve" x24 for
he CPUID.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xe
.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 6be4af7579..192af3e8a2 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
putn() and puts() are two subroutines. Add ENDPROC for the benefits of
static analysis tools and the reader.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index ddd3a33108
Hi,
On 5/29/19 7:18 PM, Julien Grall wrote:
On 29/05/2019 18:58, Oleksandr wrote:
On 29.05.19 20:44, Julien Grall wrote:
Hi Oleksandr,
Hi, Julien
On 21/05/2019 18:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a specia
On 6/10/19 4:49 PM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 31.05.19 20:11, Julien Grall wrote:
Here my take on the commit message:
gic_interrupt() was implemented using a loop to limit the cost of the
trap if there are multiple interrupts pending.
At the moment, interrupts
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volody
fo;
v->arch.saved_context.pc = (register_t)continue_new_vcpu;
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
irt_timer_restore(struct vcpu *v);
+extern void virt_timer_save(struct vcpu *v);
+extern void virt_timer_restore(struct vcpu *v);
extern void vcpu_timer_destroy(struct vcpu *v);
void vtimer_update_irqs(struct vcpu *v);
--
Julien Grall
___
Xen-dev
Hi Steano,
On 6/10/19 9:28 PM, Stefano Stabellini wrote:
On Wed, 5 Jun 2019, Julien Grall wrote:
On 05/06/2019 00:11, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed
Xen should be done with keeping in mind any patches that could be
applied on top of Xen.
So I am all hear of your arguments here... At the end, we need to come
to an agreement here as at the moment my patch can't go without your ack.
Cheers,
--
Julien Grall
__
Hi Stefano,
On 6/10/19 9:51 PM, Stefano Stabellini wrote:
On Mon, 20 May 2019, Julien Grall wrote:
On 20/05/2019 22:01, Stefano Stabellini wrote:
On Fri, 10 May 2019, Julien Grall wrote:
Feel free to suggest an in-code comment so we can discuss on the worthiness.
I suggest something like
Hi Jan,
On 6/11/19 7:43 AM, Jan Beulich wrote:
On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As build system now supports *_defconfig rules it is good to be able
to config
ou have no way to interrupt it and schedule another vCPU.
In other words, the rest of the work on that specific pCPU would be delayed.
In this context, I think Jan is seeking guarantees that the lock can be taken in
timely manner. If not, then we want to use a try-lock style.
Cheers,
On 11/06/2019 13:26, Andrii Anisov wrote:
On 11.06.19 15:12, Julien Grall wrote:
Julien, I'm not sure I understand how work on (p?)CPU could be delayed. We
are here with interrupts enabled, so here guest would just spend his own vcpu
time budget.
Xen only supports only volu
On 11/06/2019 01:06, chenbaodong wrote:
On 6/11/19 04:16, Julien Grall wrote:
Hi,
NIT: I would use "change" instead of "fix". I feel "fix" is more when there
are an actual bug.
Sound good to me.
On 6/10/19 6:07 AM, Baodong Chen wrote:
The original type is
On 11/06/2019 01:09, chenbaodong wrote:
On 6/11/19 04:11, Julien Grall wrote:
Hi,
Thank you for the patch. The title should be at max 80 characters. So how
about the following title?
"xen/arm: domain: Remove redundant memset for v->arch.saved_context"
Max 80 characters, rog
On 11/06/2019 10:41, Jan Beulich wrote:
On 11.06.19 at 11:27, wrote:
Hi Jan,
On 6/11/19 7:43 AM, Jan Beulich wrote:
On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
Julien,
On 16.05.19 at 15:37, wrote:
As bu
Hi George,
On 11/06/2019 11:12, George Dunlap wrote:
On 6/11/19 10:41 AM, Jan Beulich wrote:
On 11.06.19 at 11:27, wrote:
Hi Jan,
On 6/11/19 7:43 AM, Jan Beulich wrote:
On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wr
Hi Andrii,
Sorry for the late answer.
On 5/30/19 1:02 PM, Andrii Anisov wrote:
From: Oleksandr Tyshchenko
In case iommu_ops have been already set, we should not update it.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
Acked-by: Julien Grall
Cheers,
---
This patch
On 11/06/2019 15:37, Julien Grall wrote:
Hi Andrii,
Sorry for the late answer.
On 5/30/19 1:02 PM, Andrii Anisov wrote:
From: Oleksandr Tyshchenko
In case iommu_ops have been already set, we should not update it.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Andrii Anisov
Acked
On 11/06/2019 19:18, Volodymyr Babchuk wrote:
>
> Hi Julien,
Hi,
> Julien Grall writes:
>
>> On 06/06/2019 17:02, Julien Grall wrote:
>>> Hi Volodymyr,
>>>
>>> On 5/21/19 10:25 PM, Volodymyr Babchuk wrote:
>>>> +stat
Hi Stefano,
On 11/06/2019 19:21, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> There are few places requiring to generate offsets from an address.
>> Rather than open-coding everywhere, we can introduce a macro to do the
>> job for us.
>>
>
Hi,
On 11/06/2019 19:37, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> Currently, the MFN will be incremented even if it is invalid. This will
>> result to have a valid MFN after the first iteration.
>>
>> While this is not a major problem
. What is your end goal here?
If it is to improve the performance, then there are much bigger fish to
fry within Xen code base. I am happy to point some of them based on
where you are looking to improve.
Cheers,
--
Julien Grall
___
Xen-devel mailing
bably want some debugging
to understand the problem. Denis, Stefano, can one of you look at it?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi,
On 12/06/2019 11:08, chenbaodong wrote:
On 6/12/19 17:08, Julien Grall wrote:
Hi,
On 6/12/19 6:42 AM, Baodong Chen wrote:
Swap function can be used when calling sort().
or else, the default swap function generic_swap() is used,
which is a little inefficient.
I am not entirely convince
Hi,
On 11/06/2019 21:24, Andrew Cooper wrote:
On 11/06/2019 20:56, Julien Grall wrote:
On 11/06/2019 19:37, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first
Hi Stefano,
On 11/06/2019 23:35, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more
Hi Stefano,
On 12/06/2019 01:10, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page
Hi,
This patch is fully committed now.
Thank you for the reviews!
Cheers,
On 14/05/2019 13:11, Julien Grall wrote:
Hi all,
I spent the last few months looking at Xen boot and memory management to make
it simpler, more efficient and also more compliant in respect of the Arm Arm.
The full
Hi,
On 12/06/2019 16:54, Stefano Stabellini wrote:
On Wed, 12 Jun 2019, Julien Grall wrote:
On 12/06/2019 01:10, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
I understand we could skip the valid check on REMOVE, but should we skip
it on MODIFY too? Is that also going to
THE REST".
As MAINTAINERS is a bit the odd one, you have to add manually the maintainers of
the subsystem you modify.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ulien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
; George Dunlap
; Andrew Cooper ; Ian
Jackson ; Tim (Xen.org) ; Julien
Grall ; Tamas K Lengyel ; Jan
Beulich ; Roger Pau Monne
Subject: Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels
for sync requests.
On Thu, 2018-12-20 at 12:05 +, Paul Durrant wrote:
The memory for the
const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule,
*dtb_bootmodule;
const char* cmdline;
paddr_t dtb_paddr;
paddr_t initrd_paddr;
Cheers,
--
Julien Grall
__
lude/xen/device_tree.h
@@ -161,6 +161,8 @@ extern const void *device_tree_flattened;
int device_tree_for_each_node(const void *fdt,
device_tree_node_func func,
void *data);
+void device_tree_get_reg(const __be32 **cell,
ot;Unknown";
default: BUG();
}
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 48187e1..0ff0768 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -16,6 +16,7 @@ typedef enum {
BOOTMOD_KERNEL,
emory. So is it the correct solution?
For instance, we would request the user to provide the number of interrupts.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
reg = <0xc>;
+ti,rx-internal-delay = <0x8>;
+ti,tx-internal-delay = <0xa>;
+ti,fifo-depth = <0x1>;
+ti,rxctrl-strap-worka;
+linux,phandle = <0x2>;
+phandle = <0x2>;
+};
+};
+};
+};
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi,
Sorry for the formatting.
On Tue, 8 Jan 2019, 13:09 Stefano Stabellini,
wrote:
> On Tue, 8 Jan 2019, Stefano Stabellini wrote:
> > On Tue, 8 Jan 2019, Jan Beulich wrote:
> > > >>> On 07.01.19 at 19:29, wrote:
> > > > On Mon, 7 Jan 2019, Jan Beulich wrote:
> > > >> >>> On 04.01.19 at 18:05,
Hi,
Sorry for the formatting. Sending it from my phone.
On Wed, 9 Jan 2019, 11:03 Christopher Clark,
wrote:
> On Wed, Jan 9, 2019 at 7:56 AM Wei Liu wrote:
> >
> > On Sun, Jan 06, 2019 at 11:42:40PM -0800, Christopher Clark wrote:
> > > The register op is used by a domain to register a region
Ki
On Wed, 9 Jan 2019, 12:18 Stefano Stabellini,
wrote:
> On Wed, 9 Jan 2019, Julien Grall wrote:
> > Hi,
> > Sorry for the formatting. Sending it from my phone.
> >
> > On Wed, 9 Jan 2019, 11:03 Christopher Clark, <
> christopher.w.cl...@gmail.com> wrote:
&
On Wed, 9 Jan 2019, 12:54 Wei Liu, wrote:
> On Wed, Jan 09, 2019 at 12:02:34PM -0500, Julien Grall wrote:
> > Hi,
> >
> > Sorry for the formatting. Sending it from my phone.
> >
> > On Wed, 9 Jan 2019, 11:03 Christopher Clark, <
> christopher.w.cl...@gmail.
Hi,
Sorry for the formatting.
On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
wrote:
> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> meant to be used everywhere symbols such as _stext and _etext are used
> in the code. It can take an array type as a parameter, and it retu
on of SYMBOL.
It is not only insufficient but wrong when you read the commit message. You
also were not convinced about this approach.
I understand that we need to commit so we can get the result from the PRQA
tool. However, we should have talked with people knowing MISRA to
understand
On Thu, 10 Jan 2019, 15:36 Stefano Stabellini,
wrote:
> On Thu, 10 Jan 2019, Julien Grall wrote:
> > On Thu, 10 Jan 2019, 12:29 Stefano Stabellini,
> wrote:
> > On Thu, 10 Jan 2019, Jan Beulich wrote:
> > > >>> On 10.01.19 at 03:40, wrote:
>
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand, <
stewart.hildebr...@dornerworks.com> wrote:
>
> Why don't we change the type of _start so it's not a pointer type?
Can you suggest a type that would be suitable?
Cheers,
___
Xen-devel mailing list
Xen-de
r "VM EVENT, MEM ACCESS and MONITOR". So I
don't think you need an ack from Stefano or I.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
I ask where does this come from? A compiler could technically be free to
assume the inverse. I.e as long as it can't prove two pointers point to
different objects, it can rely on the undefined behavior to optimize it.
Cheers,
--
Julien Grall
_
perty terminates with NUL and is included in the len. So I don't think
this change is correct.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ot happen with the
new construct.
I have been told that -fno-strict-aliasing may help us for pointer arithmetic.
But I am still haven't find any evidence yet.
Cheers,
[1]
https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization.html?m=1
--
Julien Grall
___
ved though. Any help would be welcomed here.
Best regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Andrew,
On 14/01/2019 16:59, Andrew Cooper wrote:
On 14/01/2019 16:07, Julien Grall wrote:
On 14/01/2019 15:17, Andrew Cooper wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index ca655ff..22a86ec 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi
this
relevant with our discussion here?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Jan,
On 1/15/19 8:47 AM, Jan Beulich wrote:
On 14.01.19 at 18:16, wrote:
Hi Andrew,
On 14/01/2019 16:59, Andrew Cooper wrote:
On 14/01/2019 16:07, Julien Grall wrote:
On 14/01/2019 15:17, Andrew Cooper wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index
Hi Andrew,
On 1/14/19 5:43 PM, Andrew Cooper wrote:
On 14/01/2019 17:16, Julien Grall wrote:
Hi Andrew,
On 14/01/2019 16:59, Andrew Cooper wrote:
On 14/01/2019 16:07, Julien Grall wrote:
On 14/01/2019 15:17, Andrew Cooper wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h
b/xen/arch/arm/efi
Hi Stefano,
On 1/11/19 9:37 PM, Stefano Stabellini wrote:
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
Why don't we change the type of _start so it's not a pointer type?
it might even be possible to have
some of them in xen/common/var.S).
From my test [1], I don't think intermediate variables are necessary.
You could directly define the symbol with uintptr_t.
Cheers,
[1] https://lists.xen.org/archives/html/xen-devel/2019-01/msg01109.html
Jan
--
Julien Gr
drew had some concerns about it. Do
you have any update on them?
"the symbol" here leaves room for ambiguity; this
extern uintptr_t _start, _end, start;
can't possibly work (although it'll build fine) from all I can tell.
Doh, yes. sorry for the noise.
Cheers,
--
Julie
Hi,
On 1/15/19 11:46 AM, Julien Grall wrote:
Hi Stefano,
On 1/11/19 9:37 PM, Stefano Stabellini wrote:
On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
Why don't we change the
Hi,
On 1/3/19 10:07 PM, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
Device
Hi Stefano,
On 1/3/19 7:07 PM, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
We don't have a clear way to know how many virtual SPIs we need for the
boot domains. For simplicity, allocate as many as natively supp
Hi,
On 1/3/19 10:07 PM, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
docs/misc/arm/device-tree/booting.txt | 108
++
1 file changed, 108
Hi Stefano,
On 1/3/19 11:31 PM, Stefano Stabellini wrote:
On Thu, 3 Jan 2019, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
docs/misc/arm/device-tree/booting.txt | 108
ee_enabled;
Can you move this after gic_version? So we don't introduce more padding.
};
#endif /* __XEN__ || __XEN_TOOLS__ */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/m
uct domain *d) {}
+
+#endif /* CONFIG_TEE */
+
+#endif /* __ARCH_ARM_TEE_TEE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
a0OPTEE_SMC_RETURN_ENOTAVAIL OP-TEE has no resources for
> + * another VM
> + * a1-7 Preserved
> + *
> + */
> +#define OPTEE_SMC_FUNCID_VM_CREATED 13
> +#define OPTEE_SMC_VM_CREATED \
> + OPTEE_SMC_FAST_CAL
device. They are unable to cope with NULL (aka direct-mapping), hence
the NULL dereference crash.
Do you have any suggestion how this should be fixed?
Best regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
On 16/01/2019 17:22, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
Hi,
On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This flag enables TEE support for a domain.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domain.c | 4
xen
optee_enable didn't happen. So you need to cater that case.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
return handle_exchange_capabilities(regs);
+case OPTEE_SMC_CALL_WITH_ARG:
+return handle_std_call(ctx, regs);
+case OPTEE_SMC_CALL_RETURN_FROM_RPC:
+return handle_rpc(ctx, regs);
default:
return false;
}
diff --git a/xen/inc
.dev_dma_ops', should
> both of them are not NULL pointers then we can run into xen_alloc_xxx
> related function, otherwise it should fallback to use
> dma_direct_alloc() to allocate dma pages?
>
> Also very welcome if you could work on formal fixing and at my side
> I am glad
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hi Volodymyr,
On 17/01/2019 15:21, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means
I haven't seen an answer to my question on the previous version. For reminder:
Would it make sense to still allow the hardware domain to access static SHM?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
SMC_RPC_FUNC_ALLOC:
-/* TODO: Add handling */
+handle_rpc_func_alloc(ctx, regs);
break;
case OPTEE_SMC_RPC_FUNC_FREE:
-/* TODO: Add handling */
+{
+uint64_t cookie = call->rpc_params[0] << 32 |
+(uint32_t)call->rp
701 - 800 of 11146 matches
Mail list logo
