from:"Andrii Anisov"

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

2015-01-28 Thread Andrii Anisov

Hello Ian,

When I discussed with Iurii Konovalenko about this naming during
review I mentioned following the Linux kernel way.

Shmobile within kernel is arm specific, not the same as arch/sh. In
the kernel you would find arch/arm/mach-shmobile folder where
Renesas'es R-CarX SoCs support reside. 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, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

On Wed, Jan 28, 2015 at 4:16 PM, Ian Campbell ian.campb...@citrix.com wrote:

 On Wed, 2015-01-28 at 15:48 +0200, Oleksandr Tyshchenko wrote:
  Hi Ian
 
  On Wed, Jan 28, 2015 at 3:26 PM, Ian Campbell ian.campb...@citrix.com 
  wrote:
   On Fri, 2015-01-23 at 17:33 +0200, Oleksandr Tyshchenko wrote:
   From: Iurii Konovalenko iurii.konovale...@globallogic.com
  
   Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
   Reviewed-by: Julien Grall julien.gr...@linaro.org
   ---
xen/arch/arm/platforms/Makefile   |  1 +
xen/arch/arm/platforms/shmobile.c | 71 
   +++
2 files changed, 72 insertions(+)
create mode 100644 xen/arch/arm/platforms/shmobile.c
  
   diff --git a/xen/arch/arm/platforms/Makefile 
   b/xen/arch/arm/platforms/Makefile
   index 8f47c16..29e931a 100644
   --- a/xen/arch/arm/platforms/Makefile
   +++ b/xen/arch/arm/platforms/Makefile
   @@ -4,5 +4,6 @@ obj-$(CONFIG_ARM_32) += exynos5.o
obj-$(CONFIG_ARM_32) += midway.o
obj-$(CONFIG_ARM_32) += omap5.o
obj-$(CONFIG_ARM_32) += sunxi.o
   +obj-$(CONFIG_ARM_32) += shmobile.o
  
   Everything else calls the platform rcar. How does shmobile relate to
   that?
  Unfortunately, the author of this patch in vacation now.
 
  Perhaps Iurii took this name from kernel part 
  (Linux/arch/arm/mach-shmobile/...)
  where the arch specific things for this platform is located,
  especially the SMP and timer support.
 
  I would rename shmobile to rcar2.

 I'd prefer us to be consistent one way or another.

 Is RCAR2 a subset of shmobile or the other way around?

 http://am.renesas.com/applications/automotive/cis/cis_highend/rcar_h2/index.jsp
  doesn't mention shmobile at all.

 Having determined which is the parent/superset my next question would
 be how similar are the various children -- similar enough to be a
 single platform in Xen, or different enough that we will need multiple
 platforms, since that would have an impact on which name I think we
 should pick.

 (To some extent we can fidge this since we can always git mv stuff, but
 we should at least give it our best guess up front)


 Ian.


 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2015-05-12 Thread Andrii Anisov

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 list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2015-05-12 Thread Andrii Anisov

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://www.globallogic.com/email_disclaimer.txt

On Fri, May 8, 2015 at 7:33 PM, Julien Grall julien.gr...@citrix.com
wrote:

 Hello all,

 This a resend of the last part of non-PCI passthrough after a build issue
 spotted by Ian in Check if fdt_{first,next}_subnode are present in
 libfdt.

 Sincerely yours,

 Julien Grall (6):
   tools/libxl: Check if fdt_{first,next}_subnode are present in libfdt
   tools/(lib)xl: Add partial device tree support for ARM
   tools/libxl: arm: Use an higher value for the GIC phandle
   libxl: Add support for Device Tree passthrough
   xl: Add new option dtdev
   docs/misc: arm: Add documentation about Device Tree passthrough

  docs/man/xl.cfg.pod.5 |  18 +
  docs/misc/arm/passthrough.txt |  63 +++
  tools/configure.ac|   6 ++
  tools/libxl/Makefile  |   2 +-
  tools/libxl/libxl.h   |   7 ++
  tools/libxl/libxl_arm.c   | 160
 +-
  tools/libxl/libxl_create.c|  32 
  tools/libxl/libxl_internal.h  |   6 ++
  tools/libxl/libxl_libfdt_compat.c |  94 ++
  tools/libxl/libxl_types.idl   |  11 +++
  tools/libxl/xl_cmdimpl.c  |  23 +-
  11 files changed, 416 insertions(+), 6 deletions(-)
  create mode 100644 docs/misc/arm/passthrough.txt
  create mode 100644 tools/libxl/libxl_libfdt_compat.c

 --
 2.1.4


 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2015-04-08 Thread Andrii Anisov

 OOI, can you give more context why you need to relocate Xen over 4GB?

Julien,

The context here is pretty simple: just a workaround of the real system
limitations:

   1. Renesas R-Car H2 evaluation board lager has 4GB of RAM, 2GB mapped
   under 4GB boundary and 2GB over.
   2. The R-Car2 chip has IOMMU's for almost all active devices except GPU.
   3. Within our system we need one user domain with 2GB of RAM and
   dedicated GPU.
   4. While doing PoC we have no access to the GPU driver(and firmware)
   sources to introduce swiotlb here.

Having no option to handle GPU driver addressing 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 +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Wed, Apr 8, 2015 at 7:05 PM, Julien Grall julien.gr...@citrix.com
wrote:
 Hi Iurii,

 OOI, can you give more context why you need to relocate Xen over 4GB?

 On 08/04/15 13:36, Iurii Konovalenko wrote:
 From: Iurii Konovalenko iurii.konovale...@globallogic.com

 Primary CPU relocate Xen in over 4GB space and wake up seondary CPUs.

 Typoes:

 s/relocate/relocates
 s/seondary/secondary

 Secondary CPUs run on unrelocated copy of Xen until turning on MMU.
 After turning on MMU secondary CPUs run on relocated copy of Xen.

 The non-relocated copy of Xen is not marked as reserved. So Xen may
 allocate the area for his own purpose before the secondary CPU has boot.


 To add ability to relocate Xen in over 4GB space add following to
 compilation command: ARM32_RELOCATE_OVER_4GB=y

 The virtualization extension requires LPAE. Any reason to make this
 optional?

 Signed-off-by: Iurii Konovalenko iurii.konovale...@globallogic.com
 Signed-off-by: Andrii Anisov andrii.ani...@globallogic.com
 ---
  xen/Rules.mk   |  1 +
  xen/arch/arm/arm32/head.S  | 21 -
  xen/arch/arm/platforms/rcar2.c |  9 -
  xen/arch/arm/setup.c   | 17 -
  xen/arch/arm/smpboot.c | 33 +
  5 files changed, 74 insertions(+), 7 deletions(-)

 diff --git a/xen/Rules.mk b/xen/Rules.mk
 index feb08d6..fbd34a5 100644
 --- a/xen/Rules.mk
 +++ b/xen/Rules.mk
 @@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI)   += -DHAS_PCI
  CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
  CFLAGS-$(HAS_PDX)   += -DHAS_PDX
  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer
-DCONFIG_FRAME_POINTER
 +CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB

  ifneq ($(max_phys_cpus),)
  CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
 diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
 index 5c0263e..26be1d0 100644
 --- a/xen/arch/arm/arm32/head.S
 +++ b/xen/arch/arm/arm32/head.S
 @@ -262,8 +262,21 @@ cpu_init_done:
  add   r4, r4, r10/* r4 := paddr (boot_pagetable) */
  mov   r5, #0 /* r4:r5 is paddr (boot_pagetable)
*/
  mcrr  CP64(r4, r5, HTTBR)

 Newline here.

 +#ifdef ARM32_RELOCATE_OVER_4GB
 +teq   r7, #0
 +beq   1f /* construct pagetable if CPU0 */

 -/* Setup boot_pgtable: */
 +/*Skip constructing TLBs for secondary CPUs, use constructed by
CPU0*/

 /* ... */

 TLBs is confusing. I first though you were talking to Translation
 Lookaside Buffer.

 +PRINT(- Skip construction pagetable, using CPU0 table @)

 This very fragile. The CPU0 may drop a part of the 1:1 mapping if it's
 clashes with the fixmap and DTB mappings (see after the label paging).

 Therefore secondary CPUs may hang during boot.

 +mov   r0, r5
 +blputn
 +mov   r0, r4
 +blputn
 +PRINT(  -\r\n)
 +b   skip_constructing
 +#endif
 +
 +1:  /* Setup boot_pgtable: */
  ldr   r1, =boot_second
  add   r1, r1, r10/* r1 := paddr (boot_second) */

 @@ -346,6 +359,7 @@ virtphys_clash:
  PRINT(- Unable to build boot page tables - virt and phys
addresses clash. -\r\n)
  b fail

 +skip_constructing:
  1:
  PRINT(- Turning on paging -\r\n)

 @@ -427,6 +441,11 @@ paging:
   * setup in init_secondary_pagetables. */

  ldr   r4, =init_ttbr /* VA of HTTBR value stashed by
CPU 0 */
 +#ifdef ARM32_RELOCATE_OVER_4GB
 +ldr   r1, =_start
 +sub r4, r1
 +add r4, #BOOT_RELOC_VIRT_START
 +#endif

 This chunk need some comment in order to explain what it's doing.

 AFAIU the resulting value in r4, will be exactly the same as  ldr r4,
 =init_ttbr.

  ldrd  r4, r5, [r4]   /* Actual value */
  dsb
  mcrr  CP64(r4, r5, HTTBR)
 diff --git a/xen/arch/arm/platforms/rcar2.c
b/xen/arch/arm/platforms

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

2015-04-08 Thread Andrii Anisov

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://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-19 Thread Andrii Anisov

Meng,

>> If the board is not supported by Xen, can we say Xen will support the
>> board with the warkaround?

I would not say boards are supported by XEN (except earlyprintk).
Rather architectures are supported in general, and SoC's are supported
in architecture implementation defined 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_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-19 Thread Andrii Anisov

Wei,

Actually it should be the oldest patch in our current series, it was
initial researches, I tried to fit the dom0 system rootfs into
smallest possible initramfs so lean busybox was there.

>> +#trap sigerr ERR
> > -trap sigerr ERR
>
> I know why you want to comment this out but you basically break the
> error handling protocol. See the fatal function at the beginning of this
> file.
And yes we should check this particular line change carefully 'cause
it was not intelligent adjusting to busybox, just getting rid of nasty
issue.

> And you should probably fix 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
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

