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
> ---
>
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
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 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
>>> 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
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
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
>
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
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
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
---
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,
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
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
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
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
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
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
---
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
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
>>> 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,
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,
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 -
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
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
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
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:
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
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
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
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
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,
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
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`
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
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,
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
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
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
>>> 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:
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
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
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
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:
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
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 @@
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
-
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
---
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
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
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
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:
>
>
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
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
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:
> >
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
On Tue, Dec 18, 2018 at 08:53:46AM -0700, Jan Beulich wrote:
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
On 19/12/2018 07:00, David Miller wrote:
> From: Juergen Gross
> Date: Tue, 18 Dec 2018 16:06:19 +0100
>
>> 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
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
On 12/18/18 9:45 PM, Martin K. Petersen wrote:
If you haven't received feedback on a patch you should poke the relevant
driver maintainer.
Got it. Will do so.
Thanks
--
Gustavo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
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
>
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
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
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 ]
Hello Oleksandr,
Please find the attached log file.
Could please provide some pointers on how test DomU display.
On Tue, Dec 18, 2018 at 12:06 PM Oleksandr Andrushchenko
wrote:
Hello, Vikram!
> * We are using 64 bit arm platform.
> * Linux 4.20 Kernel in DomU with PV DRM front-end drivers.
From: Juergen Gross
Date: Tue, 18 Dec 2018 16:06:19 +0100
> 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
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
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
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_*
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:
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
1 - 100 of 107 matches
Mail list logo
