flight 131384 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131384/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail in 131324 pass
in 131384
test-armhf-armhf-xl
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handler_array' 32 <= 32
Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests")
Signed-off-by: YueHaibing
---
arch/x86/xen/enlighten_pv.c | 2 +-
1 file changed, 1 insertion
On 18/12/2018 09:19, YueHaibing wrote:
> Fix smatch warning:
>
> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
> buffer overflow 'early_idt_handler_array' 32 <= 32
>
> Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guests")
> Signed-off-by: YueHaibing
> ---
> arch/x
On 12/17/18 5:26 PM, Boris Ostrovsky wrote:
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it
On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used globally for each blkback queue and
> therefore should be read from xenstore only once. However, it is obtained
> in read_per_ring_refs() which might be called multiple times during the
> initiali
On Tue, Dec 18, 2018 at 10:33:00AM +0100, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
> > + for (i = 0; i < nr_grefs; i++) {
> > + char ring_ref_name[RINGREF_NAME_LEN];
> > +
> > + snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u
On 18/12/2018 02:17, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Monday, December 17, 2018 10:21 PM
>>
>> On 17/12/2018 13:09, Andrew Cooper wrote:
>>> On 17/12/2018 02:39, Tian, Kevin wrote:
>>> After some investigation, it turns out that after vmentry
On 2018/12/18 16:31, Juergen Gross wrote:
> On 18/12/2018 09:19, YueHaibing wrote:
>> Fix smatch warning:
>>
>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
>> buffer overflow 'early_idt_handler_array' 32 <= 32
>>
>> Fixes: 42b3a4cb5609 ("x86/xen: Support early interrupts in xen pv guest
George Dunlap writes ("Re: [PATCH v2 08/10] libxl: Kill QEMU by uid when
possible"):
> On 12/12/18 4:17 PM, Ian Jackson wrote:
> > I am tempted to suggest replacing each call
> > PROPAGATE_RC;
> > with
> > ACCUMULATE_RC(ddms);
> > and put the definition in libxl_internal.h for use elsewhere.
>
On 18/12/2018 10:42, YueHaibing wrote:
> On 2018/12/18 16:31, Juergen Gross wrote:
>> On 18/12/2018 09:19, YueHaibing wrote:
>>> Fix smatch warning:
>>>
>>> arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
>>> buffer overflow 'early_idt_handler_array' 32 <= 32
>>>
>>> Fixes: 42b3a4cb5609 ("x
While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
as its title says, it broke the 3-operand form by uniformly using AL/AX/
EAX/RAX as second source operand. Fix this and add tests covering both
cases.
Reported-by: Andrei Lutas
Signed-off-by: Jan Beulich
--- a/tools/tests/x
Hi Roger,
On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. However, it is obtained
>> in read_per_ring_re
>>> On 18.12.18 at 10:56, wrote:
> On 18/12/2018 02:17, Tian, Kevin wrote:
>>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>>> Sent: Monday, December 17, 2018 10:21 PM
>>>
>>> On 17/12/2018 13:09, Andrew Cooper wrote:
On 17/12/2018 02:39, Tian, Kevin wrote:
After some inve
On 18/12/2018 11:37, Jan Beulich wrote:
On 18.12.18 at 10:56, wrote:
>> On 18/12/2018 02:17, Tian, Kevin wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Monday, December 17, 2018 10:21 PM
On 17/12/2018 13:09, Andrew Cooper wrote:
> On 17/12/2018 02:
flight 131385 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 17 guest-start.2fail REGR. vs. 131318
Tests which did not
On 12/18/18 1:29 PM, Jan Beulich wrote:
> While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
> as its title says, it broke the 3-operand form by uniformly using AL/AX/
> EAX/RAX as second source operand. Fix this and add tests covering both
> cases.
>
> Reported-by: Andrei Lut
On 18/12/2018 11:29, Jan Beulich wrote:
> While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
> as its title says, it broke the 3-operand form by uniformly using AL/AX/
> EAX/RAX as second source operand. Fix this and add tests covering both
> cases.
>
> Reported-by: Andrei Luta
Hello Julien,
On 17.12.18 19:34, Andrii Anisov wrote:
I see something like following as a quick WA (not even build tested):
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d2c63a8..bf72ba9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
On 12/18/18 12:09 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 17.12.18 19:34, Andrii Anisov wrote:
I see something like following as a quick WA (not even build tested):
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d2c63a8..bf72ba9 100644
--- a/xen/arch/ar
On 11/12/2018 08:50, Jan Beulich wrote:
> There are a number of exception condition related errata on SandyBridge
> CPUs, some of which are unexpected #UD (others, of no interest here, are
> lack of mandated exceptions, or exceptions of unexpected type). Annotate
> the one workaround we already hav
On 11/12/2018 08:48, Jan Beulich wrote:
> The check needs to happen whenever EVEX.b (SDM nomenclature) is clear,
> not just in the memory operand case.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Clarify naming (to address apparent disconnect between description
> and code change).
Thanks - th
On 11/12/2018 08:47, Jan Beulich wrote:
> In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
> first thing") I neglected the fact that the retire flags get zapped only
> in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
> check added. Move output state
>>> On 14.12.18 at 18:17, wrote:
> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
> only possible to disable this functionality when we disable altp2m
> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>
> In addition to making things complete, disabling #VE is
On 12/18/18 4:10 PM, Jan Beulich wrote:
On 14.12.18 at 18:17, wrote:
>> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
>> only possible to disable this functionality when we disable altp2m
>> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>>
>> In additio
On 10/12/2018 13:56, Jan Beulich wrote:
On 10.12.18 at 14:20, wrote:
>> On 10/12/2018 11:32, Jan Beulich wrote:
>>> The avx512_vlen_check() invocation needs to be conditional.
>>>
>>> Signed-off-by: Jan Beulich
>> I'm not sure if I've asked before, but do LIG instructions really #UD
>> for L
When I destroyed a guest with 'xl destroy', I found the warning
in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
to that place, I got the call trace below:
(XEN) Xen call trace:
(XEN)[] msi.c#msi_set_mask_bit+0x1da/0x29b
(XEN)[] guest_mask_msi_irq+0x1c/0x1e
(XEN)[]
I find some pass-thru devices don't work any more across guest
reboot. Assigning it to another domain also meets the same issue. And
the only way to make it work again is un-binding and binding it to
pciback. Someone reported this issue one year ago [1].
If the device's driver doesn't disable MSI-
Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
only possible to disable this functionality when we disable altp2m
completely; #VE/VMFUNC can only be enabled once per altp2m session.
In addition to making things complete, disabling #VE is also a
workaround for CFW116 ("When Virtual
On 12/18/18 4:54 PM, Razvan Cojocaru wrote:
> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
> only possible to disable this functionality when we disable altp2m
> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>
> In addition to making things complete, disabl
On 18.12.18 15:07, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely
At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.
Modify the BUG_ON() condition accordingly.
Cc: sta...@vger.kerne
George Dunlap writes ("Re: [PATCH v2 05/10] libxl: Do root checks once in
libxl__domain_get_device_model_uid"):
> On Dec 12, 2018, at 3:45 PM, Ian Jackson wrote:
> >> +/*
> >> + * If dm_restrict isn't set, and we don't have a specified user, don't
> >> + * bother setting a `-runas` pa
Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
only possible to disable this functionality when we disable altp2m
completely; #VE/VMFUNC can only be enabled once per altp2m session.
In addition to making things complete, disabling #VE is also a
workaround for CFW116 ("When Virtual
On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
> Hi Roger,
>
> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> > On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
> >> The xenstore 'ring-page-order' is used globally for each blkback queue and
> >> therefore should be re
>>> On 18.12.18 at 15:28, wrote:
> On 10/12/2018 13:56, Jan Beulich wrote:
> On 10.12.18 at 14:20, wrote:
>>> On 10/12/2018 11:32, Jan Beulich wrote:
The avx512_vlen_check() invocation needs to be conditional.
Signed-off-by: Jan Beulich
>>> I'm not sure if I've asked before, b
Hi Martin,
Friendly ping:
Only 8 out the 41 patches in this series have been applied so far.
I wonder if you could apply the rest of this series, except:
[PATCH 02/41] scsi: NCR5380: Mark expected switch fall-through
(I'll send a v2 of this patch)
Thanks
--
Gustavo
On 11/27/18 10:18 PM, Gu
Andrew Cooper writes ("[Xen-devel] [PATCH v2 6/5] tools/docs: Remove PVRDTSCP
remnants"):
> PVRDTSCP is believed-unused, and its implementation has adverse consequences
> on unrelated functionality in the hypervisor. As a result, support has been
> removed.
Acked-by: Ian Jackson
__
On 12/18/2018 11:13 PM, Roger Pau Monné wrote:
> On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
>> Hi Roger,
>>
>> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 18, 2018 at 08:55:38AM +0800, Dongli Zhang wrote:
The xenstore 'ring-page-order' is used globally f
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c
b/xen/arch/arm/platforms/xilinx-zynqmp.c
index d8ceded..8bc7a9f 100644
--- a/xen/arch/arm/platforms/xilinx-zynqmp.c
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -18,6 +18,8 @@
*
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under
>>> On 18.12.18 at 15:43, wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback. Someone reported this issue one year ago [1].
>
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
+/* These calls are safe and always allowed. */
+case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
+case EEMI_FID(ZYNQMP_SIP_SVC_UID):
+case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
I am a bit surprised that you implement those one
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-
Hi Stefano,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream
And rename to have only one prefix underscore where applicable.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/mm/mm-locks.h | 96 --
1 file changed, 51 insertions(
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/mm/mm-locks.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/
paging_log_dirty_op function takes mm locks from a subject domain and
then attempts to perform copy to operations against the caller
domain in order to copy the result of the hypercall into the caller
provided buffer.
This works fine when the caller is a non-paging domain, but triggers a
lock orde
Hello,
The following series attempts to fix a mm lock level issue that prevents
using paging_log_dirty_op from paging callers (like a PVH Dom0). The
discussion that lead to this series can be found at:
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg01197.html
Thanks, Roger.
Rog
The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
is derived from XenDevice which in turn is derived from DeviceState
since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
Thus the code can also
Hi,
On 12/17/18 10:10 PM, Stefano Stabellini wrote:
+/* These calls are safe and always allowed. */
+case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
+case EEMI_FID(ZYNQMP_SIP_SVC_UID):
+case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
+case EEMI_FID(PM_GET_TRUSTZONE_VERSION):
+case EEMI
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by:
flight 131386 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 131317
test-
flight 131428 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131428/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 131414 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131414/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On 12/18/18 6:28 AM, Andrew Cooper wrote:
> On 18/12/2018 10:42, YueHaibing wrote:
>> On 2018/12/18 16:31, Juergen Gross wrote:
>>> On 18/12/2018 09:19, YueHaibing wrote:
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handl
Hi Stefano,
On 12/14/18 9:27 PM, Stefano Stabellini wrote:
On Fri, 14 Dec 2018, Julien Grall wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 17e2523fc1..5639e4b64c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1524,13 +1524,17 @@ int relinquish_p2m_mapping(struc
Hi Andrew,
On 12/14/18 9:31 PM, Andrew Cooper wrote:
On 14/12/2018 03:58, Julien Grall wrote:
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may
Hi all,
This is version 3 of the series to implement set/way. For more details see
patch #3.
Cheers,
Julien Grall (4):
xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by
HCR_EL2.TVM
xen/arm: vsysreg: Add wrapper to handle sysreg access trapped by
HCR_EL2.TVM
xen/arm:
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may migrate to
another pCPU in the middle of the processor. This will result to have
cache with stale
A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
to the virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to host
registers. For
A follow-up patch will require to emulate some accesses to system
registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to the host
registers.
Note that
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Linux 32-bit will use Set/Way operations during secondary
CPU bring-up. As the imple
flight 131392 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131392/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131364
test-armhf-armhf-libvirt 14 saveresto
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
>
> Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Remove flushing of shared buffer on page
Thomas Huth writes:
> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> is derived from XenDevice which in turn is derived from DeviceState
> since commit 3a6c9172ac5951e ("xen: create qdev for each backend de
On 12/18/18 20:31, Boris Ostrovsky wrote:
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushi
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts.
flight 131431 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131431/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and m
From: Volodymyr Babchuk
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator need to do address translation in the same
way as it was done for shared buffers registered by NW.
As mediator now ac
From: Volodymyr Babchuk
Hello all,
Sorry for late submussion. I was busy with other projects.
Global changes from v2:
- Use domain flags insted of domctl interface to enable optee for guests
- Remove patch "libxc: add xc_dom_tee_enable(...) function" because
of previous change
- Mediator
From: Volodymyr Babchuk
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr Babchuk
---
tools/libxl/l
From: Volodymyr Babchuk
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will set appropriate flag in architecture
configuration to ask hypervisor to enable TEE support.
Signed-off-by: Volodymyr Babchuk
---
Changes from v2:
- Use arch.tee_enabled
From: Volodymyr Babchuk
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC
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 that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contrast with fast calls, where arguments and return values
are
From: Volodymyr Babchuk
This flag enables TEE support for a domain.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domain.c | 4
xen/arch/arm/domctl.c | 1 +
xen/include/public/arch-arm.h | 3 +++
3 files changed, 8 insertions(+)
diff --git a/xen/arch/arm/domain.c b/xe
From: Volodymyr Babchuk
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP-TEE memory with a domain.
Only domain c
From: Volodymyr Babchuk
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and forward all known
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE
From: Volodymyr Babchuk
Shared memory is widely used by NW to communicate with
TAs in OP-TEE. NW can share part of own memory with
TA or OP-TEE core, by registering it OP-TEE, or by providing
a temporal reference. Anyways, information about such memory
buffers are sent to OP-TEE as a list of page
On Tue, Dec 18, 2018 at 12:35:34PM -0500, Boris Ostrovsky wrote:
> On 12/18/18 6:28 AM, Andrew Cooper wrote:
> > On 18/12/2018 10:42, YueHaibing wrote:
> >> On 2018/12/18 16:31, Juergen Gross wrote:
> >>> On 18/12/2018 09:19, YueHaibing wrote:
> Fix smatch warning:
>
> arch/x86/xen/e
On Tue, 18 Dec 2018, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the pro
I committed the series
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi all,
>
> This is version 3 of the series to implement set/way. For more details see
> patch #3.
>
> Cheers,
>
> Julien Grall (4):
> xen/arm: vcpreg: Add wrappers to handle co-proc access trapped by
> HCR_EL2.TVM
> xen/
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > Introduce zynqmp specific defines for the firmware calls.
> > See EEMI:
> > https://www.xilinx.com/support/documentat
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > +/* These calls are safe and always allowed. */
> > +case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_UID):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_V
On Tue, 18 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > +/* These calls are safe and always allowed. */
> > +case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_UID):
> > +case EEMI_FID(ZYNQMP_SIP_SVC_VERSION):
Hello,
I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
and on a 32bits PV domU shutdown I get (100% reproductible):
(XEN) Assertion 'preemptible' failed at mm.c:2493
(XEN) [ Xen-4.11.1nb0 x86_64 debug=y Tainted: C ]
On Tue, 18 Dec 2018, Julien Grall wrote:
> At the moment, Xen is relocated towards the end of the memory. While
> this has the advantage to free space in low memory, the code is not
> compliant with the break-before-make because it requires to switch
> between two sets of page-table. This is not en
On Tue, 18 Dec 2018, Stefano Stabellini wrote:
> On Tue, 18 Dec 2018, Julien Grall wrote:
> > At the moment, Xen is relocated towards the end of the memory. While
> > this has the advantage to free space in low memory, the code is not
> > compliant with the break-before-make because it requires to
flight 131434 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131434/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 131399 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131399/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131358
test-armhf-armhf-libvirt 14 sav
From: "Edgar E. Iglesias"
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-
From: "Edgar E. Iglesias"
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes i
From: "Edgar E. Iglesias"
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes in v8:
- remove redundant ZYNQMP_SIP_SVC_* cases
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream in ATF:
https://github.com/ARM-software/arm-trusted-firmware/b
From: "Edgar E. Iglesias"
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano S
From: "Edgar E. Iglesias"
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
---
Hi all,
Only minor changes in this patch, mainly:
- code style
- move PM_GET_TRUSTZONE_VERSION to enum
- remove ZYNQMP_SIP_SVC_*
- add acked-by
Cheers,
Stefano
The following changes since commit 82855aba5bf91e50c81526167c11d4aeaf665e66:
tools/libxc: Fix error handling in get_cpuid_domain_i
flight 131387 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131387/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
131276
test-amd64-amd64
1 - 100 of 107 matches
Mail list logo