On Thu, May 19, 2016 at 2:34 PM, Wei Liu <wei.l...@citrix.com> wrote:
>
> On Wed, May 18, 2016 at 07:32:24PM +0300, Andrii Anisov wrote:
> > 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.tseglyts...@globallogic.com>
> > ---
> >  tools/hotplug/Linux/block| 2 +-
> >  tools/hotplug/Linux/locking.sh   | 9 +++--
> >  tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
> >  3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
> > index 8d2ee9d..6a725db 100644
> > --- a/tools/hotplug/Linux/block
> > +++ b/tools/hotplug/Linux/block
> > @@ -1,4 +1,4 @@
> > -#!/bin/bash
> > +#!/bin/sh
> >
> >  dir=$(dirname "$0")
> >  . "$dir/block-common.sh"
> > diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
> > index c6a7e96..b8e9515 100644
> > --- a/tools/hotplug/Linux/locking.sh
> > +++ b/tools/hotplug/Linux/locking.sh
> > @@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
> >
> >  _setlockfd()
> >  {
> > +local lock_
> >  local i
> > -for ((i = 0; i < ${#_lockdict}; i++))
> > -do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> > +let i=0
> > +
> > +for lock_ in _lockdict ;
> > +do
> > +[ -z "$lock_" -o "$lock_" = "$1" ] && break
> > +(( i++ ))
> >  done
> >  _lockdict[$i]="$1"
> >  let _lockfd=200+i
> > diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in 
> > b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > index d5d0b69..42e46e3 100644
> > --- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > +++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> > @@ -51,7 +51,7 @@ sigerr() {
> >fatal "$0 failed; error detected."
> >  }
> >
>> +#trap sigerr ERR
> > -trap sigerr ERR
>
> I know why you want to comment this out but you basically break the
> error handling protocol. See the fatal function at the beginning of this
> file.
>
> So we can't take this patch. And you should probably fix your own
> environment, too.
>
> Wei.
>
> >
> >
> >  ##
> > --
> > 2.8.2
> >
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-19 Thread Andrii Anisov

All,

See the system details I can reveal below:

   - There are two OS in the system Linux(Dom0) and Android(DomU)
   - Android provides almost all infotainment functionality. Linux covers
   functionality with higher reliability requirements and backup in case if
   Android crashes/glitches.
   - Linux (Dom0) handles all HW except GPU.
   - Android (DomD) runs with number of PV drivers, has an exclusive access
   to GPU.
   - The system has 2Gb(-16MB due to errata) RAM under 4GB, and a memory
   bank mapped over 4GB
   - Due to relatively small amount of dma-able memory both domains should
   have assigned RAM both from under 4GB and over 4GB spaces.
   - Several "data flow" mixing scenarios should be provided on Linux side
   I.e. controlling Android audio level, Android audio mute, mixing Android
   audio stream from stream generated by Linux. Same for Android displaying,
   events passing.
   - Domains should share HW codecs.

>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround?

The main limitation is that Jacinto6 lacks of SMMU. All transaction
initiators can address 32bit only, some initiators have no MMU and do 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_disclaimer.txt


On Thu, May 19, 2016 at 2:00 PM, Julien Grall <julien.gr...@arm.com> wrote:
> Hello,
>
> On 18/05/16 20:17, Meng Xu wrote:
>>
>> On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov
>> <andrii.ani...@globallogic.com> wrote:
>>>
>>> This series RFC patches from the currently ongoing production project.
>>> This patch series presents changes needed to fit the system into
>>> customer requirements as well as workaround limitations of the
>>> Jacinto6 SoC.
>>
>>
>> IMHO, it will be better, if possible, to describe the exact customer
>> requirements this patch series tries to satisfy. I'm curious at what
>> the requirements are and if the requirements are general enough for
>> many other customers. :-)
>
>
> I agree with Meng here. We need to understand the use case and see if it
is
> possible to generalize it for everyone.
>
> I looked quickly at this patch series and noticed that most of patches
miss
> details on why it is necessary and what you are trying solve. Can you give
> us more details?
>
>> Similarly, what are the limitations for the Jacinto6 SoC that need to
>> be workaround? If the board is not supported by Xen, can we say Xen
>> will support the board with the warkaround?
>
>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-19 Thread Andrii Anisov

Julien,

>>We need to understand the use case and see if it is possible to generalize
>>it for everyone.

Well, the thing I would generalize is an understanding that real chips
(automotive IVI, mobile) have no or has limited SMMU functionality.

For a limited SMMU functionality 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, 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_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-20 Thread Andrii Anisov

> If I understand correctly, all the initiators but the GPU will be used by
> DOM0 which is already direct mapped. The only issue here is allocating
> memory enough memory below 4GB.
It's not about memory allocation for domain. It is rather about SDRAM
mapping on the bus. J6 has first 2GB for iomems, starting from
0x8000 2GB of SDRAM mapping plus more SDRAM mapped over 4GB line.
Changing rambase_pfn is painful for J6 release kernel so we just make
it configurable by
- [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file.
- [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn'
setting for kernel Dom0


> By default Xen will try to allocate as much RAM as possible below 4GB for
> DOM0.

Also we are providing both domains with a piece of non-dma memory for
applications with a patch [PATCH RFC 16/18] xen: Add dom0_mem_high
option & over 4GB memory allocation for Dom0.

> If you are concerned about the amount allocated, you could pre-allocate them 
> before
> hand (such as via the DT as propose in [1]).
I've quickly checked the proposal, looks interesting we would evaluate.

> For the GPU, on another reply you said it was protected by an IPMMU. I
> remembered a series from globallogic to virtualize it in Xen [2]. Can you
> details why this option would not fit in your use case?
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg03359.html
We have a successor of that patch 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://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-20 Thread Andrii Anisov

Meng,

> From my previous experience, the board may not be supported by Xen even though
> the processor it uses has virtualization extension.. :-(

I still insist it depends on SoC ;)

If you are saying about this case:

> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
> It uses Cortex A15 processor...
> However, I tried the Arndale Octo board two years ago
> (http://www.arndaleboard.org/wiki/index.php/Main_Page).

Cortex A15 just implements ARMv7 architecture more efficiently then
A9, while VE are still optional. You should read chip specs 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.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 list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-20 Thread Andrii Anisov

> If a malicious user has access to the Android guest (via USB key, wifi,...)
> he would be able to crash the platform using the GPU because there is no
> SMMU protection.
That's why we are shadowing GPU MMU translation tables in xen heap.
And this is leaded us to need of [PATCH RFC 18/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.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-19 Thread Andrii Anisov

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 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 list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-20 Thread Andrii Anisov

> 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.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 list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -61,6 +61,10 @@ int main(int argc, char **argv)
err(1, "strtoul");
 }
 
+ret = ioctl(fd, WDIOC_SETTIMEOUT, );
+if (ret < 0)
+   err(1, "xenwatchdogd: Failed to set timeout\n");
+
 for (;;) {
ret = ioctl(fd, WDIOC_KEEPALIVE);
if (ret)
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 
Signed-off-by: Iurii Mykhalskyi 
---
 tools/libxc/xc_dom_arm.c | 13 +++--
 tools/libxl/libxl_arm.c  | 10 --
 tools/libxl/libxl_create.c   |  5 +
 tools/libxl/libxl_dom.c  |  6 +++---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/xl_cmdimpl.c | 13 +
 7 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 5ee8eef..96df669 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -415,9 +415,12 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 uint64_t modbase;
 
 uint64_t ramsize = (uint64_t)dom->total_pages << XC_PAGE_SHIFT;
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+uint64_t guest_ramsize = (GUEST_RAM0_BASE + GUEST_RAM0_SIZE) -
+  guest_rambase;
 
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-const uint64_t bankmax[] = GUEST_RAM_BANK_SIZES;
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
+const uint64_t bankmax[] = {guest_ramsize, GUEST_RAM1_SIZE};
 
 /* Convenient */
 const uint64_t kernbase = dom->kernel_seg.vstart;
@@ -433,8 +436,6 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 xen_pfn_t p2m_size;
 uint64_t bank0end;
 
-assert(dom->rambase_pfn << XC_PAGE_SHIFT == bankbase[0]);
-
 if ( modsize + kernsize > bankmax[0] )
 {
 DOMPRINTF("%s: Not enough memory for the kernel+dtb+initrd",
@@ -448,11 +449,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
 return -1;
 }
 
-if ( ramsize > GUEST_RAM_MAX )
+if ( ramsize > (bankmax[0] + bankmax[1]) )
 {
 DOMPRINTF("%s: ram size is too large for guest address space: "
   "%"PRIx64" > %llx",
-  __FUNCTION__, ramsize, GUEST_RAM_MAX);
+  __FUNCTION__, ramsize, bankmax[0] + bankmax[1]);
 return -1;
 }
 
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0af8010..7f9547b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -372,7 +372,10 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
 {
 int res, i;
 const char *name;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
 
 for (i = 0; i < GUEST_RAM_BANKS; i++) {
 name = GCSPRINTF("memory@%"PRIx64, bankbase[i]);
@@ -914,7 +917,10 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 {
 void *fdt = dom->devicetree_blob;
 int i;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
 
 const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
 >ramdisk_seg : NULL;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 350e274..1c0579c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -182,6 +182,11 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
 b_info->target_memkb = b_info->max_memkb;
 
+#ifdef GUEST_RAM_BASE
+if (b_info->rambase == LIBXL_INVALID_RAM_BASE)
+b_info->rambase = GUEST_RAM0_BASE;
+#endif
+
 libxl_defbool_setdefault(_info->claim_mode, false);
 
 libxl_defbool_setdefault(_info->localtime, false);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2da3ac4..be6598f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -703,12 +703,12 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 LOGE(ERROR, "xc_dom_boot_xen_init failed");
 goto out;
 }
-#ifdef GUEST_RAM_BASE
-if ( (ret = xc_dom_rambase_init(dom, GUEST_RAM_BASE)) != 0 ) {
+
+if ( (ret = xc_dom_rambase_init(dom, info->rambase)) != 0 ) {
 LOGE(ERROR, "xc_dom_rambase failed");
 goto out;
 }
-#endif
+
 if ( (ret = xc_dom_parse_image(dom)) != 0 ) {
 LOGE(ERROR, "xc_dom_parse_image failed");
 goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1699f32..5b0b50a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -100,6 +100,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define LIBXL_INVALID_GFN (~(uint64_t)0)
+#define LIBXL_INVALID_RAM_BASE (~(uint64_t)0)
 /* use 0 as the domid of the toolstack

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

2016-05-18 Thread Andrii Anisov

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 file changed, 10 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebd..ad07ed5 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -45,6 +45,8 @@
  */
 #define XENKBD_TYPE_POS 4
 
+#define XENKBD_TYPE_RAW 5
+
 struct xenkbd_motion
 {
 uint8_t type;/* XENKBD_TYPE_MOTION */
@@ -68,6 +70,13 @@ struct xenkbd_position
 int32_t rel_z;   /* relative Z motion (wheel) */
 };
 
+struct xenkbd_raw {
+uint8_t type;/* XENKBD_TYPE_RAW */
+uint16_t input_type;
+uint16_t code;
+int32_t value;
+};
+
 #define XENKBD_IN_EVENT_SIZE 40
 
 union xenkbd_in_event
@@ -76,6 +85,7 @@ union xenkbd_in_event
 struct xenkbd_motion motion;
 struct xenkbd_key key;
 struct xenkbd_position pos;
+struct xenkbd_raw raw;
 char pad[XENKBD_IN_EVENT_SIZE];
 };
 
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

From: Oleksandr Dmytryshyn 

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

diff --git a/tools/xenstat/Makefile b/tools/xenstat/Makefile
index 901be4a..440b1b7 100644
--- a/tools/xenstat/Makefile
+++ b/tools/xenstat/Makefile
@@ -4,12 +4,10 @@ include $(XEN_ROOT)/tools/Rules.mk
 SUBDIRS :=
 SUBDIRS += libxenstat
 
-# This doesn't cross-compile (cross-compile environments rarely have curses)
-ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
+# This compiles if compiler environment has curses
 ifeq ($(wildcard /usr/include/curses.h),/usr/include/curses.h)
 SUBDIRS += xentop
 endif
-endif
 
 .PHONY: all install clean distclean
 
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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/arch/arm/irq.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 1f38605..c470613 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -481,12 +481,23 @@ int route_irq_to_guest(struct domain *d, unsigned int 
virq,
 }
 
 if ( test_bit(_IRQ_GUEST, >status) )
-printk(XENLOG_G_ERR "IRQ %u is already used by domain %u\n",
-   irq, ad->domain_id);
+{
+printk(XENLOG_G_DEBUG "IRQ %u is reassigned from domain %u to 
domain %u\n",
+irq, ad->domain_id, d->domain_id);
+
+retval = gic_remove_irq_from_guest(ad, irq, desc);
+if ( retval )
+printk(XENLOG_G_ERR "failed to remove IRQ %u from domain %u 
(%d)\n",
+irq, ad->domain_id, retval);
+xfree(desc->action);
+desc->action = NULL;
+}
 else
+{
 printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
-retval = -EBUSY;
-goto out;
+   retval = -EBUSY;
+   goto out;
+}
 }
 
 retval = __setup_irq(desc, 0, action);
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 changed, 12 insertions(+), 40 deletions(-)

diff --git a/tools/misc/xenwatchdogd.c b/tools/misc/xenwatchdogd.c
index 254117b..4b27628 100644
--- a/tools/misc/xenwatchdogd.c
+++ b/tools/misc/xenwatchdogd.c
@@ -1,17 +1,17 @@
-
 #include 
 #include 
-#include "xenctrl.h"
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
+
+#define DEV_NAME "/dev/watchdog"
 
-xc_interface *h;
-int id = 0;
+int fd = -1;
 
 void daemonize(void)
 {
@@ -36,20 +36,6 @@ void daemonize(void)
 err(1, "reopen stderr");
 }
 
-void catch_exit(int sig)
-{
-if (id)
-xc_watchdog(h, id, 300);
-exit(0);
-}
-
-void catch_usr1(int sig)
-{
-if (id)
-xc_watchdog(h, id, 0);
-exit(0);
-}
-
 int main(int argc, char **argv)
 {
 int t, s;
@@ -60,9 +46,9 @@ int main(int argc, char **argv)
 
 daemonize();
 
-h = xc_interface_open(NULL, NULL, 0);
-if (h == NULL)
-   err(1, "xc_interface_open");
+fd = open(DEV_NAME, O_RDWR);
+if (fd < 0)
+err(1, "xenwatchdogd: Failed to open %s\n", DEV_NAME);
 
 t = strtoul(argv[1], NULL, 0);
 if (t == ULONG_MAX)
@@ -75,25 +61,11 @@ int main(int argc, char **argv)
err(1, "strtoul");
 }
 
-if (signal(SIGHUP, _exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGINT, _exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGQUIT, _exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGTERM, _exit) == SIG_ERR)
-   err(1, "signal");
-if (signal(SIGUSR1, _usr1) == SIG_ERR)
-   err(1, "signal");
-
-id = xc_watchdog(h, 0, t);
-if (id <= 0)
-err(1, "xc_watchdog setup");
-
 for (;;) {
+   ret = ioctl(fd, WDIOC_KEEPALIVE);
+   if (ret)
+   err(1, "xenwatchdogd: Failed to kick watchdog\n");
+
 sleep(s);
-ret = xc_watchdog(h, id, t);
-if (ret != 0)
-err(1, "xc_watchdog");
 }
 }
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1366177..ac50bda 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1634,6 +1634,10 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 dis->drs.callback = devices_destroy_cb;
 dis->drs.force = 1;
 libxl__devices_destroy(egc, >drs);
+rc = xc_domain_destroy(ctx->xch, domid);
+if (rc < 0) {
+LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy 
failed for %d", domid);
+}
 return;
 
 out:
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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/Rules.mk |  1 +
 xen/arch/arm/setup.c | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 51f7124..30f5227 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -66,6 +66,7 @@ CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
 CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
+CFLAGS-$(ARM32_XENHEAP_IN_LOWMEM) += -DARM32_XENHEAP_IN_LOWMEM
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7e507bc..5510a34 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -475,7 +475,11 @@ static void init_pdx(void)
 #ifdef CONFIG_ARM_32
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+paddr_t ram_start, ram_end, ram_size, dma32_end;
+#else
 paddr_t ram_start, ram_end, ram_size;
+#endif
 paddr_t s, e;
 unsigned long ram_pages;
 unsigned long heap_pages, xenheap_pages, domheap_pages;
@@ -492,6 +496,9 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_start = bootinfo.mem.bank[0].start;
 ram_size  = bootinfo.mem.bank[0].size;
 ram_end   = ram_start + ram_size;
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+dma32_end = ram_end > 0x1ULL ? 0 : ram_end;
+#endif
 
 for ( i = 1; i < bootinfo.mem.nr_banks; i++ )
 {
@@ -502,6 +509,9 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 ram_size  = ram_size + bank_size;
 ram_start = min(ram_start,bank_start);
 ram_end   = max(ram_end,bank_end);
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+dma32_end = bank_end > 0x1ULL ? dma32_end : bank_end;
+#endif
 }
 
 total_pages = ram_pages = ram_size >> PAGE_SHIFT;
@@ -530,7 +540,11 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 
 do
 {
+#ifdef ARM32_XENHEAP_IN_LOWMEM
+e = consider_modules(ram_start, dma32_end,
+#else
 e = consider_modules(ram_start, ram_end,
+#endif
  pfn_to_paddr(xenheap_pages),
  32<<20, 0);
 if ( e )
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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|   1 +
 xen/arch/arm/domain_build.c | 189 +++-
 xen/arch/arm/kernel.h   |   9 +++
 3 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index fbd34a5..51f7124 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -65,6 +65,7 @@ CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
+CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f06792e..a63958b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -35,6 +35,11 @@ int dom0_11_mapping = 1;
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+#define DOM0_MEM_HIGH_DEFAULT 0x0 /* 0 MiB */
+static u64 __initdata dom0_mem_high = DOM0_MEM_HIGH_DEFAULT;
+#endif
+
 static void __init parse_dom0_mem(const char *s)
 {
 dom0_mem = parse_size_and_unit(s, );
@@ -43,6 +48,14 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+static void __init parse_dom0_mem_high(const char *s)
+{
+dom0_mem_high = parse_size_and_unit(s, );
+}
+custom_param("dom0_mem_high", parse_dom0_mem_high);
+#endif
+
 //#define DEBUG_DT
 
 #ifdef DEBUG_DT
@@ -130,7 +143,11 @@ static bool_t insert_11_bank(struct domain *d,
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
+#ifndef ARM32_SEPAR_MEM_SPLIT
 kinfo->unassigned_mem -= size;
+#else
+kinfo->unassigned_mem.low -= size;
+#endif
 
 if ( kinfo->mem.nr_banks == 0 )
 {
@@ -192,6 +209,82 @@ fail:
 return false;
 }
 
+#ifdef ARM32_SEPAR_MEM_SPLIT
+static void allocate_dom0_high_memory(struct domain *d, struct kernel_info 
*kinfo)
+{
+int i, res, st_banks = kinfo->mem.nr_banks;
+struct page_info *pg = NULL;
+int bits;
+unsigned int order = get_11_allocation_size(dom0_mem_high);
+const unsigned int min_order = get_order_from_bytes(MB(4));
+paddr_t spfn;
+paddr_t start, size;
+struct membank *bank = NULL;
+
+if (dom0_mem_high == 0)
+return;
+
+printk("Allocating %ldMB of high memory region for dom0\n",
+(unsigned long)(dom0_mem_high >> 20));
+
+while ( kinfo->unassigned_mem.high && kinfo->mem.nr_banks < NR_MEM_BANKS )
+{
+for (bits = PADDR_BITS ; bits >= min_order; bits-- )
+{
+pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+if ( pg != NULL )
+break;
+}
+
+if ( !pg )
+{
+order --;
+if ( order >= min_order )
+continue;
+
+/* No more we can do */
+break;
+}
+
+spfn = page_to_mfn(pg);
+start = pfn_to_paddr(spfn);
+size = pfn_to_paddr((1 << order));
+
+res = guest_physmap_add_page(d, spfn, spfn, order);
+if ( res )
+panic("Failed map pages to DOM0: %d", res);
+
+kinfo->unassigned_mem.high -= size;
+
+bank = >mem.bank[kinfo->mem.nr_banks];
+
+bank->start = start;
+bank->size = size;
+kinfo->mem.nr_banks++;
+
+/*
+ * Success, next time around try again to get the largest order
+ * allocation possible.
+ */
+
+order = get_11_allocation_size(kinfo->unassigned_mem.high);
+ }
+
+if(kinfo->unassigned_mem.high)
+panic("Unable to allocate high memory bank");
+
+for( i = st_banks; i < kinfo->mem.nr_banks; i++ )
+{
+printk("BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+   i,
+   kinfo->mem.bank[i].start,
+   kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+   /* Don't want format this as PRIpaddr (16 digit hex) */
+   (unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+}
+#endif
+
 /*
  * This is all pretty horrible.
  *
@@ -250,9 +343,13 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 get_11_allocation_size(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 u64 rambase_pfn = opt_dom0_rambase_pfn;
+#ifndef ARM32_SEPAR_MEM_SPLIT
+unsigned int order =

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

2016-05-18 Thread Andrii Anisov

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 Tseglytskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxc/xc_dom_arm.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index aeaba54..5ee8eef 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -33,7 +33,11 @@
 #define LPAE_SHIFT 9
 
 #define PFN_4K_SHIFT  (0)
+#define PFN_1M_SHIFT  (PFN_4K_SHIFT + 8)
 #define PFN_2M_SHIFT  (PFN_4K_SHIFT+LPAE_SHIFT)
+#define PFN_128M_SHIFT  (PFN_2M_SHIFT + 6)
+#define PFN_256M_SHIFT  (PFN_128M_SHIFT + 1)
+#define PFN_512M_SHIFT  (PFN_256M_SHIFT + 1)
 #define PFN_1G_SHIFT  (PFN_2M_SHIFT+LPAE_SHIFT)
 #define PFN_512G_SHIFT (PFN_1G_SHIFT+LPAE_SHIFT)
 
@@ -359,11 +363,31 @@ static int populate_guest_memory(struct xc_dom_image *dom,
 if ( rc < 0 ) break;
 if ( rc > 0 ) continue;
 
+rc = populate_one_size(dom, PFN_512M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_256M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
+rc = populate_one_size(dom, PFN_128M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
 rc = populate_one_size(dom, PFN_2M_SHIFT,
base_pfn + pfn, , extents);
 if ( rc < 0 ) break;
 if ( rc > 0 ) continue;
 
+rc = populate_one_size(dom, PFN_1M_SHIFT,
+   base_pfn + pfn, , extents);
+if ( rc < 0 ) break;
+if ( rc > 0 ) continue;
+
 rc = populate_one_size(dom, PFN_4K_SHIFT,
base_pfn + pfn, , extents);
 if ( rc < 0 ) break;
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 insertions(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 28d57c3..98a46bc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2988,6 +2988,21 @@ start:
 d_config.c_info.name = strdup(common_domname);
 }
 
+   if (config_file) {
+   libxl_domain_config_init(_config);
+
+   ret = libxl_read_file_contents(ctx, config_file,
+  _data, _len);
+   if (ret) {
+   LOG("Failed to read config file: %s: %s\n",
+   config_file, strerror(errno));
+   goto out;
+   }
+
+   parse_config_data(config_file, config_data, config_len,
+ _config);
+   }
+
 /*
  * XXX FIXME: If this sleep is not there then domain
  * re-creation fails sometimes.
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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.tseglyts...@globallogic.com>
---
 tools/hotplug/Linux/block| 2 +-
 tools/hotplug/Linux/locking.sh   | 9 +++--
 tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
index 8d2ee9d..6a725db 100644
--- a/tools/hotplug/Linux/block
+++ b/tools/hotplug/Linux/block
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 dir=$(dirname "$0")
 . "$dir/block-common.sh"
diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
index c6a7e96..b8e9515 100644
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
 
 _setlockfd()
 {
+local lock_
 local i
-for ((i = 0; i < ${#_lockdict}; i++))
-do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
+let i=0
+
+for lock_ in _lockdict ;
+do
+[ -z "$lock_" -o "$lock_" = "$1" ] && break
+(( i++ ))
 done
 _lockdict[$i]="$1"
 let _lockfd=200+i
diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in 
b/tools/hotplug/Linux/xen-hotplug-common.sh.in
index d5d0b69..42e46e3 100644
--- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
+++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
@@ -51,7 +51,7 @@ sigerr() {
   fatal "$0 failed; error detected."
 }
 
-trap sigerr ERR
+#trap sigerr ERR
 
 
 ##
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 aligned with the smallest memory chunk
which use xen memory allocator.

Signed-off-by: Oleksandr Dmytryshyn 
---
 xen/arch/arm/domain_build.c | 24 +---
 xen/common/page_alloc.c | 68 +++--
 xen/include/xen/mm.h|  2 ++
 3 files changed, 75 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2937ff7..b48718d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
 
+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
+
 int dom0_11_mapping = 1;
 
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;
+paddr_t mem_size = kinfo->unassigned_mem;
 int i;
 
 bool_t lowmem = is_32bit_domain(d);
@@ -267,7 +272,7 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 {
 for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
 {
-pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+pg = alloc_domheap_pages_pfn(d, order, MEMF_bits(bits), 
rambase_pfn);
 if ( pg != NULL )
 goto got_bank0;
 }
@@ -284,16 +289,21 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 /* Now allocate more memory and fill in additional banks */
 
 order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+
 while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
 {
-pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
+pg = alloc_domheap_pages_pfn(d, order, lowmem ? MEMF_bits(32) : 0,
+ rambase_pfn);
 if ( !pg )
 {
 order --;
 
 if ( lowmem && order < min_low_order)
 {
-D11PRINT("Failed at min_low_order, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Failed at min_low_order, allow high 
allocations\n");
 order = get_11_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
@@ -313,7 +323,8 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 
 if ( lowmem )
 {
-D11PRINT("Allocation below bank 0, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Allocation below bank 0, allow high 
allocations\n");
 order = get_11_allocation_size(kinfo->unassigned_mem);
 lowmem = false;
 continue;
@@ -330,6 +341,11 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
  * allocation possible.
  */
 order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+{
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+mem_size = kinfo->unassigned_mem;
+}
 }
 
 if ( kinfo->unassigned_mem )
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 74fc1de..d0c0fbb 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -583,16 +583,17 @@ static void check_low_mem_virq(void)
 }
 }
 
-/* Allocate 2^@order contiguous pages. */
-static struct page_info *alloc_heap_pages(
+/* Allocate 2^@order contiguous pages at given pfn. */
+static struct page_info *alloc_heap_pages_pfn(
 unsigned int zone_lo, unsigned int zone_hi,
 unsigned int order, unsigned int memflags,
-struct domain *d)
+struct domain *d, xen_pfn_t pfn)
 {
 unsigned int i, j, zone = 0, nodemask_retry = 0;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
 unsigned long request = 1UL << order;
-struct page_info *pg;
+struct page_info *pg, *tmp_pg;
+struct page_list_head *pg_list;
 nodemask_t nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
 bool_t need_tlbflush = 0;
 uint32_t tlbflush_timestamp = 0;
@@ -657,9 +658,25 @@

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

2016-05-18 Thread Andrii Anisov

From: Oleksandr Dmytryshyn 

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 
---
 xen/arch/arm/mm.c   | 33 +
 xen/include/public/memory.h | 12 +++-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b5d8c85..04fb813 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1150,10 +1150,43 @@ int xenmem_add_to_physmap_one(
 return rc;
 }
 
+#define MAX_P2M_ENTRIES_CNT 1
+
+static long arch_paddr_to_maddr_batch(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_p2m_lookup p2mr;
+xen_pfn_t paddr, maddr;
+unsigned int i;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+if (p2mr.count < 1 || p2mr.count > MAX_P2M_ENTRIES_CNT)
+return -EINVAL;
+
+if ( guest_handle_is_null(p2mr.paddrs) ||
+ guest_handle_is_null(p2mr.maddrs))
+return -EINVAL;
+
+for ( i = 0; i < p2mr.count; i++ )
+{
+if ( unlikely(__copy_from_guest_offset(, p2mr.paddrs, i, 1)) )
+return -EFAULT;
+
+maddr = p2m_lookup(current->domain, paddr, NULL);
+
+if ( unlikely(__copy_to_guest_offset(p2mr.maddrs, i, , 1)) )
+return -EFAULT;
+}
+return 0;
+}
+
 long arch_memory_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 switch ( op )
 {
+case XENMEM_p2m_lookup:
+return arch_paddr_to_maddr_batch(arg);
 /* XXX: memsharing not working yet */
 case XENMEM_get_sharing_shared_pages:
 case XENMEM_get_sharing_freed_pages:
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 320de91..dfc5171 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -608,7 +608,17 @@ struct xen_vnuma_topology_info {
 typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t;
 DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t);
 
-/* Next available subop number is 28 */
+struct xen_p2m_lookup {
+uint32_t count;
+XEN_GUEST_HANDLE(xen_pfn_t) paddrs; /* IN:  physical addresses */
+XEN_GUEST_HANDLE(xen_pfn_t) maddrs; /* OUT: machine addresses */
+};
+typedef struct xen_p2m_lookup xen_p2m_lookup_t;
+DEFINE_XEN_GUEST_HANDLE(xen_p2m_lookup_t);
+
+#define XENMEM_p2m_lookup 28
+
+/* Next available subop number is 29 */
 
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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

If you didn't specify high memory with this option enabled,
domain memory will be limited to 4GB (zone 20)

Signed-off-by: Iurii Mykhalskyi 
Signed-off-by: Iurii Konovalenko 
---
 tools/libxc/Makefile  |  2 ++
 tools/libxc/include/xc_dom.h  | 24 +++--
 tools/libxc/xc_dom_arm.c  | 66 +++
 tools/libxc/xc_dom_compat_linux.c |  5 +++
 tools/libxc/xc_dom_core.c | 51 ++-
 tools/libxl/Makefile  |  2 ++
 tools/libxl/libxl_arm.c   | 11 ++
 tools/libxl/libxl_dom.c   | 23 
 tools/libxl/libxl_types.idl   |  1 +
 tools/libxl/xl_cmdimpl.c  |  5 +++
 tools/xenstore/init-xenstore-domain.c |  5 +++
 xen/arch/arm/domain_build.c   | 11 +-
 xen/common/memory.c   | 16 -
 xen/common/page_alloc.c   | 23 
 xen/include/public/memory.h   |  6 
 xen/include/xen/mm.h  |  6 
 16 files changed, 245 insertions(+), 12 deletions(-)

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index a0f899b..84d21b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -112,6 +112,8 @@ CFLAGS   += -I. -I./include $(CFLAGS_xeninclude)
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
 
+CFLAGS-$(ARM32_SEPAR_MEM_SPLIT) += -DARM32_SEPAR_MEM_SPLIT
+
 CFLAGS += $(PTHREAD_CFLAGS)
 
 CTRL_LIB_OBJS := $(patsubst %.c,%.o,$(CTRL_SRCS-y))
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 600aef6..10bb6ab 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -129,12 +129,22 @@ struct xc_dom_image {
  * in rambase_pfn.
  */
 xen_pfn_t rambase_pfn;
+#ifndef ARM32_SEPAR_MEM_SPLIT
 xen_pfn_t total_pages;
+#else
+xen_pfn_t low_mem_pages;
+xen_pfn_t high_mem_pages;
+#endif
 xen_pfn_t p2m_size; /* number of pfns covered by p2m */
 struct xc_dom_phys *phys_pages;
 int realmodearea_log;
 #if defined (__arm__) || defined(__aarch64__)
+#ifndef ARM32_SEPAR_MEM_SPLIT
 xen_pfn_t rambank_size[GUEST_RAM_BANKS];
+#else
+xen_pfn_t rambank_size_low[GUEST_RAM_BANKS];
+xen_pfn_t rambank_size_high[GUEST_RAM_BANKS];
+#endif
 #endif
 
 /* malloc memory pool */
@@ -181,6 +191,12 @@ struct xc_dom_image {
 int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
 };
 
+#ifndef ARM32_SEPAR_MEM_SPLIT
+#define XC_DOM_TOTAL_PAGES(dom) ((dom)->total_pages)
+#else
+#define XC_DOM_TOTAL_PAGES(dom) ((dom)->low_mem_pages + (dom)->high_mem_pages)
+#endif
+
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
@@ -228,7 +244,11 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 void xc_dom_release_phys(struct xc_dom_image *dom);
 void xc_dom_release(struct xc_dom_image *dom);
 int xc_dom_rambase_init(struct xc_dom_image *dom, uint64_t rambase);
+#ifndef ARM32_SEPAR_MEM_SPLIT
 int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb);
+#else
+int xc_dom_mem_init(struct xc_dom_image *dom, unsigned int mem_mb_low, 
unsigned int mem_mb_high);
+#endif
 
 /* Set this larger if you have enormous ramdisks/kernels. Note that
  * you should trust all kernels not to be maliciously large (e.g. to
@@ -379,7 +399,7 @@ static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 {
 if (dom->shadow_enabled)
 return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
+if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + 
XC_DOM_TOTAL_PAGES(dom))
 return INVALID_MFN;
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
@@ -389,7 +409,7 @@ static inline xen_pfn_t xc_dom_p2m_guest(struct 
xc_dom_image *dom,
 {
 if (xc_dom_feature_translated(dom))
 return pfn;
-if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + dom->total_pages)
+if (pfn < dom->rambase_pfn || pfn >= dom->rambase_pfn + 
XC_DOM_TOTAL_PAGES(dom))
 return INVALID_MFN;
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 96df669..d995241 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -306,8 +306,19 @@ static int populate_one_size(struct xc_dom_image *dom, int 
pfn_shift,
 for ( i = 0 ; i < count ; i ++ )
 extents[i] = base_pfn + (i<

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

2016-05-18 Thread Andrii Anisov

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/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/platforms/omap5.c | 17 ++---
 xen/arch/arm/platforms/rcar2.c |  9 -
 xen/arch/arm/setup.c   | 21 -
 xen/arch/arm/smpboot.c | 33 +
 7 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index feb08d6..fbd34a5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI)   += -DHAS_PCI
 CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
 
 ifneq ($(max_phys_cpus),)
 CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e1f29bd..a644d6d 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -262,8 +262,21 @@ cpu_init_done:
 add   r4, r4, r10/* r4 := paddr (boot_pagetable) */
 mov   r5, #0 /* r4:r5 is paddr (boot_pagetable) */
 mcrr  CP64(r4, r5, HTTBR)
+#ifdef ARM32_RELOCATE_OVER_4GB
+teq   r7, #0
+beq   1f /* construct pagetable if CPU0 */
 
-/* Setup boot_pgtable: */
+/*Skip constructing TLBs for secondary CPUs, use constracted by CPU0*/
+PRINT("- Skip construction pagetable, using CPU0 table @")
+mov   r0, r5
+blputn
+mov   r0, r4
+blputn
+PRINT("  -\r\n")
+bne   skip_constructing
+#endif
+
+1:  /* Setup boot_pgtable: */
 ldr   r1, =boot_second
 add   r1, r1, r10/* r1 := paddr (boot_second) */
 
@@ -346,6 +359,7 @@ virtphys_clash:
 PRINT("- Unable to build boot page tables - virt and phys addresses 
clash. -\r\n")
 b fail
 
+skip_constructing:
 1:
 PRINT("- Turning on paging -\r\n")
 
@@ -427,6 +441,11 @@ paging:
  * setup in init_secondary_pagetables. */
 
 ldr   r4, =init_ttbr /* VA of HTTBR value stashed by CPU 0 */
+#ifdef ARM32_RELOCATE_OVER_4GB
+ldr   r1, =_start
+sub r4, r1
+add r4, #BOOT_RELOC_VIRT_START
+#endif
 ldrd  r4, r5, [r4]   /* Actual value */
 dsb
 mcrr  CP64(r4, r5, HTTBR)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b48718d..f06792e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1487,7 +1487,7 @@ static void __init find_gnttab_region(struct domain *d,
 if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
 panic("Cannot find a space for the grant table region\n");
 
-#ifdef CONFIG_ARM_32
+#if defined(CONFIG_ARM_32) && !defined(ARM32_RELOCATE_OVER_4GB)
 /*
  * The gnttab region must be under 4GB in order to work with DOM0
  * using short page table.
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index a49ba62..fe77397 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 
+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
+
 static uint16_t num_den[8][2] = {
 { 0,  0 },  /* not used */
 {  26 *  64,  26 *  125 },  /* 12.0 Mhz */
@@ -132,9 +136,16 @@ static int __init omap5_smp_init(void)
 }
 
 printk("Set AuxCoreBoot1 to %"PRIpaddr" (%p)\n",
-   __pa(init_secondary), init_secondary);
-writel(__pa(init_secondary), wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
-
+   __pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , init_secondary);
+writel(__pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+   , wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
 printk("Set AuxCoreBoot0 to 0x20\n");
 writel(0x20, wugen_base + OMAP_AUX_CORE_BOOT_0_OFFSET);
 
diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index bb25751..26973f6 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platforms/rcar2.c
@@ -25,6 +25,9 @@
 #define RCAR2_RAM_SIZE 0x1000
 #define RCAR2_SMP_START_OFFSET 0xFFC
 
+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
 static int __init rcar2_smp_init(void)
 {
 void __iomem *pram;
@@ -38,7 +41,11 @@ static int __init rcar2_smp_init(void)
 }
 
 /* setup reset vectors */
-writel(__pa(init_secondary), pram + RCAR2_SMP_START_OFFSET);
+

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

2016-05-18 Thread Andrii Anisov

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 
---
 tools/flask/policy/policy/modules/xen/xen.te | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 5e94ee3..b3eaa15 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -116,6 +116,7 @@ admin_device(dom0_t, device_t)
 admin_device(dom0_t, irq_t)
 admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
+admin_device(domU_t, irq_t);
 
 domain_comms(dom0_t, dom0_t)
 
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

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 changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a059de6..2937ff7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -244,7 +244,7 @@ fail:
 static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
-get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
+get_11_allocation_size(min_t(paddr_t, dom0_mem, MB(128)));
 const unsigned int min_order = get_order_from_bytes(MB(4));
 struct page_info *pg;
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-18 Thread Andrii Anisov

This series RFC patches from the currently ongoing production project.
This patch series presents changes needed to fit the system into
customer requirements as well as workaround limitations of the
Jacinto6 SoC.
This patch series is not a full production branch upstream. Lacks of
the board 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 interrupts to guest domain

Iurii Konovalenko (3):
  arm: Fix 1-to-1 Dom0 memory allocation of any size
  arm: Add ability to relocate Xen in over 4GB space
  arm: Add ability to allocate Xen heap in lowmem

Iurii Mykhalskyi (3):
  xen: flask: Add possiblity to forward irqs into domU domains
  xen: Add dom0_mem_high option & over 4GB memory allocation for Dom0
  tools: Introduce ARM32_SEPAR_MEM_SPLIT option

Oleksandr Dmytryshyn (3):
  tools: Allow to cross-compile xentop
  xen: arm: add batch support to the XENMEM_p2m_lookup operation
  xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

Oleksandr Tyshchenko (1):
  libxl: add ability to set rambase_pfn via cfg file

Sergiy Kibrik (1):
  kbdif: add raw events passing

Viktor Kleinik (4):
  libxl: parse config data during domain reboot
  tools/misc: Modify Xen watchdog daemon
  tools/misc: Set timeout value from watchdog daemon
  libxl: Fix unneeded domain reboot during destroy routine

 tools/flask/policy/policy/modules/xen/xen.te |   1 +
 tools/hotplug/Linux/block|   2 +-
 tools/hotplug/Linux/locking.sh   |   9 +-
 tools/hotplug/Linux/xen-hotplug-common.sh.in |   2 +-
 tools/libxc/Makefile |   2 +
 tools/libxc/include/xc_dom.h |  24 ++-
 tools/libxc/xc_dom_arm.c | 103 +++-
 tools/libxc/xc_dom_compat_linux.c|   5 +
 tools/libxc/xc_dom_core.c|  51 +-
 tools/libxl/Makefile |   2 +
 tools/libxl/libxl.c  |   4 +
 tools/libxl/libxl_arm.c  |  21 ++-
 tools/libxl/libxl_create.c   |   5 +
 tools/libxl/libxl_dom.c  |  29 +++-
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_types.idl  |   2 +
 tools/libxl/xl_cmdimpl.c |  33 
 tools/misc/xenwatchdogd.c|  54 ++-
 tools/xenstat/Makefile   |   4 +-
 tools/xenstore/init-xenstore-domain.c|   5 +
 xen/Rules.mk |   3 +
 xen/arch/arm/arm32/head.S|  21 ++-
 xen/arch/arm/domain_build.c  | 224 ++-
 xen/arch/arm/irq.c   |  19 ++-
 xen/arch/arm/kernel.h|   9 ++
 xen/arch/arm/mm.c|  33 
 xen/arch/arm/platforms/omap5.c   |  17 +-
 xen/arch/arm/platforms/rcar2.c   |   9 +-
 xen/arch/arm/setup.c |  35 -
 xen/arch/arm/smpboot.c   |  33 +++-
 xen/common/memory.c  |  16 +-
 xen/common/page_alloc.c  |  91 +--
 xen/include/public/io/kbdif.h|  10 ++
 xen/include/public/memory.h  |  18 ++-
 xen/include/xen/mm.h |   8 +
 35 files changed, 801 insertions(+), 104 deletions(-)

-- 
2.8.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2017-02-01 Thread Andrii Anisov

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 Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-01 Thread Andrii Anisov

Dear Konrad,

You are not correct here:
> But there are no Kconfig DEBUG - so you may as well just do
> #if 0
>
> around the code.

DEBUG macro is widely used in the kernel, just try grepping it through
the code. Elementary example is pr_debug definition which is resolved
through DEBUG 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@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-01 Thread Andrii Anisov

Stefano,

> Ah! Ops :-)
>
> DEBUG_KERNEL?

You said DEBUG_DRIVER last time.
Both DEBUG_KERNEL and DEBUG_DRIVER are not used in code. DEBUG_KERNEL
is used through Kconfigs to make available debug options to other
different stuff, which consequently define DEBUG through appropriate
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, Stefano Stabellini wrote:
>> > On Tue, 31 Jan 2017, Konrad Rzeszutek Wilk wrote:
>> > > On Tue, Jan 31, 2017 at 08:30:26PM +0200, Andrii Anisov wrote:
>> > > > 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-xen.h |  6 ++
>> > > >  3 files changed, 29 insertions(+)
>> > > >
>> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
>> > > > index cd1684e..76ea48a 100644
>> > > > --- a/arch/arm/xen/mm.c
>> > > > +++ b/arch/arm/xen/mm.c
>> > > > @@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
>> > > > .dma_supported = xen_swiotlb_dma_supported,
>> > > > .set_dma_mask = xen_swiotlb_set_dma_mask,
>> > > > .mmap = xen_swiotlb_dma_mmap,
>> > > > +   .get_sgtable = xen_swiotlb_get_sgtable,
>> > > >  };
>> > > >
>> > > >  int __init xen_mm_init(void)
>> > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> > > > index 8ac36b4..a809d43 100644
>> > > > --- a/drivers/xen/swiotlb-xen.c
>> > > > +++ b/drivers/xen/swiotlb-xen.c
>> > > > @@ -699,3 +699,25 @@ xen_swiotlb_dma_mmap(struct device *dev, struct 
>> > > > vm_area_struct *vma,
>> > > > return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
>> > > >  }
>> > > >  EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);
>> > > > +
>> > > > +/*
>> > > > + * Following function should be called with the local pages only.
>> > >
>> > > What does 'local pages' mean?
>> > >
>> > > > + */
>> > > > +int
>> > > > +xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>> > > > +   void *cpu_addr, dma_addr_t handle, size_t size,
>> > > > +   unsigned long attrs)
>> > > > +{
>> > > > +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>> > > > +   if (__generic_dma_ops(dev)->get_sgtable) {
>> > > > +#ifdef DEBUG
>> > > > +   unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
>> > > > +   BUG_ON (!page_is_ram(bfn));
>> > > > +#endif
>> > >
>> > > Could you remove the above please?
>> >
>> > I asked him to add it (see
>> > http://marc.info/?l=xen-devel=148461541618751): the reason is that
>> > this function cannot work on foreign pages. From the commit message
>> > (d2b7428eb0caa7c66e34b6ac869a43915b294123) it looks like it is supposed
>> > to be called on buffers returned by dma_alloc_coherent, thus it should
>> > be safe.  However, if that's not the case in any of the drivers, it
>> > would lead to memory corruptions. The two lines under ifdef DEBUG are an
>> > nice way to catch this kind of errors. However, given that they cost a
>> > few cpu cycles more than necessary, I wouldn't enable them in
>> > production, hence the ifdef DEBUG.
>>
>> But there are no Kconfig DEBUG - so you may as well just do
>> #if 0
>>
>> around the code.
>

>
>> > > > +   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, 
>> > > > cpu_addr,
>> > > > +  handle, 
>> > > > size, attrs);
>> > > > +   }
>> > > > +#endif
>> > > > +   return dma_common_get_sgtable(dev, sgt, cpu_addr, h

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

2017-02-01 Thread Andrii Anisov

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,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-01 Thread Andrii Anisov

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/xen/Kconfig b/drivers/xen/Kconfig
index f15bb3b7..733c433 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -298,4 +298,12 @@ config XEN_SYMS
 config XEN_HAVE_VPMU
bool
 
+config DEBUG_XEN
+   bool "XEN Drivers debug"
+   depends on DEBUG_KERNEL
+   help
+ Say Y here if you want to enable XEN drivers debug code.
+
+ If you are unsure about this, say N here.
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 8feab810..c886e9d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -42,3 +42,5 @@ xen-evtchn-y  := evtchn.o
 xen-gntdev-y   := gntdev.o
 xen-gntalloc-y := gntalloc.o
 xen-privcmd-y  := privcmd.o
+
+ccflags-$(CONFIG_DEBUG_XEN) := -DDEBUG
\ No newline at end of file
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-01 Thread Andrii Anisov

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
https://lists.xen.org/xen-devel

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

2017-01-31 Thread Andrii Anisov

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>
Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 arch/arm/xen/mm.c |  1 +
 drivers/xen/swiotlb-xen.c | 18 ++
 include/xen/swiotlb-xen.h |  5 +
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index bd62d94..cd1684e 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -198,6 +198,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+   .mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f8afc6d..8ac36b4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -681,3 +681,21 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ * Following function should be called with the local pages only.
+ */
+int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs)
+{
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   if (__generic_dma_ops(dev)->mmap)
+   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr,
+   dma_addr, size, attrs);
+#endif
+   return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0083be..5c8f4c8 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -55,4 +55,9 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs);
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-31 Thread Andrii Anisov

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-xen.h |  6 ++
 3 files changed, 29 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cd1684e..76ea48a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
.mmap = xen_swiotlb_dma_mmap,
+   .get_sgtable = xen_swiotlb_get_sgtable,
 };
 
 int __init xen_mm_init(void)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8ac36b4..a809d43 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -699,3 +699,25 @@ xen_swiotlb_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);
+
+/*
+ * Following function should be called with the local pages only.
+ */
+int
+xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+   void *cpu_addr, dma_addr_t handle, size_t size,
+   unsigned long attrs)
+{
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   if (__generic_dma_ops(dev)->get_sgtable) {
+#ifdef DEBUG
+   unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
+   BUG_ON (!page_is_ram(bfn));
+#endif
+   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
+  handle, size, attrs);
+   }
+#endif
+   return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_sgtable);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 5c8f4c8..c554c23 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -60,4 +60,10 @@ extern int
 xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
+
+extern int
+xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+   void *cpu_addr, dma_addr_t handle, size_t size,
+   unsigned long attrs);
+
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-31 Thread Andrii Anisov

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 a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel=139695901430667=4

Changes in V3:
 - dma ops are moved from ARM specific to generic code
 - runtime operation verified for arm64 with LK 4.9
 - compilation verified for arm, arm64, x86 with the current LK master HEAD
   566cf877a1fcb6d6dc0126b076aad062054c2637

Changes in V2:
 - patches are rebased and checked for compilation for x86, arm, arm64 with
   the current LK master HEAD 83346fbc07d267de777e2597552f785174ad0373

Andrii Anisov (1):
  swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Stefano Stabellini (1):
  swiotlb-xen: implement xen_swiotlb_dma_mmap callback

 arch/arm/xen/mm.c |  2 ++
 drivers/xen/swiotlb-xen.c | 40 
 include/xen/swiotlb-xen.h | 11 +++
 3 files changed, 53 insertions(+)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-07 Thread Andrii Anisov

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 a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel=139695901430667=4

Changes in V4:
 - No functional changes
 - '#ifdef DEBUG' is replaced with '#if 0' for a debug code because Konrad
   insisted
 - Added more comments for the functions added and for the debug code
 - fixed code alignment.

Changes in V3:
 - dma ops are moved from ARM specific to generic code
 - runtime operation verified for arm64 with LK 4.9
 - compilation verified for arm, arm64, x86 with the current LK master HEAD
   566cf877a1fcb6d6dc0126b076aad062054c2637

Changes in V2:
 - patches are rebased and checked for compilation for x86, arm, arm64 with
   the current LK master HEAD 83346fbc07d267de777e2597552f785174ad0373

Andrii Anisov (1):
  swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Stefano Stabellini (1):
  swiotlb-xen: implement xen_swiotlb_dma_mmap callback

 arch/arm/xen/mm.c |  2 ++
 drivers/xen/swiotlb-xen.c | 47 +++
 include/xen/swiotlb-xen.h | 11 +++
 3 files changed, 60 insertions(+)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-07 Thread Andrii Anisov

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>
Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 arch/arm/xen/mm.c |  1 +
 drivers/xen/swiotlb-xen.c | 19 +++
 include/xen/swiotlb-xen.h |  5 +
 3 files changed, 25 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index bd62d94..cd1684e 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -198,6 +198,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+   .mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f8afc6d..728d4e0 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -681,3 +681,22 @@ xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ * This function should be called with the pages from the current domain only,
+ * passing pages mapped from other domains would lead to memory corruption.
+ */
+int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   if (__generic_dma_ops(dev)->mmap)
+   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr,
+   dma_addr, size, attrs);
+#endif
+   return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0083be..a315c87 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -55,4 +55,9 @@ xen_swiotlb_dma_supported(struct device *hwdev, u64 mask);
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs);
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-07 Thread Andrii Anisov

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/swiotlb-xen.h |  6 ++
 3 files changed, 35 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cd1684e..76ea48a 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
.mmap = xen_swiotlb_dma_mmap,
+   .get_sgtable = xen_swiotlb_get_sgtable,
 };
 
 int __init xen_mm_init(void)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 728d4e0..e8cef1a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -700,3 +700,31 @@ xen_swiotlb_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);
+
+/*
+ * This function should be called with the pages from the current domain only,
+ * passing pages mapped from other domains would lead to memory corruption.
+ */
+int
+xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+   void *cpu_addr, dma_addr_t handle, size_t size,
+   unsigned long attrs)
+{
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+   if (__generic_dma_ops(dev)->get_sgtable) {
+#if 0
+   /*
+* This check verifies that the page belongs to the current domain and
+* is not one mapped from another domain.
+* This check is for debug only, and should not go to production build
+*/
+   unsigned long bfn = PHYS_PFN(dma_to_phys(dev, handle));
+   BUG_ON (!page_is_ram(bfn));
+#endif
+   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr,
+  handle, size, attrs);
+   }
+#endif
+   return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_sgtable);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a315c87..1f6d78f 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -2,6 +2,7 @@
 #define __LINUX_SWIOTLB_XEN_H
 
 #include 
+#include 
 #include 
 
 extern int xen_swiotlb_init(int verbose, bool early);
@@ -60,4 +61,9 @@ extern int
 xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
 void *cpu_addr, dma_addr_t dma_addr, size_t size,
 unsigned long attrs);
+
+extern int
+xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+   void *cpu_addr, dma_addr_t handle, size_t size,
+   unsigned long attrs);
 #endif /* __LINUX_SWIOTLB_XEN_H */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-13 Thread Andrii Anisov

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 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 a port of an antique and lost patch discussed here:
> http://marc.info/?l=xen-devel=139695901430667=4
>
> Changes in V4:
>  - No functional changes
>  - '#ifdef DEBUG' is replaced with '#if 0' for a debug code because Konrad
>insisted
>  - Added more comments for the functions added and for the debug code
>  - fixed code alignment.
>
> Changes in V3:
>  - dma ops are moved from ARM specific to generic code
>  - runtime operation verified for arm64 with LK 4.9
>  - compilation verified for arm, arm64, x86 with the current LK master HEAD
>566cf877a1fcb6d6dc0126b076aad062054c2637
>
> Changes in V2:
>  - patches are rebased and checked for compilation for x86, arm, arm64 with
>    the current LK master HEAD 83346fbc07d267de777e2597552f785174ad0373
>
> Andrii Anisov (1):
>   swiotlb-xen: implement xen_swiotlb_get_sgtable callback
>
> Stefano Stabellini (1):
>   swiotlb-xen: implement xen_swiotlb_dma_mmap callback
>
>  arch/arm/xen/mm.c |  2 ++
>  drivers/xen/swiotlb-xen.c | 47 ++
> +
>  include/xen/swiotlb-xen.h | 11 +++
>  3 files changed, 60 insertions(+)
>
> --
> 2.7.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

Dear Paul,

> Many moons ago there were patches to use rbtree for rangesets. Perhaps it 
> would be worth reviving that idea?
rbtree is a thing I think of now for our needs.
Even more, currently I think of refactoring ARM mmio ranges managing
to use rbtree one day. Currently there is a static array of 16 ranges
maximum with sort on insert and bsearch there. With introducing of
shared coprocessor framework system would need more mmio ranges, and
dynamic data structure fast search capable looks good to fit their
needs.
I assume Julien did not consider rangesets for ARM mmio managing 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

2017-02-16 Thread Andrii Anisov

Dear Jan,

> If this is meant to be per-domain management - how many such
> ranges do you expect to be necessary for any one domain? We've
> had attempts before to (ab)use rangesets for such a purpose.
It is meant to be the per-domain management. To handle per-domain
vcoproc register 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 Beulich <jbeul...@suse.com>:
>>>> On 16.02.17 at 13:45, <andrii.ani...@gmail.com> wrote:
>> Dear Paul,
>>
>>> The cleanup seems a good thing to do to me.
>>
>> So I would collect comments, rebase it to latest master and push the
>> second version without RFC.
>>
>>> Any particular reason this series is RFC?
>>
>> The reason to make this series was an intention to use rangesets to
>> manage mmio ranges in our shared coprocessor framework.
>
> If this is meant to be per-domain management - how many such
> ranges do you expect to be necessary for any one domain? We've
> had attempts before to (ab)use rangesets for such a purpose.
>
>> It was planned
>> to extend range with `void* priv` to extend functionality.
>> Unfortunately the rangeset feature to merge ranges makes it unusable
>> for our needs. Also linked list, even sorted, is not really good in
>> search.
>
> This concern makes me assume there might be quite many of them,
> which then makes this a no-go for unprivileged domains.
>
> Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

Dear Paul,

> The cleanup seems a good thing to do to me.

So I would collect comments, rebase it to latest master and push the
second version without RFC.

> Any particular reason this series is RFC?

The reason to make this series was an intention to use rangesets to
manage mmio ranges in our shared coprocessor framework. It was planned
to extend range with `void* priv` to extend functionality.
Unfortunately the rangeset feature to merge ranges makes it unusable
for our needs. Also linked list, even sorted, is not really good in
search.
Another concern was how community react on the 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

2017-02-16 Thread Andrii Anisov

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 Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

>> +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.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

> 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>:
>> -Original Message-
>> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
>> Sent: 16 February 2017 13:24
>> To: Paul Durrant <paul.durr...@citrix.com>
>> Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew
>> Cooper <andrew.coop...@citrix.com>; George Dunlap
>> <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>;
>> jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; Tim
>> (Xen.org) <t...@xen.org>; Wei Liu <wei.l...@citrix.com>
>> Subject: Re: [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?
>
> The relevant patch is:
>
> https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html
>
>   Paul
>
>>
>> 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

2017-02-16 Thread Andrii Anisov

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
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

Dear Paul,

>> It is still left a rangesets list functionality: rangeset_destroy()
>> will remove itself from a list. If a spinlock is provided it will be
>> held for list deletion operation. This would be reconsidered further.
>>
>
> Maybe use the same scheme in patch #1 then and pass the lock, as well as the 
> list_head, into rangeset_new().
Initialized list head in patch#1 is provided by rangeset to user if
user needs it to link to some list. So user should do the locking on
tree insert if it needs. Here rangeset user can not acquire the tree
head 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-02-16 14:26 GMT+02:00 Paul Durrant <paul.durr...@citrix.com>:
>> -Original Message-
>> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
>> Sent: 16 February 2017 12:03
>> To: xen-de...@lists.xenproject.org
>> Cc: andrii_ani...@epam.com; Andrew Cooper
>> <andrew.coop...@citrix.com>; George Dunlap
>> <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>;
>> jbeul...@suse.com; konrad.w...@oracle.com; Paul Durrant
>> <paul.durr...@citrix.com>; sstabell...@kernel.org; Tim (Xen.org)
>> <t...@xen.org>; Wei Liu <wei.l...@citrix.com>
>> Subject: [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 provided it will be
>> held for list deletion operation. This would be reconsidered further.
>>
>
> Maybe use the same scheme in patch #1 then and pass the lock, as well as the 
> list_head, into rangeset_new().
>
>   Paul
>
>> Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
>> ---
>>  xen/arch/x86/hvm/ioreq.c   |  2 +-
>>  xen/arch/x86/mm/p2m.c  |  2 +-
>>  xen/common/domain.c|  5 +
>>  xen/common/rangeset.c  | 15 ---
>>  xen/include/xen/domain.h   |  3 +++
>>  xen/include/xen/rangeset.h |  9 ++---
>>  6 files changed, 24 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
>> index 6df191d..6ae5921 100644
>> --- a/xen/arch/x86/hvm/ioreq.c
>> +++ b/xen/arch/x86/hvm/ioreq.c
>> @@ -496,7 +496,7 @@ static void hvm_ioreq_server_free_rangesets(struct
>> hvm_ioreq_server *s,
>>  return;
>>
>>  for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
>> -rangeset_destroy(s->range[i]);
>> +domain_rangeset_destroy(s->range[i], s->domain);
>>  }
>>
>>  static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 46301ad..d39c093 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain
>> *d)
>>
>>  if ( p2m )
>>  {
>> -rangeset_destroy(p2m->logdirty_ranges);
>> +domain_rangeset_destroy(p2m->logdirty_ranges, d);
>>  p2m_free_one(p2m);
>>  d->arch.p2m = NULL;
>>  }
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 1b9bc3c..f03a032 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct
>> domain *d, char *name,
>>  return r;
>>  }
>>
>> +void domain_rangeset_destroy(struct domain *d,
>> +struct rangeset *r)
>> +{
>> +rangeset_destroy(r, >rangesets_lock);
>> +}
>>
>>
>>  /*
>> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
>> index 478d232..1172950 100644
>> --- a/xen/common/rangeset.c
>> +++ b/xen/common/rangeset.c
>> @@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name,
>> unsigned int flags,
>>  }
>>
>>  void rangeset_destroy(
>> -struct rangeset *r)
>> +struct rangeset *r, spinlock_t *lock)
>>  {
>>  struct range *x;
>>
>>  if ( r == NULL )
>>  return;
>>
>> -if ( r->domain != NULL )
>> -{
>> -spin_lock(&

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

2017-02-16 Thread Andrii Anisov

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 reconsidered
further.

Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 xen/arch/x86/domain.c  |  2 +-
 xen/arch/x86/hvm/ioreq.c   |  4 ++--
 xen/arch/x86/mm/p2m.c  |  4 ++--
 xen/arch/x86/setup.c   |  4 ++--
 xen/common/domain.c| 22 --
 xen/common/rangeset.c  | 12 
 xen/include/xen/domain.h   |  3 +++
 xen/include/xen/rangeset.h | 19 +++
 8 files changed, 45 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index eae643f..93f18d7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -630,7 +630,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 d->arch.x86_model  = boot_cpu_data.x86_model;
 
 d->arch.ioport_caps = 
-rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
+domain_rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
 rc = -ENOMEM;
 if ( d->arch.ioport_caps == NULL )
 goto fail;
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 88071ab..6df191d 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -520,8 +520,8 @@ static int hvm_ioreq_server_alloc_rangesets(struct 
hvm_ioreq_server *s,
 if ( rc )
 goto fail;
 
-s->range[i] = rangeset_new(s->domain, name,
-   RANGESETF_prettyprint_hex);
+s->range[i] = domain_rangeset_new(s->domain, name,
+  RANGESETF_prettyprint_hex);
 
 xfree(name);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6a45185..46301ad 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -122,8 +122,8 @@ static int p2m_init_hostp2m(struct domain *d)
 
 if ( p2m )
 {
-p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
-RANGESETF_prettyprint_hex);
+p2m->logdirty_ranges = domain_rangeset_new(d, "log-dirty",
+   RANGESETF_prettyprint_hex);
 if ( p2m->logdirty_ranges )
 {
 d->arch.p2m = p2m;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b130671..69a961c 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1419,8 +1419,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 /* Low mappings were only needed for some BIOS table parsing. */
 zap_low_mappings();
 
-mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
-  RANGESETF_prettyprint_hex);
+mmio_ro_ranges = rangeset_new("r/o mmio ranges",
+  RANGESETF_prettyprint_hex, NULL);
 
 init_apic_mappings();
 
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 3abaca9..1b9bc3c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -329,8 +329,8 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 rangeset_domain_initialise(d);
 init_status |= INIT_rangeset;
 
-d->iomem_caps = rangeset_new(d, "I/O Memory", RANGESETF_prettyprint_hex);
-d->irq_caps   = rangeset_new(d, "Interrupts", 0);
+d->iomem_caps = domain_rangeset_new(d, "I/O Memory", 
RANGESETF_prettyprint_hex);
+d->irq_caps   = domain_rangeset_new(d, "Interrupts", 0);
 if ( (d->iomem_caps == NULL) || (d->irq_caps == NULL) )
 goto fail;
 
@@ -1537,6 +1537,24 @@ int continue_hypercall_on_cpu(
 return 0;
 }
 
+struct rangeset *domain_rangeset_new(struct domain *d, char *name,
+ unsigned int flags)
+{
+struct list_head *head;
+struct rangeset *r = rangeset_new(name, flags, );
+
+if ( d != NULL )
+{
+spin_lock(>rangesets_lock);
+list_add(head, >rangesets);
+spin_unlock(>rangesets_lock);
+}
+
+return r;
+}
+
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..478d232 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -322,8 +322,8 @@ bool_t rangeset_is_empty(
 return ((r == NULL) || list_empty(>range_list));
 }
 
-struct rangeset *rangeset_new(
-struct domain *d, char *name, unsigned int flags)
+struct rangeset *rangeset_new(char *name, unsigned int flags,
+  struct list_head **head)
 {
 struct rangeset *r;
 
@@ -347,12 +347,8 @@ struct rangeset *rangeset_new(
 snprintf(r->name, sizeof(r-

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

2017-02-16 Thread Andrii Anisov

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 provided it will be
held for list deletion operation. This would be reconsidered further.

Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 xen/arch/x86/hvm/ioreq.c   |  2 +-
 xen/arch/x86/mm/p2m.c  |  2 +-
 xen/common/domain.c|  5 +
 xen/common/rangeset.c  | 15 ---
 xen/include/xen/domain.h   |  3 +++
 xen/include/xen/rangeset.h |  9 ++---
 6 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 6df191d..6ae5921 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -496,7 +496,7 @@ static void hvm_ioreq_server_free_rangesets(struct 
hvm_ioreq_server *s,
 return;
 
 for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
-rangeset_destroy(s->range[i]);
+domain_rangeset_destroy(s->range[i], s->domain);
 }
 
 static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server *s,
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 46301ad..d39c093 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
 
 if ( p2m )
 {
-rangeset_destroy(p2m->logdirty_ranges);
+domain_rangeset_destroy(p2m->logdirty_ranges, d);
 p2m_free_one(p2m);
 d->arch.p2m = NULL;
 }
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1b9bc3c..f03a032 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct domain *d, 
char *name,
 return r;
 }
 
+void domain_rangeset_destroy(struct domain *d,
+struct rangeset *r)
+{
+rangeset_destroy(r, >rangesets_lock);
+}
 
 
 /*
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 478d232..1172950 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name, unsigned int 
flags,
 }
 
 void rangeset_destroy(
-struct rangeset *r)
+struct rangeset *r, spinlock_t *lock)
 {
 struct range *x;
 
 if ( r == NULL )
 return;
 
-if ( r->domain != NULL )
-{
-spin_lock(>domain->rangesets_lock);
-list_del(>rangeset_list);
-spin_unlock(>domain->rangesets_lock);
-}
+if ( lock )
+spin_lock(lock);
+
+list_del(>rangeset_list);
+
+if ( lock )
+spin_unlock(lock);
 
 while ( (x = first_range(r)) != NULL )
 destroy_range(r, x);
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index cd62e6e..3d9c652 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -111,4 +111,7 @@ void vnuma_destroy(struct vnuma_info *vnuma);
 struct rangeset *domain_rangeset_new(struct domain *d, char *name,
  unsigned int flags);
 
+void domain_rangeset_destroy(struct domain *d,
+struct rangeset *r);
+
 #endif /* __XEN_DOMAIN_H__ */
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 395ba62..deed54d 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -14,6 +14,7 @@
 
 struct domain;
 struct list_head;
+struct spinlock;
 struct rangeset;
 
 /*
@@ -37,11 +38,13 @@ struct rangeset *rangeset_new(char *name, unsigned int 
flags,
   struct list_head **head);
 
 /*
- * Destroy a rangeset. It is invalid to perform any operation on a rangeset @r
+ * Destroy a rangeset. Rangeset will take an action to remove itself from a
+ * list. If a spinlock is provided it will be held during list deletion
+ * operation.
+ * It is invalid to perform any operation on a rangeset @r
  * after calling rangeset_destroy(r).
  */
-void rangeset_destroy(
-struct rangeset *r);
+void rangeset_destroy(struct rangeset *r, struct spinlock *lock);
 
 /*
  * Set a limit on the number of ranges that may exist in set @r.
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

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 Anisov (6):
  rangeset_new() refactoring
  rangeset_destroy() refactoring
  Drop rangeset_domain_initialise()
  rangeset_domain_destroy() refactoring
  rangeset_domain_printk() refactoring
  Drop domain remains from rangeset

 xen/arch/x86/domain.c  |  2 +-
 xen/arch/x86/hvm/ioreq.c   |  6 ++---
 xen/arch/x86/mm/p2m.c  |  6 ++---
 xen/arch/x86/setup.c   |  4 +--
 xen/common/domain.c| 48 +++
 xen/common/keyhandler.c|  2 +-
 xen/common/rangeset.c  | 63 +++---
 xen/include/xen/domain.h   |  9 +++
 xen/include/xen/rangeset.h | 42 +++
 9 files changed, 102 insertions(+), 80 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

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|  4 ++--
 xen/common/rangeset.c  | 11 ---
 xen/include/xen/rangeset.h |  9 ++---
 3 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7fe69c6..47c45f2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,7 +420,7 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 radix_tree_destroy(>pirq_tree, free_pirq_struct);
 }
 if ( init_status & INIT_rangeset )
-rangeset_domain_destroy(d);
+rangeset_list_destroy(>rangesets);
 if ( init_status & INIT_watchdog )
 watchdog_domain_destroy(d);
 if ( init_status & INIT_xsm )
@@ -815,7 +815,7 @@ static void complete_domain_destroy(struct rcu_head *head)
 
 watchdog_domain_destroy(d);
 
-rangeset_domain_destroy(d);
+rangeset_list_destroy(>rangesets);
 
 sched_destroy_domain(d);
 
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 1a13a32..a8b5a5d 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -381,20 +381,17 @@ void rangeset_limit(
 r->nr_ranges = limit;
 }
 
-void rangeset_domain_destroy(
-struct domain *d)
+void rangeset_list_destroy(struct list_head *list)
 {
 struct rangeset *r;
 
-while ( !list_empty(>rangesets) )
+while ( !list_empty(list) )
 {
-r = list_entry(d->rangesets.next, struct rangeset, rangeset_list);
+r = list_entry(list->next, struct rangeset, rangeset_list);
 
-BUG_ON(r->domain != d);
-r->domain = NULL;
 list_del(>rangeset_list);
 
-rangeset_destroy(r);
+rangeset_destroy(r, NULL);
 }
 }
 
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index e8244a0..cc795d1 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -18,14 +18,9 @@ struct spinlock;
 struct rangeset;
 
 /*
- * Destroy per-domain rangeset information.
- * 
- * It is invalid to create or destroy a rangeset belonging to a domain @d
- * before rangeset_domain_initialise(d) returns or after calling
- * rangeset_domain_destroy(d).
+ * Destroy a list of rangesets.
  */
-void rangeset_domain_destroy(
-struct domain *d);
+void rangeset_list_destroy(struct list_head *list);
 
 /*
  * Create a rangeset. Optionally attach to a specified list @head.
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

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/common/keyhandler.c|  2 +-
 xen/common/rangeset.c  | 15 +++
 xen/include/xen/domain.h   |  3 +++
 xen/include/xen/rangeset.h |  4 ++--
 5 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 47c45f2..9b68e2f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1560,6 +1560,20 @@ void domain_rangeset_destroy(struct domain *d,
 rangeset_destroy(r, >rangesets_lock);
 }
 
+void domain_rangeset_printk(
+struct domain *d)
+{
+printk("Rangesets belonging to domain %u:\n", d->domain_id);
+
+spin_lock(>rangesets_lock);
+
+if ( list_empty(>rangesets) )
+printk("None\n");
+
+rangeset_list_printk(>rangesets);
+
+spin_unlock(>rangesets_lock);
+}
 
 /*
  * Local variables:
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 16de6e8..4f237f0 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -320,7 +320,7 @@ static void dump_domains(unsigned char key)
 
 arch_dump_domain_info(d);
 
-rangeset_domain_printk(d);
+domain_rangeset_printk(d);
 
 dump_pageframe_info(d);
 
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index a8b5a5d..c18fb21 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -455,26 +455,17 @@ void rangeset_printk(
 read_unlock(>lock);
 }
 
-void rangeset_domain_printk(
-struct domain *d)
+void rangeset_list_printk(
+struct list_head *list)
 {
 struct rangeset *r;
 
-printk("Rangesets belonging to domain %u:\n", d->domain_id);
-
-spin_lock(>rangesets_lock);
-
-if ( list_empty(>rangesets) )
-printk("None\n");
-
-list_for_each_entry ( r, >rangesets, rangeset_list )
+list_for_each_entry ( r, list, rangeset_list )
 {
 printk("");
 rangeset_printk(r);
 printk("\n");
 }
-
-spin_unlock(>rangesets_lock);
 }
 
 /*
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 3d9c652..b2dca15 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -114,4 +114,7 @@ struct rangeset *domain_rangeset_new(struct domain *d, char 
*name,
 void domain_rangeset_destroy(struct domain *d,
 struct rangeset *r);
 
+void domain_rangeset_printk(
+struct domain *d);
+
 #endif /* __XEN_DOMAIN_H__ */
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index cc795d1..8fd8164 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -81,8 +81,8 @@ void rangeset_swap(struct rangeset *a, struct rangeset *b);
 /* Rangeset pretty printing. */
 void rangeset_printk(
 struct rangeset *r);
-void rangeset_domain_printk(
-struct domain *d);
+void rangeset_list_printk(
+struct list_head *list);
 
 #endif /* __XEN_RANGESET_H__ */
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

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
index c18fb21..857615b 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -19,9 +19,8 @@ struct range {
 };
 
 struct rangeset {
-/* Owning domain and threaded list of rangesets. */
+/* threaded list of rangesets. */
 struct list_head rangeset_list;
-struct domain   *domain;
 
 /* Ordered list of ranges contained in this set, and protecting lock. */
 struct list_head range_list;
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index 8fd8164..8462071 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -12,7 +12,6 @@
 
 #include 
 
-struct domain;
 struct list_head;
 struct spinlock;
 struct rangeset;
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

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/common/rangeset.c  | 7 ---
 xen/include/xen/rangeset.h | 4 +---
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index f03a032..7fe69c6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -326,7 +326,8 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 d->disable_migrate = 1;
 }
 
-rangeset_domain_initialise(d);
+INIT_LIST_HEAD(>rangesets);
+spin_lock_init(>rangesets_lock);
 init_status |= INIT_rangeset;
 
 d->iomem_caps = domain_rangeset_new(d, "I/O Memory", 
RANGESETF_prettyprint_hex);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 1172950..1a13a32 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -381,13 +381,6 @@ void rangeset_limit(
 r->nr_ranges = limit;
 }
 
-void rangeset_domain_initialise(
-struct domain *d)
-{
-INIT_LIST_HEAD(>rangesets);
-spin_lock_init(>rangesets_lock);
-}
-
 void rangeset_domain_destroy(
 struct domain *d)
 {
diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
index deed54d..e8244a0 100644
--- a/xen/include/xen/rangeset.h
+++ b/xen/include/xen/rangeset.h
@@ -18,14 +18,12 @@ struct spinlock;
 struct rangeset;
 
 /*
- * Initialise/destroy per-domain rangeset information.
+ * Destroy per-domain rangeset information.
  * 
  * It is invalid to create or destroy a rangeset belonging to a domain @d
  * before rangeset_domain_initialise(d) returns or after calling
  * rangeset_domain_destroy(d).
  */
-void rangeset_domain_initialise(
-struct domain *d);
 void rangeset_domain_destroy(
 struct domain *d);
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-16 Thread Andrii Anisov

> What use are rangesets if the implementation doesn't control the list/tree? 
> How on earth would you implement an allocation function otherwise?
Just to be on the same page, my understanding of the rangesets is as following:

 - Currently the `struct rangeset` is a list of `ranges`. This list
head is a `range_list` of `struct rangeset`. Currently `range_list`
manipulations are not protected by any locks. IMO this is the core
functionality of the rangeset.

 - Also there is another list head `rangeset_list` inside `struct
rangeset`. It is used to link a rangeset to an external 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

2017-01-18 Thread Andrii Anisov

Stefano,

About this piece:

>
> -   if (__generic_dma_ops(dev)->get_sgtable)
> +
> +   if (__generic_dma_ops(dev)->get_sgtable) {
> +   /* We can't handle foreign pages here. */
> +#ifdef CONFIG_ARM
> +   unsigned long bfn = dma_to_pfn(dev, handle);
> +#else
> +   unsigned long bfn = handle >> PAGE_SHIFT;
> +#endif
> +   BUG_ON (!page_is_ram(bfn));
> return __generic_dma_ops(dev)->get_sgtable(dev, sgt, 
> cpu_addr, handle,
>  size, attrs);
> +   }
> return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
>  }


Would it be in drivers/xen/swiotlb-xen.c as you suggested, the whole
"if (__generic_dma_ops(dev)->get_sgtable) {}" should be under ifdef.

IMO 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

2017-01-18 Thread Andrii Anisov


Dear Stefano,


> Only one suggestion more. For this to work correctly, we are assuming
> that no foreging pages are involved here, which is a very reasonable
> assumption given that mmap should be called on memory returned by
> dma_alloc_coherent.

I also kept in mind this problem, that's why the first version was RFC.

> Please add an in-code comment here so that we'll remember.

Do you think comment would be enough so far?
Maybe fallback to common ops would be better in order to keep current (even 
broken) functionality for now? Or BUG_ON as you suggested for get_sgtable 
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.epam.com>



CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) 
to which it is addressed and contains information that is legally privileged 
and confidential. If you are not the intended recipient, or the person 
responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. All unintended recipients are obliged to 
delete this message and destroy any printed copies.


From: Stefano Stabellini <sstabell...@kernel.org>
Sent: Tuesday, January 17, 2017 12:56:12 AM
To: Stefano Stabellini
Cc: Andrii Anisov; xen-de...@lists.xenproject.org; Andrii Anisov; 
julien.gr...@arm.com; konrad.w...@oracle.com; Stefano Stabellini; Oleksandr 
Dmytryshyn
Subject: Re: [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Mon, 16 Jan 2017, Stefano Stabellini wrote:
> On Mon, 16 Jan 2017, Andrii Anisov wrote:
> > 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>
> > Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
> > ---
> >  arch/arm/xen/mm.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> > index bd62d94..ff812a2 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -163,6 +163,19 @@ bool xen_arch_need_swiotlb(struct device *dev,
> >  !is_device_dma_coherent(dev));
> >  }
> >
> > +/*
> > + * Create userspace mapping for the DMA-coherent memory.
> > + */
> > +static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct 
> > *vma,
> > +void *cpu_addr, dma_addr_t dma_addr, size_t size,
> > +unsigned long attrs)
> > +{

Only one suggestion more. For this to work correctly, we are assuming
that no foreging pages are involved here, which is a very reasonable
assumption given that mmap should be called on memory returned by
dma_alloc_coherent.  Please add an in-code comment here so that we'll
remember.


> > +   if (__generic_dma_ops(dev)->mmap)
> > +   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr, 
> > dma_addr, size, attrs);
> > +
> > +   return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
> > +}
> > +
> >  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
> >   unsigned int address_bits,
> >   dma_addr_t *dma_handle)
> > @@ -198,6 +211,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
> >  .unmap_page = xen_swiotlb_unmap_page,
> >  .dma_supported = xen_swiotlb_dma_supported,
> >  .set_dma_mask = xen_swiotlb_set_dma_mask,
> > +   .mmap = xen_swiotlb_dma_mmap,
> >  };
> >
> >  int __init xen_mm_init(void)
>
> The patch should work fine and looks OK. It is better written like this,
> compared to the previous versions that reimplemented dma_common_mmap. I
> like the fact that we are reusing the arm specific generic mmap
> functions via __generic_dma_ops.
>
> For consistency, I would prefer to have xen_swiotlb_dma_mmap in
> drivers/xen/swiotlb-xen.c, even if it needs to be #ifdef'ed CONFIG_ARM
> (at least the __generic_dma_ops calls need to be #ifdef'ed).
>
> Konrad, what do you think?
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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 a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel=139695901430667=4

Changes in V2:
 - patches are rebased and checked for compilation for x86, arm, arm64 with
   the current LK master HEAD 83346fbc07d267de777e2597552f785174ad0373

Andrii Anisov (1):
  swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Stefano Stabellini (1):
  swiotlb-xen: implement xen_swiotlb_dma_mmap callback

 arch/arm/xen/mm.c | 25 +
 1 file changed, 25 insertions(+)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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/arch/arm/xen/mm.c
@@ -176,6 +176,16 @@ static int xen_swiotlb_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 
+static int xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+void *cpu_addr, dma_addr_t handle, size_t size,
+unsigned long attrs)
+{
+   if (__generic_dma_ops(dev)->get_sgtable)
+   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr, 
handle,
+size, attrs);
+   return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 unsigned int address_bits,
 dma_addr_t *dma_handle)
@@ -212,6 +222,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
.mmap = xen_swiotlb_dma_mmap,
+   .get_sgtable = xen_swiotlb_get_sgtable,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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>
Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 arch/arm/xen/mm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index bd62d94..ff812a2 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -163,6 +163,19 @@ bool xen_arch_need_swiotlb(struct device *dev,
!is_device_dma_coherent(dev));
 }
 
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ */
+static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+   if (__generic_dma_ops(dev)->mmap)
+   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr, 
dma_addr, size, attrs);
+
+   return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 unsigned int address_bits,
 dma_addr_t *dma_handle)
