Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

On 6/22/2015 10:02 PM, Julien Grall wrote: On 22/06/15 12:17, Peng Fan wrote: I add debug log in this piece of code: void __init sanity_check_meminfo(void) { phys_addr_t memblock_limit = 0; int i, j, highmem = 0; phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1; printk

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi, On 6/23/2015 9:36 PM, Julien Grall wrote: Hi, On 23/06/15 14:03, Peng Fan wrote: I did not enable LPAE for DOM0 kernel, use shor page table. Following is the full log from uboot to kernel with DOM0 512M: Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I remembered

[Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi, I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have no clear idea about why Dom0 kernel panic. Detail log see below: U-Boot 2015.04-rc4-00145-gf12a16e (Jun 18 2015 - 10:38:06) CPU: Freescale i.MX7D rev1.0 at 792 MHz CPU: Thermal invalid data, fuse: 0x1b800 CPU:

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi Julien, On 6/20/2015 6:19 PM, Julien Grall wrote: Hi, On 19/06/2015 14:22, Peng Fan wrote: diff --git a/kernel/timer.c b/kernel/timer.c index 38f0d40..4a025cc 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base *base

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi On 6/20/2015 10:08 PM, Peng Fan wrote: Hi Julien, On 6/20/2015 6:19 PM, Julien Grall wrote: Hi, On 19/06/2015 14:22, Peng Fan wrote: diff --git a/kernel/timer.c b/kernel/timer.c index 38f0d40..4a025cc 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1175,6 +1175,10 @@ static

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

On 6/22/2015 6:20 PM, Julien Grall wrote: On 20/06/15 15:47, Peng Fan wrote: On 6/20/2015 10:08 PM, Peng Fan wrote: Hi Julien, On 6/20/2015 6:19 PM, Julien Grall wrote: Hi, On 19/06/2015 14:22, Peng Fan wrote: diff --git a/kernel/timer.c b/kernel/timer.c index 38f0d40..4a025cc 100644

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi Julien, On 6/23/2015 9:56 PM, Peng Fan wrote: Hi, On 6/23/2015 9:36 PM, Julien Grall wrote: Hi, On 23/06/15 14:03, Peng Fan wrote: I did not enable LPAE for DOM0 kernel, use shor page table. Following is the full log from uboot to kernel with DOM0 512M: Which CONFIG_VMSPLIT_* do you

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi, On 6/18/2015 10:54 PM, Ian Campbell wrote: On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote: Hi, I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have no clear idea about why Dom0 kernel panic. Have you confirmed that this same kernel runs reliably natively

[Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

ificant bit of the condition code for each instruction in the block. " So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );" Signed-off-by: Peng Fan <peng@freescale.com> Cc: Ian Campbell <ian.campb...@citrix.com> Cc: Stefano Stabell

[Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional check, but to ARM32, we need to use 'hsr.ec >> 30' to check. Signed-off-by: Peng Fan <peng@freescale.com> Cc: Ian Campbell <ian.campb...@citrix.com> Cc: Stefano Stabellini <stefano.stabe

Re: [Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

On Mon, Sep 21, 2015 at 11:10:11AM +0100, Julien Grall wrote: >Hi Peng, > >On 21/09/15 08:07, Peng Fan wrote: >> From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM >> and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM: >

Re: [Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

Hi Julien, On Mon, Sep 21, 2015 at 10:47:23AM +0100, Julien Grall wrote: >Hi Peng, > >On 21/09/15 08:07, Peng Fan wrote: >> To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional >> check, but to ARM32, we need to use 'hsr.ec >> 30' to check. &

[Xen-devel] Question about arm passthrough and power related

Hi, I am trying to passthrough a platform device to domU, but as we know clk dts property and related code are handled in dom0. If passthrough the platform device to domU, then how the clock for the device. I came across this documentation "How to passthrough your integrated device to a VM on

[Xen-devel] [RFC 1/1] xen: block: correct setting for xen_blkif_max_ring_order

max_ring_order using XENBUS_MAX_RING_GRANT_ORDER, but not 0. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: David Vrabel <david.vra...@citrix.com> Cc: "Roger Pau Monné&

[Xen-devel] [RFC 1/1] xen: interface: correct comments

According to definition of structure evtchn_alloc_unbound, there is an entry "domid_t remote_dom", no "rdom". So using "remote_dom" in comments instead of "rdom". Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Konrad Rzeszutek Wilk <konrad.w

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

Hi Julien, On Mon, May 30, 2016 at 10:53:24PM +0100, Julien Grall wrote: >Hi Peng, > >On 27/05/2016 06:31, Peng Fan wrote: >>To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate >>first level page table, if there is a big chunk memory (ie, >512GB). >

[Xen-devel] [PATCH] xen/arm64: config: correct VMAP_VIRT_END

To ARM64, we should use '(VMAP_VIRT_START + GB(1))' as VMAP_VIRT_END, but not '(VMAP_VIRT_START + GB(1) - 1)'. Seeing 'vm_end[type] = PFN_DOWN(end - start);' in vm_init_type, if not correct VMAP_VIRT_END, one page is wasted. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Julien

[Xen-devel] [PATCH] xen/arm: setup: fix typo

Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Julien Grall <julien.gr...@arm.com> Cc: Stefano Stabellini <sstabell...@kernel.org> --- xen/arch/arm/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x

[Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate first level page table, if there is a big chunk memory (ie, >512GB). So, need to make sure boot pages are ready before setup xenheap mappings. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Julien Grall &

Re: [Xen-devel] [PATCH] xen/arm64: config: correct VMAP_VIRT_END

Hi Julien, On Tue, May 31, 2016 at 12:07:58PM +0100, Julien Grall wrote: >Hi Peng, > >On 27/05/16 11:23, Peng Fan wrote: >>To ARM64, we should use '(VMAP_VIRT_START + GB(1))' as VMAP_VIRT_END, > >s/To/For/ Fix in V2. > >>but not '(VMAP_VIRT_START + GB(1) -

[Xen-devel] [PATCH V2] xen/arm64: config: Correctly define VMAP_VIRT_END

of VMAP_VIRT_END will lead the vmap code to not use the last 4K of the region. Fix it by defining VMAP_VIRT_END as "VMAP_VIRT_START + GB(1)". Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Julien Grall <julien.gr...@arm.com> Cc: Stefano Stabellini <sstabell...@kernel.org> --

Re: [Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

Hi Julien, On Tue, May 31, 2016 at 06:08:38PM +0100, Julien Grall wrote: >Hi Peng, > >On 31/05/16 10:58, Peng Fan wrote: >>> >>>>So, need to make sure boot pages are ready before setup xenheap mappings. >>> >>>init_boot_pages is using mfn_to_vir

[Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

t;ipg" packed into a structure |->notify backend 2. wait_completion Dom0 finished clk_prepare_enable and send event channel interrupt to DomU, In DomU frontend interrupt handler, call complete to wakeup. [1] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

Hello David, On Mon, Jan 18, 2016 at 11:24:08AM +, David Vrabel wrote: >On 16/01/16 05:22, Peng Fan wrote: >> This patch was just a initial patch, not sure whether this way >> is ok from you side for handlding clk when doing platform device >> passhthrough. Any com

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

Hello George, On Mon, Jan 18, 2016 at 11:22:44AM +, George Dunlap wrote: >On Sat, Jan 16, 2016 at 5:22 AM, Peng Fan <van.free...@gmail.com> wrote: >> This patch was just a initial patch, not sure whether this way >> is ok from you side for handlding clk when

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

Hello Ian, On Mon, Jan 18, 2016 at 12:41:59PM +, Ian Campbell wrote: >On Mon, 2016-01-18 at 11:24 +, David Vrabel wrote: >> On 16/01/16 05:22, Peng Fan wrote: >> > This patch was just a initial patch, not sure whether this way >> > is ok from you side for handld

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Wed, Jan 20, 2016 at 07:52:58AM -0700, Jan Beulich wrote: On 20.01.16 at 15:37, wrote: >> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote: >> On 20.01.16 at 15:05, wrote: On Wed, Jan 20, 2016 at 05:01:40AM -0700,

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian, On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote: >On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote: >>  >> To platform device of ARM, hypervisor is responsible for the mapping >> between machine address and guest physical address, also responsible &

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote: On 21.01.16 at 09:59, wrote: >> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm. >> passthrough uart2, hypervisor handles the reg and interrupts, that is >> because >> hypervisor handles the

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian, On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote: >On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote: >> Hi Ian, >> >> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote: >> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote: >

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Thu, Jan 21, 2016 at 12:53:01AM -0700, Jan Beulich wrote: On 21.01.16 at 02:29, wrote: >> The platform device passthrough part for arm is to mapping the machine io >> address >> to the guest physical io address. Then guest can map the phsical io address

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote: On 21.01.16 at 13:06, wrote: >> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote: >> On 21.01.16 at 09:59, wrote: uart2 needs clock IMX7D_UART2_ROOT_CLK

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian, On Thu, Jan 21, 2016 at 12:49:24PM +, Ian Campbell wrote: >On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote: >> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote: >> > Would adding a dummy fixed-clock[0] (or several of them) to the guest >>

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian and Stefano, On Thu, Jan 21, 2016 at 04:11:45PM +, Stefano Stabellini wrote: >On Thu, 21 Jan 2016, Ian Campbell wrote: >> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote: >> > On Thu, 21 Jan 2016, Peng Fan wrote: >> > > Hi Ian, >> >

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote: On 22.01.16 at 02:56, wrote: >> On Thu, Jan 21, 2016 at 05:52:12AM -0700, Jan Beulich wrote: >>>At the very least it would need to be avoided by denying the request. >>>Upon shared use, either all

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Fri, Jan 22, 2016 at 03:25:40AM -0700, Jan Beulich wrote: On 22.01.16 at 10:27, wrote: >> Hi Jan, >> >> On Fri, Jan 22, 2016 at 12:36:31AM -0700, Jan Beulich wrote: >> On 22.01.16 at 02:56, wrote: On Thu, Jan 21, 2016 at

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian, On Thu, Jan 21, 2016 at 12:49:24PM +, Ian Campbell wrote: >On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote: >> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote: >> > Would adding a dummy fixed-clock[0] (or several of them) to the guest >>

[Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

that are passed through from Dom0. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: George Dunlap <george.dun...@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: David Vrabel <david.vra...@citrix.com> Cc: Julien Grall <julien.gr...@citrix.com> Cc: Stefa

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Juergen, On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote: >On 20/01/16 10:25, Peng Fan wrote: >> Hi Juergen, >> >> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote: >>> On 20/01/16 09:31, Peng Fan wrote: >>>> Introduce

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote: On 20.01.16 at 09:31, wrote: >> +/* >> + * Backend response >> + * >> + * cmd: command for operation on clk, same with the cmd in request. >> + * id: clk id, same with the id in request. >> + *

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Juergen, On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote: >On 20/01/16 09:31, Peng Fan wrote: >> Introduce pvclk interface which is useful when doing device passthrough >> on ARM platform. > >... > >> +/* >> + * Frontend request >> +

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote: On 20.01.16 at 15:05, wrote: >> Hi Jan, >> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote: >> On 20.01.16 at 12:40, wrote: Hi Jan, On Wed, Jan

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Ian, Stefano On Wed, Jan 20, 2016 at 12:27:07PM +, Ian Campbell wrote: >On Wed, 2016-01-20 at 12:06 +, Stefano Stabellini wrote: >> On Wed, 20 Jan 2016, Peng Fan wrote: >> > To my use case, Dom0 and DomU both use device tree, I need to build >> > the mappin

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Juergen, On Wed, Jan 20, 2016 at 01:11:39PM +0100, Juergen Gross wrote: >On 20/01/16 12:48, Peng Fan wrote: >> Hi Juergen, >> >> On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote: >>> On 20/01/16 10:25, Peng Fan wrote: >>>> Hi Juergen, &g

Re: [Xen-devel] [RFC V2] xen: interface: introduce pvclk interface

Hi Jan, On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote: On 20.01.16 at 12:40, wrote: >> Hi Jan, >> >> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote: >> On 20.01.16 at 09:31, wrote: +/* + * Backend

Re: [Xen-devel] SMMU, Unhandled context fault

On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote: > > >On 28/04/16 07:39, Peng Fan wrote: >>Hi Julien, > >Hello Peng, > >>On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote: >>>Hi Julien, >>>On Wed, Apr 27, 2016 at 10:5

Re: [Xen-devel] SMMU, Unhandled context fault

Hi Julien, On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote: >Hello, > >On 28/04/16 13:56, Peng Fan wrote: >>On Thu, Apr 28, 2016 at 11:27:22AM +0100, Julien Grall wrote: >>> >>> >>>On 28/04/16 07:39, Peng Fan wrote: >>>>Hi Julien,

Re: [Xen-devel] SMMU, Unhandled context fault

Hi Julien, On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote: >Hello Peng, > >On 27/04/2016 03:02, Peng Fan wrote: >>On Tue, Apr 26, 2016 at 04:30:03PM +0200, Edgar E. Iglesias wrote: >>>On Tue, Apr 26, 2016 at 09:56:33PM +0800, Peng Fan wrote: >>>

Re: [Xen-devel] SMMU, Unhandled context fault

Hi Julien, On Thu, Apr 28, 2016 at 10:37:54AM +0800, Peng Fan wrote: >Hi Julien, >On Wed, Apr 27, 2016 at 10:58:28AM +0100, Julien Grall wrote: >>Hello Peng, >> >>On 27/04/2016 03:02, Peng Fan wrote: >>>On Tue, Apr 26, 2016 at 04:30:03PM +0200, Edgar E. Iglesia

Re: [Xen-devel] [PATCH 2/2] xen/arm64: use shift operator

Hi Julien, On Fri, Apr 22, 2016 at 05:08:26PM +0100, Julien Grall wrote: >On 21/04/16 02:06, Peng Fan wrote: >>Hi Julien, > >Hello Peng, > >>On Wed, Apr 20, 2016 at 03:44:09PM +0100, Julien Grall wrote: >>>Hello Peng, >>> >>>On 20/

[Xen-devel] SMMU, Unhandled context fault

Hi Julien, Stefano I met an issue when passthrough a device to DomU, and have no clear idea what's wrong. " (XEN) smmu: /iommu@5c80: Unhandled context fault: iova=0x42188000, fsynr=0x433, cb=0 (XEN) smmu: /iommu@5c80: Unhandled context fault: iova=0x42188020, fsynr=0x433, cb=0 " fsynr

[Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary

. So, drop it. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Julien Grall <julien.gr...@arm.com> Cc: Stefano Stabellini <sstabell...@kernel.org> --- xen/arch/arm/smpboot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpbo

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

Hi Julien, On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote: >Hi Peng, > >I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in >setup_pagetables". Thanks. Will fix in V2. > >On 11/05/2016 08:59, Peng Fan wrote: >>Before re

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

On Wed, May 11, 2016 at 11:03:06AM +0100, Julien Grall wrote: > > >On 11/05/2016 10:57, Peng Fan wrote: >>Hi Julien, > >Hi Peng, > >>On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote: >>> >>>[...] >>> >>>>diff --g

[Xen-devel] [PATCH V2] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

level pages), is the correct one that should be used. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- V2: Take Julien's suggestion in http://lists.xen.org/archives/html/xen-devel/2016-05/msg01145

[Xen-devel] [PATCH V2 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

CPU0 is using the boot pages table before relocating xen and xen_second is not part of them. So, no need to flush the TLB when filling xen_second. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@a

[Xen-devel] [PATCH V2 2/2] xen/arm: mm: clean up code in setup_pagetables

In setup_pagetables, need to map BOOT_RELOC_VIRT_START in xen_second and boot_second, so we can merge the two pieces code into one code block. Also no need to use write_pte when map BOOT_RELOC_VIRT_START in xen_second, because CPU0 is using boot page tables now. Signed-off-by: Peng Fan <van.f

[Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

To ARM64, "frametable_size >> SECOND_SHIFT" means the number of second level entries, not the number of second level pages. "DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)" is the correct way to calculate the second level pages needed for frametable m

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

Hi Julien, On Thu, May 12, 2016 at 11:48:30AM +0100, Julien Grall wrote: >Hi Peng, > >On 12/05/16 07:36, Peng Fan wrote: >>To ARM64, "frametable_size >> SECOND_SHIFT" means the number >>of second level entries, not the number of second level page

[Xen-devel] [PATCH V3 2/2] xen/arm: mm: clean up code in setup_pagetables

, because CPU0 is using boot page tables. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- V3: Refine the commit log. V2: Follow Julien's comments: split the V1 patch into two patches, this

[Xen-devel] [PATCH V3 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

CPU0 is using the boot pages table before relocating xen and xen_second is not part of them. So, no need to flush the TLB when filling xen_second. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@ar

[Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

understand. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- There is no function change in this patch, I just think there is no need to use flush_xen_data_tlb_range_va_local and write_pte

Re: [Xen-devel] SMMU, Unhandled context fault

On Tue, May 03, 2016 at 11:58:17AM +0100, Julien Grall wrote: >On 29/04/16 15:28, Peng Fan wrote: >>Hi Julien, > >Hello Peng, > >>On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote: >>>>Is there any big difference between XEN SMMU driver and linux S

Re: [Xen-devel] Odroid XU3 support

Hi Julien, On Mon, May 09, 2016 at 10:49:58AM +0100, Julien Grall wrote: > > >On 08/05/2016 12:59, Peng Fan wrote: >>Hi Julien, > >Hello Peng, > >>On Thu, Apr 28, 2016 at 10:50:33AM +0100, Julien Grall wrote: >>>Hello, >>> >>>On 27/04/16

[Xen-devel] [PATCH 1/2] xen/arm64: correct comments

The 'Base address for 4K mapping' is '(x19 >> THIRD_SHIFT) << THIRD_SHIFT'. Also we are building 4K page mapping, not section mapping. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.c

[Xen-devel] [PATCH 2/2] xen/arm64: use shift operator

Use shift operator, but not muliplication. No function change. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- xen/arch/arm/arm64/head.S | 2 +- 1 file changed, 1 insertion(+), 1 delet

Re: [Xen-devel] [PATCH 2/2] xen/arm64: use shift operator

Hi Julien, On Wed, Apr 20, 2016 at 03:44:09PM +0100, Julien Grall wrote: >Hello Peng, > >On 20/04/16 14:54, Peng Fan wrote: >>Use shift operator, but not muliplication. >>No function change. > >Why? The compiler will calculate the address at compilation time. Yeah. T

Re: [Xen-devel] SMMU, Unhandled context fault

Hi Julien, On Fri, May 06, 2016 at 01:48:54PM +0100, Julien Grall wrote: >Hello Peng, > >On 03/05/16 14:58, Peng Fan wrote: >>On Tue, May 03, 2016 at 11:58:17AM +0100, Julien Grall wrote: >>>On 29/04/16 15:28, Peng Fan wrote: >>>>Hi Julien, >>> >>

Re: [Xen-devel] Odroid XU3 support

Hi Julien, On Thu, Apr 28, 2016 at 10:50:33AM +0100, Julien Grall wrote: >Hello, > >On 27/04/16 23:53, Suriyan Ramasami wrote: > >>How can I check which core is currently active? >>Judging by this link on big.LITTLE architecture: >>

Re: [Xen-devel] [PATCH 4/4] xen/arm: arm64: Remove MPIDR multiprocessing extensions check

Hi Wei, On Wed, May 25, 2016 at 10:10:11AM +0800, Wei Chen wrote: >In ARM64, the MPIDR multiprocessing extensions bit is reserved to 1. >So, the value check for this bit is no longer necessary on ARM64. From ARM DDI0487A.G, I found the U bit for MPIDR_EL1: " Indicates a Uniprocessor system, as

[Xen-devel] Unable to add disk on ARM64

Hi, I am using xen master branch on i.MX8 ARM64. My xl configuration: kernel = "/root/xen/Image" memory = "128" name = "DomU" vcpus = 1 serial="pty" disk = [ 'phy:/dev/loop0,xvda,w' ] extra = "console=hvc0 root=/dev/xvda debug=/bin/sh" And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0

Re: [Xen-devel] Unable to add disk on ARM64

Hi Julien, Roger On Fri, Aug 12, 2016 at 04:57:06PM +0200, Roger Pau Monné wrote: >On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote: >> On 12/08/2016 14:24, Peng Fan wrote: >> > Hi, >> >> Hello Peng, >> >> I have CCed Roger who is more

Re: [Xen-devel] Unable to add disk on ARM64

On Fri, Aug 12, 2016 at 04:57:06PM +0200, Roger Pau Monné wrote: >On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote: >> On 12/08/2016 14:24, Peng Fan wrote: >> > Hi, >> >> Hello Peng, >> >> I have CCed Roger who is more familiar than me wit

Re: [Xen-devel] Build problems with xen 4.7

Hi, On Fri, May 13, 2016 at 11:23:29AM -0400, Konrad Rzeszutek Wilk wrote: >On Fri, May 13, 2016 at 03:25:52PM +0100, M A Young wrote: >> On Fri, 13 May 2016, Jan Beulich wrote: >> >> > >>> On 13.05.16 at 15:49, wrote: >> > > ... >> > > >> > > Still an issue - with

Re: [Xen-devel] [PATCH] arm64: head: Fill image size

Hi Julien, On Thu, Aug 18, 2016 at 05:02:01PM +0100, Julien Grall wrote: >Hello Peng, > >On 16/08/16 03:58, Peng Fan wrote: >>When booting xen from U-Boot, U-Boot will use the image size >>info. Because this information is lacked in XEN image,U-Boot >>assume the im

[Xen-devel] [PATCH] arm64: head: Fill image size

When booting xen from U-Boot, U-Boot will use the image size info. Because this information is lacked in XEN image,U-Boot assume the image size is 16MB to memmove, which will cost lots time on simulation platform. Signed-off-by: Peng Fan <van.free...@gmail.com> Cc: Stefano Stabellini <

[Xen-devel] [PATCH V2] xen/arm: arm64: Update the Image header

use we may have spin table at dram_base. Loading xen to dram_base will override the spin table. Introduce image.h and macros.h in this patch, just as Linux kernel. Signed-off-by: Peng Fan <peng@nxp.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@ar

Re: [Xen-devel] xen arm64 dom0 question

Hi Julien, On Fri, Sep 02, 2016 at 02:13:07PM +0100, Julien Grall wrote: > > >On 02/09/16 12:27, Peng Fan wrote: >>Hi Julien, Stefano > >Hi Peng, > >> >>On My ARM64 platform, there is 6GB memory. >>0x8000 - 0xfff: 2GB >>0x88000 -

[Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code when identifying cpuinfo

The current_cpu_data indicates the cpuinfo for the current cpu. There is no need to fill the current_cpu_data from boot_cpu_data, because the following call to identify_cpu will override it. Signed-off-by: Peng Fan <peng@nxp.com> Cc: Julien Grall <julien.gr...@arm.com> Cc: Stefan

[Xen-devel] xen arm64 dom0 question

Hi Julien, Stefano On My ARM64 platform, there is 6GB memory. 0x8000 - 0xfff: 2GB 0x88000 - 0x9: 4GB xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a bigger value, saying 2048MB or bigger. xen will alloc continus memory from higher address space

Re: [Xen-devel] [PATCH V2] xen/arm: arm64: Update the Image header

Hi Julien, On Fri, Sep 09, 2016 at 02:19:33PM +0100, Julien Grall wrote: >Hello Peng, > >On 01/09/16 02:38, Peng Fan wrote: >>This patch is mainly modified from Linux kernel: >>[1] commit a2c1d73b94ed: arm64: Update the Image header >>[2] commit 6ad1fe5d9077: a

[Xen-devel] [PATCH V3] xen/arm: arm64: Update the Image header

n platform. The flags field is also filled with value 0xA, Bit3(physical placement): 1 Bit2-1(Page size): 1 Bit0(endianness): 0 Signed-off-by: Peng Fan <peng@nxp.com> Cc: Julien Grall <julien.gr...@arm.com> Cc: Stefano Stabellini <sstabell...@kernel.org> --- V3

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

On Wed, Sep 14, 2016 at 01:34:10PM +0100, Julien Grall wrote: > > >On 14/09/16 13:18, Peng Fan wrote: >>Hello Julien, >> >>On Wed, Sep 14, 2016 at 01:06:01PM +0100, Julien Grall wrote: >>> >>> >>>On 14/09/16 13:03, Peng Fan wrote: >>>

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hello Julien, On Wed, Sep 14, 2016 at 11:47:10AM +0100, Julien Grall wrote: >Hello, > >On 14/09/16 08:41, Peng Fan wrote: >>On Wed, Sep 14, 2016 at 08:23:24AM +0100, Julien Grall wrote: >>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >>in

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hello Julien, On Wed, Sep 14, 2016 at 01:06:01PM +0100, Julien Grall wrote: > > >On 14/09/16 13:03, Peng Fan wrote: >>Hello Julien, > >Hello Peng, > >>On Wed, Sep 14, 2016 at 11:47:10AM +0100, Julien Grall wrote: >>>Hello, >>> >>>On 14/09

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hi Edgar, On Wed, Sep 14, 2016 at 04:16:58PM +0200, Edgar E. Iglesias wrote: >On Wed, Sep 14, 2016 at 08:40:09PM +0800, Peng Fan wrote: >> On Wed, Sep 14, 2016 at 01:34:10PM +0100, Julien Grall wrote: >> > >> > >> >On 14/09/16 13:18, Peng Fan wrote: >>

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

On Tue, Sep 13, 2016 at 02:24:31PM +0100, Julien Grall wrote: > > >On 13/09/16 14:12, Peng Fan wrote: >>Hi Julien, >>On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote: >>>Hello Peng, >>> >>>On 13/09/16 13:55, Peng Fan wrote: >>&g

[Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

assign 2GB for Dom0 and 1GB of the 2GB memory in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen. Signed-off-by: Peng Fan <peng@nxp.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- RFC->V1: Thi

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hello Julien, On Wed, Sep 14, 2016 at 08:23:24AM +0100, Julien Grall wrote: >Hello, > >On 14/09/2016 06:12, Peng Fan wrote: >>On AArch64 SoCs, some IPs may only have the capability to access >>32bits address space. The physical memory assigned for Dom0 maybe >&

[Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

assign 2GB for Dom0 and 1GB of the 2GB memory in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen. Signed-off-by: Peng Fan <peng@nxp.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Julien Grall <julien.gr...@arm.com> --- This patch is t

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

Hi Julien, On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote: >Hello Peng, > >On 13/09/16 13:55, Peng Fan wrote: >>On AArch64 SoCs, some IPs may only have the capability to access >>32bits address space. The physical memory assigned for Dom0 maybe >&

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

Hi Stefano, Julien Any comments on this v4 patch? Thanks, Peng On Fri, Sep 23, 2016 at 10:55:34AM +0800, Peng Fan wrote: >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, the

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

> >> > > On 20/09/2016 12:27, George Dunlap wrote: >> > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan <van.free...@gmail.com> >> > > > wrote: >> > > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote: >> &

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Mon, Sep 19, 2016 at 11:33:58AM +0100, George Dunlap wrote: >On 19/09/16 11:06, Julien Grall wrote: >> Hi George, >> >> On 19/09/2016 11:45, George Dunlap wrote: >>> On Mon, Sep 19, 2016 at 9:53 AM, Julien Grall >>> wrote: >> As mentioned in the mail you pointed

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Mon, Sep 19, 2016 at 11:59:05AM +0200, Julien Grall wrote: > > >On 19/09/2016 11:38, Peng Fan wrote: >>On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote: >>>Hello, >>> >>>On 19/09/2016 10:36, Peng Fan wrote: >>>>On Mon, Sep 19, 20

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

Hello Julien, On Mon, Sep 19, 2016 at 10:53:56AM +0200, Julien Grall wrote: >Hello, > >On 19/09/2016 10:36, Peng Fan wrote: >>On Mon, Sep 19, 2016 at 10:09:06AM +0200, Julien Grall wrote: >>>Hello Peng, >>> >>>On 19/09/2016 04:08, van.free...@gmail.com w

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

On Wed, Sep 21, 2016 at 11:39:11AM +0100, Julien Grall wrote: > > >On 20/09/16 10:10, Peng Fan wrote: >>Hello Julien, > >Hello Peng, > >>On Tue, Sep 20, 2016 at 10:36:27AM +0200, Julien Grall wrote: >>>Hello Peng, >>> >>>On 20/09/2016 07:

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, Sep 21, 2016 at 11:15:35AM +0100, Julien Grall wrote: >Hello Peng, > >On 21/09/16 09:38, Peng Fan wrote: >>On Tue, Sep 20, 2016 at 01:17:04PM -0700, Stefano Stabellini wrote: >>>On Tue, 20 Sep 2016, Julien Grall wrote: >>>>On 20/09/2016 20:09, Stefano S

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

2016, Julien Grall wrote: >>>>>Hi, >>>>> >>>>>On 20/09/2016 12:27, George Dunlap wrote: >>>>>>On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan <van.free...@gmail.com> >>>>>>wrote: >>>>>>>On Tue

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Wed, Sep 21, 2016 at 10:22:14AM +0100, George Dunlap wrote: >On 21/09/16 09:38, Peng Fan wrote: >> On Tue, Sep 20, 2016 at 01:17:04PM -0700, Stefano Stabellini wrote: >>> On Tue, 20 Sep 2016, Julien Grall wrote: >>>> Hi Stefano, >>>> >>

  1   2   >