Re: [Xen-devel] [PATCH v3 3/3] xen/arm: Introduce support for Renesas R-Car Gen2 platform

. F.e. R8A7790 what is R-Car H2 we have on our table. Browsing the kernel configs you will find shmobile not rcar as well. From other hand I do not like rcar2 naming for uart. I would prefer the IP block naming - scif. Andrii Anisov | Team Lead GlobalLogic Kyiv, 03038, Protasov Business Park

Re: [Xen-devel] [PATCH v7 0/6] xen/arm: Add support for non-PCI passthrough

Thank you. Andrii Anisov | Team Lead GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v7 0/6] xen/arm: Add support for non-PCI passthrough

Julien, You did miss the libxl_libfdt_compat.h file in this patch series. Andrii Anisov | Team Lead GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http://www.globallogic.com/ http

Re: [Xen-devel] [PATCH v1 1/2] arm: Add ability to relocate Xen in over 4GB space

with iommu (2) or swiotlb(4), it was decided to place the user domain described in 3 within RAM below 4GB with 1:1 mapping. Therefore we needed to move all the rest (XEN, rest of domains) under 4GB. Andrii Anisov | Team Lead GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P

Re: [Xen-devel] [PATCH v1 1/2] arm: Add ability to relocate Xen in over 4GB space

Therefore we needed to move all the rest (XEN, rest of domains) OVER 4GB. Andrii Anisov | Team Lead GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http://www.globallogic.com/ http

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

d deviations (i.e. SMMU absence). Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http://www.globallogic.com/email_di

Re: [Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

x your own environment, too. I'm not sure I got the point. If we are speaking about our system we are tied to this http://processors.wiki.ti.com/index.php/Category:GLSDK in dom0. I doubt it will be accepted by customer switching to any rich shell. Andrii Anisov | Associate Manager, Engineering Global

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

o not support sg-lists (require buffers continuous in maddr). Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http://www.globallogic.com/email_disclaime

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

I would name Renesas RCAR H2 chip - it has its own IPMMU instead of SMMU. It is claimed that IPMMU implemets VMSAv7. But no VMSAv7 VE are supported by that IPMMU in fact. The most outstanding example is a chip with Cortex A15 MPCore, but without any VE support at all. Andrii Anisov | Associate Manager,

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

tch series. But the GPU MMU is still 32-bit and is not able to address SDRAM mapped over 4GB on the bus. Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.9695x3664 M +380505738852 S andriyanisov www.globallogic.com http

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

more careful. You remember I wrote: >> The most outstanding example is a chip with Cortex A15 MPCore, but >> without any VE support at all. It was another Samsung's SoC in my experience. Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Gr

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

8/18] arm: Add ability to allocate Xen heap in lowmem. Patche for GPU MMU shadowing is not published yet, I still have to check if it lacks of proprietary information. Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1 P +38.044.492.969

Re: [Xen-devel] [PATCH RFC 00/18] System adjustment to customer needs.

Julien, > Thank you for your series. For the next version, can you CC the relevant > maintainers using scripts/get_maintainer.pl for each patch? We will take care to follow this rule further. Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Busines