@@ -198,6 +211,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+   .mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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 a port of an antique and lost patch discussed here:
http://marc.info/?l=xen-devel=139695901430667=4

Changes in V2:
 - patches are rebased and checked for compilation for x86, arm, arm64 with
   the current LK master HEAD 83346fbc07d267de777e2597552f785174ad0373

Andrii Anisov (1):
  swiotlb-xen: implement xen_swiotlb_get_sgtable callback

Stefano Stabellini (1):
  swiotlb-xen: implement xen_swiotlb_dma_mmap callback

 arch/arm/xen/mm.c | 25 +
 1 file changed, 25 insertions(+)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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/arch/arm/xen/mm.c
@@ -176,6 +176,16 @@ static int xen_swiotlb_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
 }
 
+static int xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
+void *cpu_addr, dma_addr_t handle, size_t size,
+unsigned long attrs)
+{
+   if (__generic_dma_ops(dev)->get_sgtable)
+   return __generic_dma_ops(dev)->get_sgtable(dev, sgt, cpu_addr, 
handle,
+size, attrs);
+   return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 unsigned int address_bits,
 dma_addr_t *dma_handle)
@@ -212,6 +222,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
.mmap = xen_swiotlb_dma_mmap,
+   .get_sgtable = xen_swiotlb_get_sgtable,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-01-16 Thread Andrii Anisov

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>
Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>
---
 arch/arm/xen/mm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index bd62d94..ff812a2 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -163,6 +163,19 @@ bool xen_arch_need_swiotlb(struct device *dev,
!is_device_dma_coherent(dev));
 }
 
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ */
+static int xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+   if (__generic_dma_ops(dev)->mmap)
+   return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr, 
dma_addr, size, attrs);
+
+   return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
 unsigned int address_bits,
 dma_addr_t *dma_handle)
