[Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Tamas, On 13 February 2017 at 18:20, Tamas K Lengyel <tamas.k.leng...@gmail.com> wrote: > On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk > <vlad.babc...@gmail.com> wrote: >> Hello, >> >> This e-mail is sort of follow-up to the two threads: [1] (my thr

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

ted >> from the firmware to be performed either by the monitor app, or have >> the monitor app further delegate it somewhere that can perform the >> task. That can be either the firmware itself (if its safe), or an >> isolated VM if it is possible to perform the task there. I wo

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Hello Julien, On 1 March 2017 at 18:09, Julien Grall <julien.gr...@arm.com> wrote: > On 01/03/17 14:13, Volodymyr Babchuk wrote: >>>> This e-mail is sort of follow-up to the two threads: [1] (my thread >>>> about TEE interaction) and [2] (Edgar's thread

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

>> 6. Hypervisor should do this as fast as possible (DRM playback use case). >> 7. All domains (including dom0) should be handled in the same way. > > > +1 here. Same path for all domains means less code and you it will get > tested more Yep. But this is somewhat incompa

[Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

Hello all, My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch of other guys like Artem Mygaiev or Andrii Anisov. My responsibility there is security in embedded systems. I would like to discuss approaches to OP-TEE support in XEN. But first small introduction for those who

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

Hello, On 28 November 2016 at 18:14, Julien Grall <julien.gr...@arm.com> wrote: > On 24/11/16 21:10, Volodymyr Babchuk wrote: >> >> Hello all, > > > Hello, > >> My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch >> of other

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

RMAT_SPECIAL as raw format. I.e. "I know how to prepare data for my device and my device expects audio in that format". You don't need this on generic x86 system, but it can be absolutely crucial on embedded system with hardware accelerated audio/video playback for example. -- WBR Volodymyr B

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

On 16 November 2016 at 15:31, David Vrabel <david.vra...@citrix.com> wrote: > On 16/11/16 13:12, Volodymyr Babchuk wrote: >> Hello David, >> >> I helped Oleksandr with parts of this protocol, so I want to address >> some questions you asked. >> >&g

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

Hi Julien, On 29 November 2016 at 20:55, Julien Grall <julien.gr...@arm.com> wrote: > Hi Volodymyr, > > On 29/11/16 17:40, Volodymyr Babchuk wrote: >> >> On 29 November 2016 at 18:02, Julien Grall <julien.gr...@arm.com> wrote: >>> >>> On 29/11

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

-> PA. We also need to forbid some SMC > call from the guest where it will impact all TEE (e.g such as reset...). True. > In summary, we need a white-list in Xen to avoid the guest using an SMC that > has been added in newer version of TEE but not been supported by the > Hy

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

Hi Julien On 1 December 2016 at 17:19, Julien Grall <julien.gr...@arm.com> wrote: > On 29/11/16 19:19, Volodymyr Babchuk wrote: >> >> Hi Julien, > > > Hi Volodymyr, > > >> >> >> On 29 November 2016 at 20:55, Julien Grall <julien.gr...@arm

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

in common with OP-TEE thread. I like first solution, because if there will be easy and reliable way to run code in XEN's EL1/EL0, then this will be ideal solution for TEE emulation/mediation layer. So, if you'll choose this way, please bear in mind other uses, like TEE emulation. -- WBR

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

Hi Dongli! On 29 November 2016 at 06:47, Dongli Zhang <dongli.zhang0...@gmail.com> wrote: > 2016-11-25 5:10 GMT+08:00 Volodymyr Babchuk <vlad.babc...@gmail.com>: >> Hello all, > > Hi Volodymyr! > >> >> My name is Volodymyr Babchuk, I'm working on EPA

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

On 28 November 2016 at 22:10, Julien Grall <julien.gr...@arm.com> wrote: > > > On 28/11/16 18:09, Volodymyr Babchuk wrote: >> >> Hello, > > > Hello Volodymyr, > >> On 28 November 2016 at 18:14, Julien Grall <julien.gr...@arm.com> wrote:

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

On 29 November 2016 at 18:02, Julien Grall <julien.gr...@arm.com> wrote: > Hello Volodymyr, > > On 29/11/16 15:27, Volodymyr Babchuk wrote: >> >> On 28 November 2016 at 22:10, Julien Grall <julien.gr...@arm.com> wrote: >>> >>> On 28/11/16 18:09

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

. This was tested using the VM event API and Mini-OS > (upstream with Chen Baozi's series to support ARM64). The first results > shows it is 10 times slower than handling SMC calls directly in the > hypervisor. > > Volodymir is working on another approach to deprivilege the execution by

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Stefano, On 30 March 2017 at 21:52, Stefano Stabellini <sstabell...@kernel.org> wrote: > On Thu, 30 Mar 2017, Volodymyr Babchuk wrote: >> Hi Julien, >> >> 5pm UTC+1 will be fine for me. >> >> I just finished my EL0 PoC and want to share benchmark results

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

Hi Julien, On 30 March 2017 at 22:57, Julien Grall <julien.gr...@arm.com> wrote: > Hi Volodymyr > > On 30/03/2017 20:19, Volodymyr Babchuk wrote: >> >> On 30 March 2017 at 21:52, Stefano Stabellini <sstabell...@kernel.org> >> wrote: >>>

[Xen-devel] MiniOS aarch64 support

tches useful. Build instructions are in commit 29d8b9ec. [1] https://github.com/lorc/mini-os -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [ARM] Native application design and discussion (I hope)

. If there are will be no objections against basic concept, then we can develop details. [1] https://github.com/lorc/xen_app_stub - native app [2] https://github.com/lorc/xen/tree/el0_app - my branch with PoC [3] http://marc.info/?l=xen-devel=149088856116797=2 - benchmark results -- WBR Volodymyr Babchuk aka lorc

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Stefano, On 7 April 2017 at 00:31, Stefano Stabellini <sstabell...@kernel.org> wrote: > On Thu, 6 Apr 2017, Volodymyr Babchuk wrote: >> Hello all, >> >> I want to discuss EL0 (native) applications for XEN. This will be relatively >> long e-mail with require

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

ot;donated time slots" way? > > Yes > > >> > > 1) and 2) are particularly important. If we had them, we would not >> > > need >> > > el0 apps. I believe stubdoms would be as fast as el0 apps too. >> > >> &

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Julien, On 21 April 2017 at 19:47, Julien Grall <julien.gr...@arm.com> wrote: > On 21/04/17 17:16, Volodymyr Babchuk wrote: >> >> Hi Julien, > > > Hi Volodymyr, > > >> On 21 April 2017 at 18:57, Julien Grall <julien.gr...@arm.com> wrote: &g

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 18:49, Julien Grall <julien.gr...@arm.com> wrote: > > > On 21/04/17 15:42, Andrii Anisov wrote: >> >> Hello, > > > Hi, > >> On 20.04.17 23:20, Volodymyr Babchuk wrote: >>> >>> Hi Stefano, >>> &

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 18:57, Julien Grall <julien.gr...@arm.com> wrote: > Hello Volodymyr, > > On 20/04/17 21:20, Volodymyr Babchuk wrote: >> >> On 12 April 2017 at 22:17, Stefano Stabellini <sstabell...@kernel.org> >> wrote: >>&g

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 21 April 2017 at 20:38, Julien Grall <julien.gr...@arm.com> wrote: > Hi Volodymyr, > > On 21/04/17 18:04, Volodymyr Babchuk wrote: >> >> On 21 April 2017 at 19:47, Julien Grall <julien.gr...@arm.com> wrote: >>> >>> On 21/04/17 17

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

missed something? On 11 February 2017 at 02:14, Volodymyr Babchuk <vlad.babc...@gmail.com> wrote: > Hello, > > This e-mail is sort of follow-up to the two threads: [1] (my thread > about TEE interaction) and [2] (Edgar's thread regarding handling SMC > calls in platform_hvc). I

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

On 10.08.17 00:22, Julien Grall wrote: On 09/08/2017 22:06, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that originates from aarch32 state) have extra field

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Julien, On 11.08.17 00:09, Julien Grall wrote: On 10/08/2017 21:09, Volodymyr Babchuk wrote: Hi, On 10.08.17 21:18, Julien Grall wrote: Hi, On 10/08/17 18:40, Volodymyr Babchuk wrote: On 10.08.17 19:11, Julien Grall wrote: On 10/08/17 16:33, Volodymyr Babchuk wrote: Hi Julien

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Julien, On 09.08.17 13:10, Julien Grall wrote: Hi Volodymyr, CC "THE REST" maintainers to get an opinion on the public headers. On 08/08/17 21:08, Volodymyr Babchuk wrote: SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states that both HVC and SMC

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

On 10.08.17 19:11, Julien Grall wrote: On 10/08/17 16:33, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 13:10, Julien Grall wrote: Hi Volodymyr, CC "THE REST" maintainers to get an opinion on the public headers. On 08/08/17 21:08, Volodymyr Babchuk wrote: SMCCC (SMC Call

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi, On 10.08.17 21:18, Julien Grall wrote: Hi, On 10/08/17 18:40, Volodymyr Babchuk wrote: On 10.08.17 19:11, Julien Grall wrote: On 10/08/17 16:33, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 13:10, Julien Grall wrote: Hi Volodymyr, CC "THE REST" maintainers to get

[Xen-devel] [PATCH v3 1/3] arm: processor: add new struct hsr_smc32 into hsr union

instruction executing in AArch32 state. But we define this struct for both ARMv7 and ARMv8, because ARMv8 encoding is backwards compatible with ARMv7. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/include/asm-arm/processor.h | 17 + 1 file changed, 17 inse

[Xen-devel] [PATCH v3 2/3] arm: traps: handle unknown exceptions in check_conditional_instr()

that it is unconditional. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Acked-by: Julien Grall <julien.gr...@arm.com> --- xen/arch/arm/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c07999b..eae2212 1006

[Xen-devel] [PATCH v3 3/3] arm: traps: handle SMC32 in check_conditional_instr()

. There is additional flag (CCKNOWNPASS) to be checked before performing standard handling of CCVALID and COND fields. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/arch/arm/traps.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/xen/ar

[Xen-devel] [PATCH v3 0/3] arm: allign check_conditional_instr() with ARMv8

Hello all, This is third version of series. * Dropped patch that renames hsr.iss to hsr.res0 * Updated references to ARMv8 ARM (latest revision is used) * Added better explanation about ARMv7 and ARMv8 compatibility * No code changes. Only comments and commit messages. Volodymyr Babchuk (3

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Jan, On Thu, Aug 17, 2017 at 01:45:54AM -0600, Jan Beulich wrote: > >>> On 16.08.17 at 23:41, <volodymyr_babc...@epam.com> wrote: > > Hello Jan, > > > > On Wed, Aug 09, 2017 at 05:58:19AM -0600, Jan Beulich wrote: > > > >> > >> &g

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hi again, On 7 July 2017 at 09:41, Dario Faggioli <dario.faggi...@citrix.com> wrote: > On Fri, 2017-07-07 at 18:02 +0300, Volodymyr Babchuk wrote: >> Hello Dario, >> > Hi! > >> On 20 June 2017 at 13:11, Dario Faggioli <dario.faggi...@citrix.com> >>

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hello Dario, On 20 June 2017 at 13:11, Dario Faggioli <dario.faggi...@citrix.com> wrote: > On Mon, 2017-06-19 at 11:36 -0700, Volodymyr Babchuk wrote: >> On 19 June 2017 at 10:54, Stefano Stabellini <sstabell...@kernel.org> >> wrote: >> > True. However, Vo

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

nko and Andrii Anisov for briefing be about VCF workflows. On 16 June 2017 at 20:19, Stefano Stabellini <sstabell...@kernel.org> wrote: > On Fri, 16 Jun 2017, Dario Faggioli wrote: >> On Thu, 2017-06-15 at 13:14 -0700, Stefano Stabellini wrote: >> > On Thu, 15 Jun 2017, Volodym

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

Hello Dario, On 30 June 2017 at 00:26, Dario Faggioli <dario.faggi...@citrix.com> wrote: > On Thu, 2017-06-29 at 22:04 +0300, Volodymyr Babchuk wrote: >> Hello all, >> > Hello, > >> 1. OP-TEE use case: DRM playback (secure data path). >> >> User wan

Re: [Xen-devel] [PATCH 1/2] arm: smccc: handle SMCs/HVCs according to SMCCC

Hello Julien, On 27.06.17 14:08, Julien Grall wrote: On 06/22/2017 05:29 PM, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 15.06.17 13:48, Julien Grall wrote: diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 6cf9ee7..2d0b058 100644 --- a/xen/arch/arm/traps.c +++ b

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 25 April 2017 at 14:43, Julien Grall wrote: >> We will also need another type of application: one which is >> periodically called by XEN itself, not actually servicing any domain >> request. This is needed for a >> coprocessor sharing framework

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

7% gicv2_hcr_status - 4.6% per-source-file statistics: spinlock.c - 22% entry.S - 15% arm/domain.c - 11.6% -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

of LRs used by a domain. Excuse me, what is LR in this context? You can take a look at my context switch routines at [2]. [1] http://marc.info/?l=xen-devel=149088856116797=2 [2] https://github.com/lorc/xen/blob/el0_app/xen/arch/arm/domain.c#L257 -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

isor). I just wanted to to consider idea of doing this in TEE. But you are right, XEN can remove pages in any time, so we need to pin them. > your guest and also potential bounce buffer if the guest buffer span across > multiple pages. That should be done on TEE driver side. Actually, I'm currently upstream

[Xen-devel] [PATCH 2/4] arm: processor: add ccknownpass field into hsr_cond union

its condition code check. 1 - The instruction was conditional, and might have failed its condition code check. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/include/asm-arm/processor.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/inclu

[Xen-devel] [PATCH 3/4] arm: traps: handle unknown exceptions in check_conditional_instr()

According to ARM architecture reference manual, exception with unknown reason (HSR.EC == 0) have no valid bits in HSR (apart from HSR.EC), so we can't check if that was caused by conditional instruction. We need assume that it is uncoditional. Signed-off-by: Volodymyr Babchuk <volodymyr_b

[Xen-devel] [PATCH 0/4] arm: allign check_conditional_instr() with ARM64 requirements

Hello all, Julien asked me to take a look at check_conditional_instr() in traps.c, because it incorrectly handled SMC32 on ARMv8 architecture. This patch series brings it into accordance with TRM (at least, I hope so). ___ Xen-devel mailing list

[Xen-devel] [PATCH 1/4] arm: processor: rename iss to res0 in hsr_cond union

Name "iss" in this case was used not exactly correctly, because this is only part of HSR.ISS field. ARM refence manual denotes this part of ISS as RES0 when it describes encoding for conditional exceptions. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen

[Xen-devel] [PATCH 4/4] arm: traps: handle SMC32 in check_conditional_instr()

. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/arch/arm/traps.c | 12 1 file changed, 12 insertions(+) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index eae2212..6a21763 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1717,8 +1

[Xen-devel] [PATCH v3 0/7] Handle SMCs and HVCs in conformance with SMCCC

Hello all, This is third version. Instead of 4 patches, there are 7 now. As part of the series, I make some functions in traps.c available globally, moved SMC conditional check into separate patch, changed how PSCI functiond numbers are defined. Per-patch changes are described in corresponding

[Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

is forwarded to standard SMCCC handler, it can be routed to a domain monitor, if one is installed. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tysh

[Xen-devel] [PATCH 2/7] arm: make processor-specific functions from traps.c globaly visible

From: Volodymyr Babchuk <vlad.babc...@gmail.com> The following list of functions: - advance_pc() - check_conditional_instr() - inject_undef_exception() - inject_iabt_exception() - inject_dabt_exception() - inject_vabt_exception() are now globaly visible. This change is needed bec

[Xen-devel] [PATCH 5/7] arm: traps: handle PSCI calls inside `smccc.c`

t;, while never PSCI 2.0 is defined as "standard secure service". Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com> --- -

[Xen-devel] [PATCH 1/7] arm: traps: psci: use generic register accessors

From: Volodymyr Babchuk <vlad.babc...@gmail.com> There are standard functions set_user_reg() and get_user_reg(). We can use them in PSCI_SET_RESULT()/PSCI_ARG() macroses instead of relying on CONFIG_ARM_64 definition. Signed-off-by: Volodymyr Babchuk <vlad.babc...@gmail.com> ---

[Xen-devel] [PATCH 7/7] arm: vsmc: remove 64 bit mode check in psci handler

from 64 bit caller. This patch removes that extra check. Also, as there are no more natural scope ( if { } ) to hold local variables, paramters to do_psci_*() are taken right from SMC arguments, without storing in intermediate local variables. Signed-off-by: Volodymyr Babchuk <volodymyr_b

[Xen-devel] [PATCH 6/7] arm: psci: use definitions provided by vsmc.h

using generic macroses from vsmc.h. This change also affects vsmc.c and seattle.c, because they both use PSCI function numbers. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- This is new patch, suggested by Julien Grail. --- xen/arch/arm/platforms/seattle.c | 5 +++-

[Xen-devel] [PATCH 3/7] arm: traps: check if SMC was conditional before handling it

On certain ARM arhcitectures SMC instruction can be conditional (ARM DDI 0487A.k page D7-1949) and we need to check if that conditional was meet. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- This patch was separated from the next one --- xen/arch/arm/traps.c | 6 +++

Re: [Xen-devel] [PATCH 4/4] arm: traps: handle SMC32 in check_conditional_instr()

Hi Julien, On 28.07.17 23:37, Julien Grall wrote: Hi, On 07/28/2017 08:43 PM, Volodymyr Babchuk wrote: On ARMv8 architecture SMC instruction in aarch32 state can be conditional. version + paragraph please. Also, ARMv8 supports both AArch32 and AArch64. As I said in my answer on &quo

Re: [Xen-devel] [PATCH 1/7] arm: traps: psci: use generic register accessors

Hi Andrew On 08.08.17 23:37, Andrew Cooper wrote: On 08/08/2017 21:08, Volodymyr Babchuk wrote: diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 6cf9ee7..ed78b36 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1449,13 +1449,12 @@ static void do_debug_trap(struct

Re: [Xen-devel] [PATCH 2/7] arm: make processor-specific functions from traps.c globaly visible

Hi Julien, On 09.08.17 12:53, Julien Grall wrote: Hi Volodymyr, On 08/08/17 21:08, Volodymyr Babchuk wrote: From: Volodymyr Babchuk <vlad.babc...@gmail.com> The following list of functions: - advance_pc() - check_conditional_instr() - inject_undef_exception() - inject_iabt_exc

[Xen-devel] [PATCH v2 3/4] arm: traps: handle unknown exceptions in check_conditional_instr()

that it is unconditional. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- - Added reference to the ARM manuals --- xen/arch/arm/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c07999b..eae2212 100644 --- a/xe

[Xen-devel] [PATCH v2 4/4] arm: traps: handle SMC32 in check_conditional_instr()

standard handling of CCVALID and COND fields. Because we can't distinguish ARMv7 from aarch32 state, we will always check CCKNOWNPASS field. On ARMv7 it will be read as 0 (ARM DDI 0406C.c page B3-1431), so there will be no problem. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.

[Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

ARMv7, aarch32 and aarch64." Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- - Created new stucture for HSR_EC_SMC32 instead of extending fields in hsr.cond. - Added references to ARM manual. - Wrote comment with rationale. --- xen/include/asm-arm/processor.h | 19 ++

[Xen-devel] [PATCH v2 0/4] arm: allign check_conditional_instr() with ARMv8

ys, becase it does right thing. It can be dropped, though. Volodymyr Babchuk (4): arm: processor: rename iss to res0 in hsr_cond union arm: processor: add new struct hsr_smc32 into hsr union arm: traps: handle unknown exceptions in check_conditional_instr() arm: traps: ha

[Xen-devel] [PATCH v2 1/4] arm: processor: rename iss to res0 in hsr_cond union

Name "iss" in this case was used not exactly correctly, because this is only part of HSR.ISS field. ARM refence manual denotes this part of ISS as RES0 when it describes encoding for conditional exceptions (ARM DDI 0487A.k pages D7-1939 - D7-1949). Signed-off-by: Volodymyr Babchuk <v

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

On 09.08.17 14:58, Jan Beulich wrote: On 09.08.17 at 12:10, <julien.gr...@arm.com> wrote: CC "THE REST" maintainers to get an opinion on the public headers. Please be more specific as to what you expect - the only public header affected here is ARM-specific. On 08/08/17

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that originates from aarch32 state) have extra field in HCR.ISS encoding: s/aarch32/AArch32/ s/have/has/ And the register is called HSR and not HCR

[Xen-devel] [PATCH v4 0/3] arm: allign check_conditional_instr() with ARMv8

Hello all, This is 4th version of patch series: * Fixed spelling in comments * Fixed coding style Volodymyr Babchuk (3): arm: processor: add new struct hsr_smc32 into hsr union arm: traps: handle unknown exceptions in check_conditional_instr() arm: traps: handle SMC32

[Xen-devel] [PATCH v4 2/3] arm: traps: handle unknown exceptions in check_conditional_instr()

that it is unconditional. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Acked-by: Julien Grall <julien.gr...@arm.com> --- xen/arch/arm/traps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c07999b..eae2212 1006

[Xen-devel] [PATCH v4 1/3] arm: processor: add new struct hsr_smc32 into hsr union

instruction executing in AArch32 state. But we define this struct for both ARMv7 and ARMv8, because ARMv8 encoding is backwards compatible with ARMv7. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Acked-by: Julien Grall <julien.gr...@arm.com> --- xen/include/asm-arm/proc

[Xen-devel] [PATCH v4 3/3] arm: traps: handle SMC32 in check_conditional_instr()

. There is additional flag (CCKNOWNPASS) to be checked before performing standard handling of CCVALID and COND fields. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- * Fixed spelling * Fixed coding style in 'if ( )' --- xen/arch/arm/traps.c | 19 ++- 1 file c

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hello Jan, On Wed, Aug 09, 2017 at 05:58:19AM -0600, Jan Beulich wrote: > > > On 08/08/17 21:08, Volodymyr Babchuk wrote: > >> +#ifndef __XEN_PUBLIC_ARCH_ARM_SMC_H__ > >> +#define __XEN_PUBLIC_ARCH_ARM_SMC_H__ > >> + > >> +typedef struct { >

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

Hi Jan, On 22.08.17 10:26, Jan Beulich wrote: On 21.08.17 at 22:27, wrote: --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -930,6 +930,15 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t); __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

Hello Jan On 23.08.17 11:10, Jan Beulich wrote: On 22.08.17 at 16:37, wrote: I can't see why you want to map UUID to a certain structure. This is so that the type cannot mistakenly be passed to a function taking unsigned char *, or be assigned to a variable of

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

pport Xen in Buildroot. The use case is >> a small initramfs. >> >> Potential task: Keep Xen updated on buildroot. Anastasios could help on >> that. >> >> Stefano: Xen is compiling fine with Yocto. >> >> ACTION: Stefano to write a wiki

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

There will be no isolation, this is bad. But: - you can load proprietary modules if you want to - they are fast - you can interface with them in a nativest way possible: just call a function Artem, could you please comment from your side? -- WBR Volodymyr Babchuk aka lorc [+380976646013] mai

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

ibution. I thought, that it can be included in some module with different (but still open source) license. But if you say that it can't... Then I don't know. It is out of my competence. I'm not lawyer also. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

ood to know that it is possible. > Lastly, can you remind me with platform you are using for testing? It is Renesas Rcar Gen3. It is Big-Little platform, but currently we use only four A57 cores. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

plain EXPORT_SYMBOL()? I though it was intended to separate GPL and non-GPL code. BTW, "non-GPL code" does not mean "closed-source code". It can be LGPL, MIT, BSD, or Copyleft license. I can imagine proprietary license which is compatible with BSD, but is incompatible with GPLv2. A

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

possible: just call a >> function > > Proprietary modules are a legal minefield. They are best avoided even in > Linux. Fortunately, both EL0 apps and stubdoms could be proprietary. > Thus, especially if you have a requirement for running proprietary > code, it is key to do EL0 app

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

xt switch is heavy on ARM. > > In the case of ARM, when entering to the hypervisor, we only save the bare > minimum (all non-banked registers + registers useful for handling guest > request), and left the rest untouched. > > Our save/restore functions are quite big because it involv

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

sharing GPU, limit will be 6 ms. And, actually, one slice per domain is not enough, because domain may be willing to render own portion later. So, 1 ms will be more realistic requirement. I mean, that stubdom with coproc driver should be scheduled every 1ms not matter of what. With native apps (or some

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

IPA->PA translation in a command buffer, it needs to execute SMCs (but we can limit it there, thanks to SMCCC), probably it will need to inject vIRQ to guest to wake it up. [1] https://github.com/lorc/xen/tree/staging-4.7/xen/arch/arm/optee -- WBR Volodymyr Babchuk ak

Re: [Xen-devel] [PATCH 1/2] arm: smccc: handle SMCs/HVCs according to SMCCC

Hi Julien, On 15.06.17 13:48, Julien Grall wrote: Hi Volodymyr, On 14/06/17 15:10, Volodymyr Babchuk wrote: SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states that both HVC and SMC are valid conduits to call to a different firmware functions. Thus

[Xen-devel] [PATCH v2 2/4] arm: smccc: handle SMCs/HVCs according to SMCCC

is forwarded to standard SMCCC handler, it can be routed to a domain monitor, if one is installed. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tysh

[Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

from 64 bit caller. This patch removes that extra check. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/arch/arm/vsmc.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c index 5f10fd1..1983e0e

[Xen-devel] [PATCH v2 3/4] arm: traps: handle PSCI calls inside `vsmc.c`

t;, while never PSCI 2.0 is defined as "standard secure service". Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshche...@epam.com> --- S

[Xen-devel] [PATCH v2 1/4] arm: traps: psci: use generic register accessors

There are standard functions set_user_reg() and get_user_reg(). Use them instead of PSCI_RESULT_REG()/PSCI_ARG() macros. Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com> --- xen/arch/arm/traps.c | 68 ++-- 1 file changed, 29 inse

[Xen-devel] [PATCH v2 0/4] Handle SMCs and HVCs in conformance with SMCCC

Hello all, This is second version. Instead of 2 patches, there are 4 now. I have divided PSCI patch into two: one changes how PSCI code accesses registers and second one moves PSCI code with new accessors to vsmc.c. Also I had removed redundant 64 bit mode check in PSCI code, as it does not

Re: [Xen-devel] Notes on stubdoms and latency on ARM

very interested in Julien's idea about stubdom without GIC. Probably, I'll try to hack something like that to see how it will affect overall switching latency. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-dev

Re: [Xen-devel] Notes on stubdoms and latency on ARM

iscussion up front is to prevent a > situation where you spend months coding up something which is ultimately > rejected. There are a lot of things that are hard to predict until > there's actually code to review, but at the moment the "jumps to an > interrupt handling routine" a

Re: [Xen-devel] Notes on stubdoms and latency on ARM

need interrupts, am I correct? Ah yes, you are correct. I thought about OP-TEE use case, when there are no interrupts. In case of co-processor virtualization we probably will need interrupts. > The problem would be the same with an EL0 app. In case of EL0 there will be no problem, because EL0 can't ha

Re: [Xen-devel] [PATCH 1/2] arm: smccc: handle SMCs/HVCs according to SMCCC

Hello Julien, Thank you for review. It is my first time, when I'm submitting patch to XEN, so I have some questions. On 15.06.17 13:48, Julien Grall wrote: On 14/06/17 15:10, Volodymyr Babchuk wrote: SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states

Re: [Xen-devel] Notes on stubdoms and latency on ARM

simultaneously on different > sets of physical cpus using cpupools. For example, you can use the null > scheduler on 2 physical cores and credit2 on the remaining cores. Wow. Didn't know that. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On 26 May 2017 at 12:43, Volodymyr Babchuk <vlad.babc...@gmail.com> wrote: > Hi Dario, > Oops, sorry, George. There was two emails in a row: yours one and Dario's one. And I overlooked to whom I'm answering. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc.

Re: [Xen-devel] Notes on stubdoms and latency on ARM

d by mechanism similar to priority inheritance: if scheduler knows that vcpu1 waits for vcpu2 and there are remaining time slice for vcpu1 it should select vcpu2 as next scheduled vcpu. Problem is how to populate such dependencies. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Notes on stubdoms and latency on ARM

en you don't make that hypercall. :-) In any case you certainly can't > use an EL0 app for that, at least the way we've been describing it. That depends on how many right you will give to an EL0 app. I think, it is possible to use it for this purpose. But actually, I'd like to see TEE mediator

  1   2   3   >