Re: [Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

> My bottom line is the error reporting mechanism needs to be preserved, > otherwise we risk breaking other users. Libxl currently relies on those > nodes to report error. Got it. Andrii Anisov | Associate Manager, Engineering GlobalLogic Kyiv, 03038, Protasov Business Park, M.Grinchen

[Xen-devel] [PATCH RFC 08/18] tools/misc: Set timeout value from watchdog daemon

From: Viktor Kleinik Signed-off-by: Viktor Kleinik --- tools/misc/xenwatchdogd.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c index 4b27628..fcf7d16 100644 ---

[Xen-devel] [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file

From: Oleksandr Tyshchenko In case of missing required property in cfg file the default value (0x4) should be used. Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Iurii Konovalenko

[Xen-devel] [PATCH RFC 02/18] kbdif: add raw events passing

From: Sergiy Kibrik xenkbd_raw carries raw linux event structure -- type, code & value, which allows support of more devices (e.g. touchscreens). Signed-off-by: Sergiy Kibrik --- xen/include/public/io/kbdif.h | 10 ++ 1

[Xen-devel] [PATCH RFC 09/18] tools: Allow to cross-compile xentop

From: Oleksandr Dmytryshyn Signed-off-by: Oleksandr Dmytryshyn Signed-off-by: Iurii Konovalenko --- tools/xenstat/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

[Xen-devel] [PATCH RFC 05/18] xen/arm: allow reassigning of hw interrupts to guest domain

From: Andrii Tseglytskyi Patch allows reassigning of hardware interrupts from dom0 to other guest domain. Signed-off-by: Andrii Tseglytskyi Signed-off-by: Iurii Konovalenko ---

[Xen-devel] [PATCH RFC 07/18] tools/misc: Modify Xen watchdog daemon

From: Viktor Kleinik This change allows watchdog daemon to work thru watchdog device on the file system. Signed-off-by: Viktor Kleinik --- tools/misc/xenwatchdogd.c | 52 +++ 1 file

[Xen-devel] [PATCH RFC 12/18] libxl: Fix unneeded domain reboot during destroy routine

From: Viktor Kleinik During domain destroy we should change its state from "alive" to "dying" to prevent reboot because of watchdog timeout. Signed-off-by: Viktor Kleinik --- tools/libxl/libxl.c | 4 1 file changed, 4

[Xen-devel] [PATCH RFC 18/18] arm: Add ability to allocate Xen heap in lowmem

From: Iurii Konovalenko Add abiliyty to allocate Xen heap in 32-bit address range for ARM32. Due to architecture features some ARM32 platforms require Xen heap to be allocated in lowmem. Signed-off-by: Iurii Konovalenko ---

[Xen-devel] [PATCH RFC 16/18] xen: Add dom0_mem_high option & over 4GB memory allocation for Dom0

From: Iurii Mykhalskyi Add support of custom allocation of over 4GB memory for Dom0. Requested memory size might be specified by passing dom0_mem_high option in Xen cmdline Signed-off-by: Iurii Mykhalskyi --- xen/Rules.mk

[Xen-devel] [PATCH RFC 03/18] xen/arm: allow to allocate 1/128/256/512 Mb memory chunks

From: Andrii Tseglytskyi This is done to allow possibility of having 1 to 1 memory mapping chunks with size 1/128/256/512 Mb what can sagnificantly decrease time of memory allocation and fragmentation for 1-to-1 mapped domains. Signed-off-by: Andrii

[Xen-devel] [PATCH RFC 06/18] libxl: parse config data during domain reboot

From: Viktor Kleinik We need to parse config data during domain reboot to get correct I/O memory regions for mapping. Signed-off-by: Viktor Kleinik --- tools/libxl/xl_cmdimpl.c | 15 +++ 1 file changed, 15

[Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

This patch makes virtual disks helper scripts be functional in busybox environment. Actually we call sh insteand of bash and rewrite loop with counter to be properly parsed by ash. Signed-off-by: Andrii Anisov <andrii.ani...@globallogic.com> Signed-off-by: Andrii Tseglytskyi <andrii

[Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

From: Oleksandr Dmytryshyn This setting is used to adjust starting memory address allocated for kernel Dom0. To use 'rambase_pfn' setting just add for example 'dom0_rambase_pfn=0x8' to the hypervisor command line. Note that 'dom0_rambase_pfn' should be

[Xen-devel] [PATCH RFC 10/18] xen: arm: add batch support to the XENMEM_p2m_lookup operation

From: Oleksandr Dmytryshyn Signed-off-by: Oleksandr Dmytryshyn Signed-off-by: Iurii Konovalenko --- xen/arch/arm/mm.c | 33 +

[Xen-devel] [PATCH RFC 17/18] tools: Introduce ARM32_SEPAR_MEM_SPLIT option

From: Iurii Mykhalskyi This option enables separate memory allocation in low & over 4GB address space. With this option enabled in domain config files "memory" parameter are used to specify domain low memory "memory_high" - to specify over 4GB allocated memory

[Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space

From: Iurii Konovalenko Move Xen to the end of physical memory Signed-off-by: Iurii Konovalenko --- xen/Rules.mk | 1 + xen/arch/arm/arm32/head.S | 21 -

[Xen-devel] [PATCH RFC 14/18] xen: flask: Add possiblity to forward irqs into domU domains

From: Iurii Mykhalskyi Looks like that from 4.6 version, Xen didn't allow irq forwarding into DomU domains - in our setup we forward list of them, so we need to changed the policy. Signed-off-by: Iurii Mykhalskyi ---

[Xen-devel] [PATCH RFC 11/18] arm: Fix 1-to-1 Dom0 memory allocation of any size

From: Iurii Konovalenko For Dom0 with non-power-two memory size less then 128M allocation of first memory bank fails. This patch fix it. Signed-off-by: Iurii Konovalenko --- xen/arch/arm/domain_build.c | 2 +- 1 file

[Xen-devel] [PATCH RFC 00/18] System adjustment to customer needs.

specific patches as well as new PV drivers interfaces. Patches for new PV drivers interfaces will be submitted soon. Andrii Anisov (1): xen/tools: Fix virtual disks helper scripts. Andrii Tseglytskyi (2): xen/arm: allow to allocate 1/128/256/512 Mb memory chunks xen/arm: allow reassigning of hw

Re: [Xen-devel] [PATCH v3 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Yup, Following is wrong: > DEBUG macro could be globally across drivers defined by > CONFIG_DEBUG_DRIVERS. See drivers/base/Makefile. DEBUG is not defined globally. And there is no debug option to enable DEBUG in drivers/xen/Makefile. Should it be added? Sincerely, Andrii

Re: [Xen-devel] [PATCH v3 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

macro, also reasonable pieces of debug code are widely guarded by DEBUG macro. DEBUG macro could be globally across drivers defined by CONFIG_DEBUG_DRIVERS. See drivers/base/Makefile. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@l

Re: [Xen-devel] [PATCH v3 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

makefiles. DEBUG_DRIVER enables DEBUG macro in base, opp and power makefiles. Sincerely, Andrii Anisov. On Tue, Jan 31, 2017 at 9:21 PM, Stefano Stabellini <sstabell...@kernel.org> wrote: > On Tue, 31 Jan 2017, Konrad Rzeszutek Wilk wrote: >> On Tue, Jan 31, 2017 at 11:15:50AM -0800,

Re: [Xen-devel] [PATCH v3 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

Konrad, Stefano, >> What does 'local pages' mean? > > A page that belongs to this domain, rather than a foreign page that has > been mapped. I guess it should be clarified, but not sure in the commit message or comment to the code? Sincerely

[Xen-devel] [PATCH] xen: Kconfig: Add DEBUG_XEN config option

From: Andrii Anisov <andrii_ani...@epam.com> Add a debug option to enable xen drivers debug code. Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- drivers/xen/Kconfig | 8 drivers/xen/Makefile | 2 ++ 2 files changed, 10 insertions(+) diff --git a/drivers/x

Re: [Xen-devel] [PATCH] xen: Kconfig: Add DEBUG_XEN config option

Dear Juergen, > In future you might want to add the maintainers to the recipient list. Yep, I would take care to not miss this point. And +1 to Julien's comment. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org ht

[Xen-devel] [PATCH v3 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini <stefano.stabell...@eu.citrix.com> This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com> Sig

[Xen-devel] [PATCH v3 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Stefano Stabellini <sstabell...@kernel.org> --- arch/arm/xen/mm.c | 1 + drivers/xen/swiotlb-xen.c | 22 ++ include/xen/swiotlb-xe

[Xen-devel] [PATCH v3 0/2] XEN SWIOTLB dma operations extension

From: Andrii Anisov <andrii_ani...@epam.com> Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is

[Xen-devel] [PATCH v4 0/2] XEN SWIOTLB dma operations extension

From: Andrii Anisov <andrii_ani...@epam.com> Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is

[Xen-devel] [PATCH v4 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini <stefano.stabell...@eu.citrix.com> This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com> Sig

[Xen-devel] [PATCH v4 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Stefano Stabellini <sstabell...@kernel.org> --- arch/arm/xen/mm.c | 1 + drivers/xen/swiotlb-xen.c | 28 include/xen/

Re: [Xen-devel] [PATCH v4 0/2] XEN SWIOTLB dma operations extension

Konrad, Any comments? Sincerely, Andrii Anisov. On Tue, Feb 7, 2017 at 7:58 PM, Andrii Anisov <andrii.ani...@gmail.com> wrote: > From: Andrii Anisov <andrii_ani...@epam.com> > > Some drivers need additional dma ops to be provided by xen swiotlb. Because > common operat

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

ng due to no range priv data for r/w handlers, linked list search slowness and ranges merging capabilities. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

er access emulation described here [1] in terms of shared coproc framework [2]. [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01935.html [2] https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html Sincerely, Andrii Anisov. 2017-02-16 15:25 GMT+02:00 Jan Beuli

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

change into generic code. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Dear Jan, I'm really sorry, but I did not get your point here: > This concern makes me assume there might be quite many of them, > which then makes this a no-go for unprivileged domains. Could you please provide wider explanation. Sincerely, Andrii

Re: [Xen-devel] [RFC 1/6] rangeset_new() refactoring

>> +if ( d != NULL ) > > Shouldn't d == NULL be a hard error now, in which you could pass d->rangesets > directly into rangeset_new() (under lock). It definitely should. Because this is a domain specific code. Sincerely, Andrii Anisov. _

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

> The relevant patch is: > > https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html Thank you for the link. I would try to realize why it is left unmerged. Sincerely, Andrii Anisov. 2017-02-16 16:02 GMT+02:00 Paul Durrant <paul.durr...@citrix.com>: >>

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Paul, > Many moons ago there were patches to use rbtree for rangesets. Perhaps it > would be worth reviving that idea? Do you have a link to look at those patches? Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

even if it has a rangeset itself, because `struct rangeset` is not exposed via header file. So rangeset_destroy() should take care of tree head remove and spinlock locking if needed. I still have concerns why rangeset list keeping should be inside rangeset itself. Sincerely, Andrii Anisov. 2017-0

[Xen-devel] [RFC 1/6] rangeset_new() refactoring

From: Andrii Anisov <andrii_ani...@epam.com> rangeset_new is made domain agnostic. The domain specific code is moved to common/domain.c:domain_rangeset_new(). It is still left a rangesets list functionality: rangeset_new() is returning its list head if requested. This would be recons

[Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

From: Andrii Anisov <andrii_ani...@epam.com> rangeset_destroy is made domain agnostic. The domain specific code is moved to common/domain.c:domain_rangeset_destroy(). It is still left a rangesets list functionality: rangeset_destroy() will remove itself from a list. If a spinlock is pr

[Xen-devel] [RFC 0/6] Rangeset generalisation

From: Andrii Anisov <andrii_ani...@epam.com> Rangesets in XEN seems to be a pretty generic thing slightly poisoned with. domain specific funtionality in initialization and deinitialization code. So make the rangeset code generic with moving domain specific code to common/domain.c Andrii

[Xen-devel] [RFC 4/6] rangeset_domain_destroy() refactoring

From: Andrii Anisov <andrii_ani...@epam.com> rangeset_domain_destroy() is rather rangeset list helper and does nothing really domain specific. So replace it with rangeset_list_destroy() helper. Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- xen/common/domain.c|

[Xen-devel] [RFC 5/6] rangeset_domain_printk() refactoring

From: Andrii Anisov <andrii_ani...@epam.com> rangeset_domain_printk() is split into generic rangeset_list_printk() function and domain specific common/domain.c:domain_rangeset_printk(). Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- xen/common/domain.c| 14 +++

[Xen-devel] [RFC 6/6] Drop domain remains from rangeset

From: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- xen/common/rangeset.c | 3 +-- xen/include/xen/rangeset.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c i

[Xen-devel] [RFC 3/6] Drop rangeset_domain_initialise()

From: Andrii Anisov <andrii_ani...@epam.com> The rangeset_domain_initialise() does nothing rangeset specific. Even keeping it specific to domain looks not reasonable. So drop it. Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- xen/common/domain.c| 3 ++- xen/commo

Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

l list of rangesets. This is protected by spinlocks now. IMO this functionality is odd to the rangeset itself. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

it would be better to avoid ifdefs in drivers/xen/swiotlb-xen.c, but I haven't find out how to do that. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

table callback? ANDRII ANISOV Lead Systems Engineer Office: +380 44 390 5457<tel:+380%2044%20390%205457> x 66766 Cell: +380 50 573 8852<tel:+380%2050%20573%208852> Email: andrii_ani...@epam.com<mailto:andrii_ani...@epam.com> Kyiv, Ukraine (GMT+3) epam.com<http://www.

[Xen-devel] [PATCH v2 0/2] XEN SWIOTLB for ARM dma operations extension

From: Andrii Anisov <andrii_ani...@epam.com> Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is

[Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- arch/arm/xen/mm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index ff812a2..dc83a35 100644 --- a/arch/arm/xen/mm.c +++ b/

[Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini <stefano.stabell...@eu.citrix.com> This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com> Sig

[Xen-devel] [PATCH v2 0/2] XEN SWIOTLB for ARM dma operations extension

From: Andrii Anisov <andrii_ani...@epam.com> Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is

[Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov <andrii_ani...@epam.com> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com> --- arch/arm/xen/mm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index ff812a2..dc83a35 100644 --- a/arch/arm/xen/mm.c +++ b/

[Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini <stefano.stabell...@eu.citrix.com> This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytrys...@globallogic.com> Sig

Re: [Xen-devel] Error in Xen while booting for salvator-X (M3 Board)

on r8a7796 but described in a device tree for r8a7795. -- *Andrii Anisov* *Lead Systems Engineer* *Office: *+380 44 390 5457 <tel:+380%2044%20390%205457> *x* 66766 *Cell: *+380 50 5738852 <tel:+380%2050%205738852>*Email: *andrii_ani...@epam.com <mailto:andrii_ani...@ep

[Xen-devel] [RFC] Shared coprocessor framework

switching. Such context switch function support would be introduced into the firmware and the driver of the coprocessor. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

was pushed there, but still consists of useful things. I'm really happy they decided to upstream it. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM community call

Hello Julien, We will be happy to work on this. We are in GMT+2 timezone (EET). Adding Artem Mygaiev and Oleksandr Tyshchenko who work on co-processor sharing with me in EPAM. Sincerely, Andrii Anisov. On Tue, Nov 8, 2016 at 2:19 PM, Julien Grall <julien.gr...@arm.com> wrote: > Hi a

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

no IOMMU supported (or owned) by XEN with 32-bit DMA controllers and RAM over 4GB will suffer from this problem. From living products: new J6 EVM with 4GB RAM, Salvator-X. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

e, > > this should be fixed in the DOM0 OS. > Do you consider driver domain guests? Sincerely, Andrii Anisov. On Fri, Nov 11, 2016 at 4:24 PM, Andrii Anisov <andrii.ani...@gmail.com> wrote: > > Hello Julien, > > Please see my comments below: > > > From my understa

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

der driver domain guests? Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

river solutions is avoiding data copying inside FE-BE pair in order to increase performance, reduce latency and system load. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

> Without an SMMU, driver domains are not about security anymore, they are > about disaggregation and componentization That is our case. And the thing we can provide to customers on chips without SMMU. Sincerely, Andrii Anisov. ___ Xen-devel m

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

a special guest domain. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

> You could also exhaust the memory of the backend domain. > The problem with this is not much the code changes but the risk of > exhausting Dom0 memory. I think the approach you proposed previously, > explicitly giving memory below 4G to DomUs, is better. I see the point. Since

[Xen-devel] XEN tools for ARM64 build issue

20120215. I upgraded iasl to 20160527, but nothing noticeably to me changed, see [log.do_compile.18488.tbz2]. Unfortunately I'm not really familiar with the ACPI stuff so have no ideas about the issue. Any suggestions? Sincerely, Andrii Anisov. log.do_compile.14752.tbz2 Description: application/bzip

Re: [Xen-devel] XEN tools for ARM64 build issue

> Looking at the source I see that this statement gets included for > x86 only. Are you perhaps doing a cross build of the ARM tools > on an x86 host? Indeed. I do. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

ing wrong with the compilation. But I have a strong feeling that this option should be optional. [1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01903.html Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://list

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

l/2016-11/msg01921.html Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] Shared coprocessor framework

ample, if you have one. I'm not really sure about a simple functional example. We are targeting GPU sharing for the first drop. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

s from it to Kconfig. I guess extending that file is not acceptable, so I hope to be back soon with modifications suggested by Julien: >The way forward is to have an option in the configure to opt-out the support >of guest ACPI and also remove the iasl check. Sincerely, A

[Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

Make the libxl ACPI support build configurable by the same config option as the hypervisor side support. Signed-off-by: Andrii Anisov <andrii.ani...@gmail.com> --- tools/libxl/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/Makefile b/tools/libxl/Ma

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

> This will not work because Kconfig support only exists for the hypervisor. So I totally confused where CONFIG_ARM_64 is defined for tools. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

Dear Iurii, Following: > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch - required by to fix > build issue, described here [2]. I haven't found any better solution except > this one. Is not needed. The issue does not appear with the current master HEAD. Sincerely, Andrii Anisov.

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

tionality easily. BTW, excessive functionality reduction is also a way to get more stable and predictable system. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] Shared coprocessor framework

Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

memory banks are duplicated and crashes. Putting all memory banks into one memory node in the device tree is the simplest workaround. I'm not really sure where should be a proper fix. Should it be on u-boot or XEN side? Sincerely, Andrii Anisov. ___ Xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

iginal patch. Sincerely, Andrii Anisov. On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov <andrii.ani...@gmail.com> wrote: > Dear Iurii, > > This patch https://github.com/qbeeukraine/meta-platform-xen/ > blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u- > boot/0002-arm-

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

r with the current master HEAD. With clean build I still face the issue described here: https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html. Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: Fix compilation when cross building the tools

> I diffed the generated dsdt and it is the same before and after the > patches when built natively. I did try cross-build, Andrii could you > give a try? Build passed smoothly. Non-ACPI guests started well. Sincerely, Andr

Re: [Xen-devel] [RFC] Shared coprocessor framework

> I was thinking of something trivial but enough to prove the point. It is already implemented in a hack'n'slash way. So we are pretty confident in the approach and looking forward to make generic and scalable implementation. And upstreamable, of course. Sincerely, Andrii Ani

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

area of responsibility. > This is because the Kconfig is not embedded in the Xen binary. This thread was started from the configuration of the tools, which are not configured by Kconfig. Is it already possible to get back tools configuration during runtime? Sincerely, Andrii Anisov. ___

Re: [Xen-devel] [RFC] Shared coprocessor framework

ll, we also need to take care about following: AA> Due to the fact that some domain assigned a vcoproc could access coproc when AA> it is running another domain context, framework will implement iomem access AA> emulation for domains which are not provided coproc at the moment of

Re: [Xen-devel] [RFC] Shared coprocessor framework

t destabilize the system > incase the firmware on the "coprocessors" ends up blowing up? > > Are there some other operations to allow the coprocessors > only to touch specific memory regions? IOMMU should take care of that. IOMMU setup planned to be a part of "context&

  1   2   3   >