@@ -198,6 +211,7 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
.unmap_page = xen_swiotlb_unmap_page,
.dma_supported = xen_swiotlb_dma_supported,
.set_dma_mask = xen_swiotlb_set_dma_mask,
+   .mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2017-02-27 Thread Andrii Anisov


Dear George,


Actually r8a7796 and r8a7795 are different chips with different 
peripherals, so you should adjust your r8a7796-xxx.dtb.


I'm not really sure what the problem is with XEN 4.6, but the crash 
point you are stepped in with 4.8 is commented as following


/*
 * Currently, to ensure hypervisor safety, when we received a
 * guest-generated vSerror/vAbort, we just crash the guest to protect
 * the hypervisor. In future we can better handle this by injecting
 * a vSerror/vAbort to the guest.
 */

So I guess you see the abort on access to a peripheral missing 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...@epam.com>


*Kyiv**,* *Ukraine *(GMT+3)*epam.com <http://www.epam.com>*

CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or 
entity(ies) to which it is addressed and contains information that is 
legally privileged and confidential. If you are not the intended 
recipient, or the person responsible for delivering the message to the 
intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. 
All unintended recipients are obliged to delete this message and destroy 
any printed copies.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [RFC] Shared coprocessor framework

2016-10-28 Thread Andrii Anisov

 support, configs enabling scheduling algorithms, configs
