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

[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

[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

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

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

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

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

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

<    1   2