enabling support of the coprocessor platform support.

The system startup configuration will be described in the system device tree
in the xen "choosen" node. The configuration should at least describe which
coprocessors within the system will be shared to the domains, a scheduling
algorithm assigned to each shared coprocessor, and an identificator of this
particular coprocessor instance. Hypervisor will read corresponding nodes and
configure the coprocessor framework with platform implementations on startup.

Domain startup configuration


In a domain configuration file it will be specified which particular instance
of the coprocessor should be shared to this domain.

The shared coprocessor domain configuration should be read by tools/xen and on
domain creation a vcoproc should be created and assigned to vcoproc instances
list of the particular coprocessor. Starting from here it is assumed that
vcoproc is ready to be scheduled as soon as domain starts using it.

In case of failure of vcoproc creation, the domain creation should be aborted.

Runtime configuration of scheduling algorithm per instance of shared

coprocessor
---

There will be a initial domain tool implemented which will provide a CLI for
runtime monitoring of shared coprocessors instances available, per-domain/
per-coproc instance list of vcoproc and runtime setup of the scheduler per
each coprocessor instance.

Integration of different coprocessor support implementation
---

The coprocessor sharing framework is a platform independent entity which
implements generic flows and actions. It does need platform specific hooks
which implement exact coprocessor management operations.
The coprocessor platform specific implementations will provide:
* domain create/destroy hooks
* context switch hooks (coprocessor start, stop, context load/save)
* iomem handler(s)
* interrupt handler(s)

Integration of different scheduling algorithms implementation
-

There are number of possible coprocessor sharing scenarios with different
needs of coprocessor resources allocation for different domains. Within
current design the coprocessor resource allocation to domains is a matter of
scheduling algorithm and its configuration. The framework will use the
scheduling algorithm to determine if context switching should be done and what
is the next vcoproc to be ran on coprocessor.

The algorithm impelementation will provide:
* initialization/deinitialization hooks
* scheduling operations hooks

(Optional) The coprocessor firmware and drivers should not be changed in order
--
to support the sharing.
---

This requirement could be compromised for implementations which support
coprocessors not designed for externally issued context 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

2016-11-08 Thread Andrii Anisov

Dirk,

IuriiK did great work at the beginning of the summer to bringup XEN on
Salvator-X in a short term.
Due to different reasons it was a bit hacky and was not exposed here,
but you can find the stuff here:
https://github.com/qbeeukraine/meta-platform-xen. I'm not really sure
if the final code 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

2016-11-08 Thread Andrii Anisov

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 all,
>
> I would like to start organizing a recurring community call to discuss and
> sync-up on upcoming features for Xen ARM.
>
> Example of features that could be discussed:
> - Sharing co-processor between guests
> - PCI passthrough
>
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.
>
> Your sincerely,
>
> --
> Julien Grall

___
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

2016-11-11 Thread Andrii Anisov

Sorry for the late intrusion into this discussion. I would introduce my
vision of the issues behind the 32 bits addressing DMA controllers in
ARMv7/v8 SoCs.

On AArch64 SoCs, some IPs may only have the capability to access
> 32 bits address space. The physical memory assigned for Dom0 maybe
> not in 4GB address space, then the IPs will not work properly.
> So need to allocate memory under 4GB for Dom0.
>
IMHO that is a wrong approach. Unfortunately the problem is much bigger.
Normally you would need to run guest domains as well. With at least PV
Block and PV NET drivers. Due to the fact that PV drivers made in a way
that DMA controller at last will work with DomU's pages, those pages should
be from below 4GB.
So any DomU running PV drivers should have some amount of pages from below
4GB. Moreover, the OS running in DomU should be knowing that only those
pages are DMA-able, and that PV drivers should be working with DMA-able
pages only: I.e. pages should be mapped correspondingly into different
banks under and over 4GB.

The approach, I believe is more suitable, is to specify explicitly an
amount of RAM below 4GB and above 4GB for any domain. For dom0 through xen
command line, for domU through domain configuration file.

Such approach was implemented by GL. You can find preliminary patches over
here: https://lists.xen.org/archives/html/xen-devel/2016-05/msg01785.html
https://lists.xen.org/archives/html/xen-devel/2016-05/msg01786.html .
I really hope GL will decide to tailor and upstream the feature.

I am undecided whether this should be considered as a bug fix for Xen 4.8.
> Are you aware of any ARM64 platform we currently support requiring
> allocation of memory below 4GB?

That is not only ARM64 problem. Any ARMv7/v8 based platform having 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

2016-11-11 Thread Andrii Anisov

Sorry for a confusion.

The sentence:
> Also it does answer to the next question:
should be typed as:
> Also it does NOT answer to the next question:

> > The guest should be IPA agnostic and not care how the physical device is 
> > working when using PV drivers. So for me,
> > 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 understanding of what you say, the problem is not because domU is 
> > using memory above 4GB but the fact that >the backend driver does not take 
> > the right decision
>
> Yep, the problem could be treated in such a way.
>
> > (e.g using bounce buffer when required).
> I suppose unacceptable performance drop for such kind of solution.
>
> An alternative here could be reverting of the FE-BE interaction scheme
> in a following way: BE side domain provides buffers and maps them to
> the FE side domain. Some time ago we estimated this approach as huge
> architecture change and enormous implementation efforts. Also it does
> answer to the next question:
>
> > The guest should be IPA agnostic and not care how the physical device is 
> > working when using PV drivers. So for me,
> > this should be fixed in the DOM0 OS.
> Do you consider 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

2016-11-11 Thread Andrii Anisov

Hello Julien,

Please see my comments below:

> From my understanding of what you say, the problem is not because domU is 
> using memory above 4GB but the fact that >the backend driver does not take 
> the right decision

Yep, the problem could be treated in such a way.

> (e.g using bounce buffer when required).
I suppose unacceptable performance drop for such kind of solution.

An alternative here could be reverting of the FE-BE interaction scheme
in a following way: BE side domain provides buffers and maps them to
the FE side domain. Some time ago we estimated this approach as huge
architecture change and enormous implementation efforts. Also it does
answer to the next question:

> The guest should be IPA agnostic and not care how the physical device is 
> working when using PV drivers. So for me,
> this should be fixed in the DOM0 OS.
Do you consider 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

2016-11-14 Thread Andrii Anisov

> Could you define unacceptable performance drop? Have you tried to measure
> what would be the impact?

> I know it can be bad, depending on the class of protocols. I think that
> if numbers were provided to demonstrate that bounce buffers (the swiotlb
> in Linux) are too slow for a given use case

Unfortunately I could not come up with exact requirements numbers.
Introducing another memcpy (what bouncing buffer approach does) for
block or network IO would not only reduce the operation performance
but also increase the overall system load.
All what we does for any of our PV driver 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

2016-11-14 Thread Andrii Anisov

> 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 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

2016-11-14 Thread Andrii Anisov

> There are many reasons: for example because you want Dom0 to be Linux
> and the storage driver domain to be FreeBSD. Or because you want the
> network driver domain to be QNX.
What we estimate now is a thin Dom0 without any drivers running with
ramdisk. All drivers would be moved to 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

2016-11-14 Thread Andrii Anisov

> 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.

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] XEN tools for ARM64 build issue

2016-11-23 Thread Andrii Anisov

Dear all,

Building latest XEN master branch
(58bd0c7985890e0292212f94a56235228a3445c3) for salvator-x platform using
the same yocto as here
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I've
faced following issue:

Maximum error count (200) exceeded

/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
 3: OperationRegion ( MSUM, SystemMemory, \_SB.MSUA, 1 )
Error4084 -

 Object does not exist ^  (\_SB.MSUA)
/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
 8: If ( LLess(Arg0, NCPU) ) {
Error4084 -

   Object does not exist ^  (NCPU)
/home/aanisov/DEV/salvatorx-new/build/tmp/work/aarch64-poky-linux/xen/4.8.0+gitAUTOINC+58bd0c7985-r0/git/tools/libxl/dsdt_anycpu_arm.asl
16: OperationRegion ( MATR, SystemMemory, Add(\_SB.MAPA,
0), 8 )
Error4084 -

 Object does not exist ^  (\_SB.MAPA)

See attached full log [log.do_compile.14752.tbz2].
The original yocto adopts iasl 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-compressed-tar


log.do_compile.18488.tbz2
Description: application/bzip-compressed-tar
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2016-11-23 Thread Andrii Anisov

> 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.org
https://lists.xen.org/xen-devel

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

2016-11-23 Thread Andrii Anisov

> But before you write any code, let me try to understand the real issue
> first: you're trying to cross-build ARM tools on x86, but x86
> iasl doesn't support ARM ACPI definition(s), right?
Well, as I stated here [1], I'm pretty far from ACPI and understanding
of what's going 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://lists.xen.org/xen-devel

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

2016-11-23 Thread Andrii Anisov

Iurii,

About the 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.

Please review this [1] thread.

[1] https://lists.xenproject.org/archives/html/xen-devel/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

2016-11-23 Thread Andrii Anisov

Stefano,

Please see my answers below:
>
> Thank you for the document, I think is a very good start. I also see the
> need for this framework. Please add more details about the proposed
> interface (Xen API, hypercalls, etc) in the next version; I am looking
> forward to it.

We will come up with the document update once we have it agreed internally.

>> 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 
>> access.
>
> This is certainly going to be the hardest part. I take the framework is
> just going to provide a generic API for implementing a coprocessor
> emulator and it is going to be up to each coprocessor implementation to
> provide the code.

This piece together with the context switching logic is definitely a
platform specific stuff and its complexity could be different
coprocessor to coprocessor.
Registers access emultaion for not running vcopro is expected to be
not very complex for our case:
- saved context return on register read
- stacking on writes to be executed during switching context to that vcoproc
- rare more complex corner cases

> Is the emulator going to live in the Xen hypervisor?
That is the idea.

> It would be nice to provide a simple coprocessor example, 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.

2016-11-23 Thread Andrii Anisov

> It is defined in config/arm64.mk, which is included by various
> makefiles.
As I got, it is included by Config.mk which consequently included by
different makefiles in hypervisor, tools, docs, stubdom.
It looks like a piece of legasy configuration code, I see moves of
CONFIG_ options 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,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2016-11-23 Thread Andrii Anisov

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/Makefile
index f5053a0..a4e9319 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -90,7 +90,7 @@ acpi:
 
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
-ifeq ($(CONFIG_ARM_64),y)
+ifeq ($(CONFIG_ACPI),y)
 DSDT_FILES-y = dsdt_anycpu_arm.c
 LIBXL_OBJS-y += libxl_arm_acpi.o $(patsubst %.c,%.o,$(DSDT_FILES-y))
 dsdt_anycpu_arm.c:
-- 
2.7.4


___
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.

2016-11-23 Thread Andrii Anisov

> 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

2016-11-23 Thread Andrii Anisov

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.


On Wed, Nov 23, 2016 at 4:00 PM, Iurii Mykhalskyi
<iurii.mykhals...@globallogic.com> wrote:
> Dear all,
>
> Andrii, thanks for the remark - I'll rework this patch.
>
> Julien, I have updated yocto layer [1] to use the most recent stable Xen
> version - Xen 4.8-rc6
>
> Looks like used patches for Xen should be described more briefly:
> 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
> console introduction for Salvator-X board

> 3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
> compilation issue on arm64 platform. Looks like Andrii faces same problem
> [3] [4].
> 4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
> essential, but xsm might be usefull for some use-cases.
> 5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
> Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
> Dom0 will be allocated at over 4GB space - DMA operation will fail.
> According to xen-devel list [5], this patch planned to be included in
> Xen 4.9.
> 6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
> but by default Xen traps such calls, so we have to allow such actions.
>
> [1] https://github.com/qbeeukraine/meta-platform-xen
> [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
> [3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
> [4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
> [5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html
>
> In last email you have written:
>> Also, it is not clear to me why you need a specific device tree and hacked
>> DOM0 linux (see [2]) on this board for Xen. This would need some
>> documentation on the wiki.
>
> Yes, this need some explanation. I'll update related wiki page in few hours.
>
> Thanks for all of your comments.
>
> With the best regards,
> Iurii Mykhalskyi
>
>
>
> On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov <andrii.ani...@gmail.com>
> wrote:
>>
>> Well,
>>
>> > 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-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> > Is a total mess.
>> It seems you've lost some code and related history during porting the
>> original 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-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>>> arch_fixup_fdt() function, which, as per you idea, is not needed to be built
>>> for the XEN boot. You have no patch lines to introduce CONFIG_XEN so the
>>> code works.
>>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>>> to drop whole the function.
>>>
>>> But the problem in that piece of code still exists:
>>>
>>> u-boot updates the first memory node in the dtb with all memory banks it
>>> found in the board code, does not take into consideration other memory nodes
>>> as a result memory banks in device tree are duplicated
>>> unlike the kernel which tolerates that mess from u-boot, XEN does not
>>> accept 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.
>>>
>>
>
>
>
> --
>
> Iurii Mykhalskyi | Senior Software Engineer
> GlobalLogic
> P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

___
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.

2016-11-23 Thread Andrii Anisov

Hello Julien,

> The ACPI support is pretty much contained in a single file and I am not sure 
> you will win much space.
> Can you explain why the ACPI guest support should be optional?
This would increase the system configurability and would let one
shrink a system to a minimal footprint with required functionality
only. Such possibility is very useful in embedded applications.

Unfortunately I don't know the exact space impact of this particular
feature 'cause I can't build it. From other hand I do not need it in
my system. So I would like to have a way to drop not needed
functionality 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

2016-11-23 Thread Andrii Anisov

> I was thinking of something trivial but enough to prove the point.
> Something like a very simple accelerator, maybe a data copy accelerator.
> A GPU is certainly not trivial :-)
Indeed.
But we still have targets to reach and shortage in resources to spread
over simple examples ;)

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

2016-11-22 Thread Andrii Anisov

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-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
arch_fixup_fdt() function, which, as per you idea, is not needed to be
built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
the code works.
Also arch_fixup_fdt() not only mangles memory nodes, so it is not right to
drop whole the function.

But the problem in that piece of code still exists:

   - u-boot updates the first memory node in the dtb with all memory banks
   it found in the board code, does not take into consideration other memory
   nodes
   - as a result memory banks in device tree are duplicated
   - unlike the kernel which tolerates that mess from u-boot, XEN does not
   accept 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 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

2016-11-22 Thread Andrii Anisov

Well,

> 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-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> Is a total mess.
It seems you've lost some code and related history during porting the
original 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-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
> arch_fixup_fdt() function, which, as per you idea, is not needed to be
> built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
> the code works.
> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right to
> drop whole the function.
>
> But the problem in that piece of code still exists:
>
>- u-boot updates the first memory node in the dtb with all memory
>banks it found in the board code, does not take into consideration other
>memory nodes
>- as a result memory banks in device tree are duplicated
>- unlike the kernel which tolerates that mess from u-boot, XEN does
>not accept 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 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

2016-11-25 Thread Andrii Anisov

Dear Iurii,

It was my mistake:
> 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.

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

2016-11-28 Thread Andrii Anisov

> 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,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2016-11-23 Thread Andrii Anisov

> 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 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.

2016-11-28 Thread Andrii Anisov

Julien,

> There is no automatic test on all the possible configurations, although we 
> have
> travis to test build (and not booting) a random Kconfig.

I guess there is no need to test booting of a "random" Kconfig within
the mainline anyway. The full-featured defconfig would be enough to be
provided by the mainline.

> Even if we try our best to see any problem when reviewing code, we cannot 
> guarantee an error
> when using a different configuration.

From other hand, those who build their solution based on XEN, will
take care about their specific configurations. And get back to the
community with features and fixes if applicable.

> I got bitten quite a few times in my development because I had a binary but
> not the Kconfig.

I think everyone faced similar issues in their experience.

> I might be more inclined to make more feature optional when we will
> have a way to track the configuration of a hypervisor binary.
> +10 to this idea.

Having a .config built into the XEN binary is a cool feature.
But IMO it is useful rather during development time. Knowing a
production system configuration seems to be closer to an integration
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.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2016-11-16 Thread Andrii Anisov

AM> The situation is not as bad as having full-scope driver (which is
AM> implemented in some proprietary hypervisors), we only need to:
AM> 1. stop
AM> 2. flush registers
AM> 3. switch memory context <--- implemented by SMMU in ARM
AM> 4. restore registers
AM> 5. start

Well, 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 access.

Sincerely,
Andrii Anisov.

On Sat, Nov 12, 2016 at 2:04 PM, Artem Mygaiev <jocula...@gmail.com> wrote:
> On Fri, Nov 11, 2016 at 10:43 PM, Konrad Rzeszutek Wilk
> <konrad.w...@oracle.com> wrote:
>> Does this also mean that the hypervisor has to know the co-processors?
>> As in how to start/stop them? And how to tell them to save/restore
>> guest context? Or is there some generic specification for doing this?
>
> Unfortunately there is be no single way to switch context on
> co-processors, so yes, hypervisor has to know the co-processors.
> The situation is not as bad as having full-scope driver (which is
> implemented in some proprietary hypervisors), we only need to:
> 1. stop
> 2. flush registers
> 3. switch memory context <--- implemented by SMMU in ARM
> 4. restore registers
> 5. start
>
> Best regards,
> Artem Mygaiev

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

2016-11-16 Thread Andrii Anisov

> So it looks like there could be an generic API to deal with
> these various operations.

Currently it is designed to be a generic API with platform
(coprocessor) specific hooks.

> And I think you are thinking to hook it up to the scheduler so that when a 
> guest
> switches you can follow with that

If you mean hook with vcpu scheduler then we will not. On an SMP
system it could be running vcpus from different domains at the same
time, so we can not rely on the domain is running.
vcoproc scheduling will be independent from vcpu scheduling.

> But I think the design also mentioned asynchronous jobs so there may be 
> situations
> where there is a doorbell to wake up an guest?
Not really sure I've got the question. Coprocessor generated
interrupts would be routed to the domain which context is running on
the coprocessor at the moment of interrupt.

> But I think in my x86 poisioned PoV mind this is similar to an
> PCIe device that has its own MMU.
I'm sorry, I can not compare. I know a little about the x86 world.

> Which brings some more questions - how do we erect the barriers
> such that this "coprocessor" does not 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", so the framework will take care to switch it.

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

1 2 3 >

1 - 100 of 226 matches

Mail list logo