Use shift operator, but not muliplication.
No function change.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 05e3db0
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
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch/arm/arm64/head.S | 8
1 file chang
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
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/04/16 14:
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 i
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:
>>>>
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. Iglesias w
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:58:28AM +0100,
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,
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
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,
>>>
>>
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:
>>http://forum.odroid.com/viewtopic.php?f=65
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
understand.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
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
at that point. And I tested this patch on AArch64.
xen/arch/arm/mm.c | 11 +
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 reloc
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
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
Cc: Stefano Stabellini
Cc: Julien Grall
---
V2:
Following Julien's comments:
split the V1 patch into two patches.
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
Cc
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
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
, because CPU0 is using boot page tables.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
V3:
Refine the commit log.
V2:
Follow Julien's comments:
split the V1 patch into two patches, this patch is the code movement part.
xen/arch/arm/mm.c | 10 --
1 file ch
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
Cc: Stefano Stabellini
Cc: Julien Grall
Reviewed-by: Julien Grall
---
V3:
Add Julien's review tag.
V2:
Foll
pages),
is the correct one that should be used.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
V2:
Take Julien's suggestion in
http://lists.xen.org/archives/html/xen-devel/2016-05/msg01145.html.
Refine commit log.
xen/arch/arm/mm.c | 3 ++-
1 file changed, 2 inser
. So, drop it.
Signed-off-by: Peng Fan
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/arch/arm/smpboot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c5109bf..6b3c157 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
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
Cc: Stefano Stabellini
Cc: Julien Grall
---
V2: Addressing Julien's comments to follow linux kernel
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
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/arch/arm/smpboot.c | 1 -
1
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 in
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 - 0x9f
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
form.
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
Cc: Julien Grall
Cc: Stefano Stabellini
---
V3:
Drop the image.h macros.h from Linux, included in V2.
Only update image size
gn 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
Cc: Stefano Stabellini
Cc: Julien Grall
---
This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg0
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
>>not in
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:
>>>&
gn 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
Cc: Stefano Stabellini
Cc: Julien Grall
---
RFC->V1:
This patch is to resolve the issue in
https://lists.xen.org/archives/html/xen-devel/2016-09
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
>>not in
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
>>index 35ab
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
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:
>>>
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:
>>
Hi Edgar,
On Thu, Sep 15, 2016 at 10:26:46AM +0200, Edgar E. Iglesias wrote:
>On Thu, Sep 15, 2016 at 08:20:33AM +0800, Peng Fan wrote:
>> 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
Hello Julien,
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 wrote:
>>From: Peng Fan
>>
>>This patchset is to support XEN run on big.little SoC.
>>The idea of the patch is from
>>&quo
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 wrote:
>&g
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.co
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
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 above, this series is not
>
On Tue, Sep 20, 2016 at 02:11:04AM +0200, Dario Faggioli wrote:
>On Mon, 2016-09-19 at 21:33 +0800, Peng Fan wrote:
>> On Mon, Sep 19, 2016 at 11:33:58AM +0100, George Dunlap wrote:
>> >??
>> > No, I think it would be a lot simpler to just teach the scheduler
>>
Hello Julien,
On Tue, Sep 20, 2016 at 10:36:27AM +0200, Julien Grall wrote:
>Hello Peng,
>
>On 20/09/2016 07:52, van.free...@gmail.com wrote:
>>From: Peng Fan
>>
>>On AArch64 SoCs, some IPs may only have the capability to access
>>32bits address space. The physic
Hi Dario,
On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
>On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
>> On Tue, 20 Sep 2016, Dario Faggioli wrote:
>> > And this would work even if/when there is only one cpupool, or in
>> > general for domains that are in a pool th
>
>> > > On 20/09/2016 12:27, George Dunlap wrote:
>> > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan
>> > > > wrote:
>> > > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote:
>> > > > > > On Mon, 2016
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/20
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
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,
>>>>
>>>> O
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
>>>>>>wrote:
>>>>>>>On Tue, Sep 20, 2016 at 02:54:06AM +020
On Wed, Sep 21, 2016 at 08:28:32PM +0100, Julien Grall wrote:
>Hi Dario,
>
>On 21/09/2016 16:45, Dario Faggioli wrote:
>>On Wed, 2016-09-21 at 14:06 +0100, Julien Grall wrote:
>>>(CC a couple of ARM folks)
>>>
>>Yay, thanks for this! :-)
>>
>>>I had few discussions and more thought about big.LITTL
t;>>>>On 20/09/2016 20:09, Stefano Stabellini wrote:
>>>>>>>>On Tue, 20 Sep 2016, Julien Grall wrote:
>>>>>>>>>Hi,
>>>>>>>>>
>>>>>>>>>On 20/09/2016 12:27, George Dunlap wrote:
>>&
o allocate bank0 under 4GB,
need to panic for 32-bit domain, because 32-bit domain requires bank0
be allocated under 4GB.
For 64-bit domain, set "lowmem" to false, and continue allocating
memory from higher memory space.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
>> On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
>> >
>> > Hi Stefano,
>> >
>> > On 21/09/2016 19:13, Stefano Stabell
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
On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
>> On Wed, Sep 21, 2016 at 08:11:43PM +0100, Julien Grall wrote:
>> >
>> > Hi Stefano,
>> >
>> > On 21/09/2016 19:13, Stefano Stabell
On Thu, Sep 22, 2016 at 10:51:04AM +0100, George Dunlap wrote:
>On 22/09/16 10:27, Peng Fan wrote:
>> On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>>> On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
>>>> On Wed, Sep 21, 2016 at 08:11:
On Thu, Sep 22, 2016 at 04:23:05PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 22/09/16 10:16, 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 s
On Thu, Sep 22, 2016 at 12:29:53PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 22/09/16 10:27, Peng Fan wrote:
>>On Thu, Sep 22, 2016 at 10:50:23AM +0200, Dario Faggioli wrote:
>>>On Thu, 2016-09-22 at 14:49 +0800, Peng Fan wrote:
>>>>On Wed, Sep 21, 2016 at
On Thu, Sep 22, 2016 at 07:54:02PM +0100, Julien Grall wrote:
>Hi Stefano,
>
>On 22/09/2016 18:31, Stefano Stabellini wrote:
>>On Thu, 22 Sep 2016, Julien Grall wrote:
>>>Hello Peng,
>>>
>>>On 22/09/16 10:27, Peng Fan wrote:
>>>>On Thu,
On Thu, Sep 22, 2016 at 12:21:00PM +0100, Julien Grall wrote:
According to George's comments,
Then, I think we could use affinity to restrict little vcpus be scheduled
on little vcpus,
and restrict big vcpus on big vcpus. Seems no need to consider soft
affinity, use hard
ated under 4GB.
For 64-bit domain, set "lowmem" to false, and continue allocating
memory from above 4GB.
Signed-off-by: Peng Fan
Cc: Stefano Stabellini
Cc: Julien Grall
---
This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/ms
On Fri, Sep 23, 2016 at 10:24:37AM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 23/09/16 03:14, Peng Fan wrote:
>>On Thu, Sep 22, 2016 at 07:54:02PM +0100, Julien Grall wrote:
>>>Hi Stefano,
>>>
>>>On 22/09/2016 18:31, Stefano Stabellini wrote:
&
Hi Julien,
Sorry for late reply.
On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
>Hi Peng,
>
>Sorry for the late answer.
>
>On 23/09/2016 03:55, Peng Fan wrote:
>>On AArch64 SoCs, some IPs may only have the capability to access
>>32 bits address space. T
On Thu, Nov 10, 2016 at 01:01:38PM +, Julien Grall wrote:
>(CC Wei as release manager)
>
>On 10/11/16 08:30, Peng Fan wrote:
>>Hi Julien,
>
>Hi Peng,
>
>>On Tue, Nov 01, 2016 at 02:42:06PM +, Julien Grall wrote:
>>>Hi Peng,
>>>
>>>So
Hi Julien,
On Tue, Nov 22, 2016 at 02:28:39PM +, Julien Grall wrote:
>Hello Anastassios,
>
>On 09/11/16 22:50, Anastassios Nanos wrote:
>>Hi Julien, all,
>>
>>>I would like to start organizing a recurring community call to discuss and
>>>sync-up on upcoming features for Xen ARM.
>>
>>great idea
On Tue, Nov 29, 2016 at 01:49:51PM +, Julien Grall wrote:
>(CC Stefano)
>
>On 25/11/16 12:19, Iurii Mykhalskyi wrote:
>>Hello!
>
>Hi Iurii,
>
>>
>>I'm working under Renesas Gen3 H3 board with 4GB RAM (Salvator-X)
>>support in Xen mainline.
>>
>>Salvator-X has several CMA pool nodes, for exampl
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 4.7.0-rc1.
>> >
>> > And I d
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 Linux
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
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
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
Cc: Stefano Stabellini
Cc: Julien Grall
---
xen/arch
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
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
max_ring_order using XENBUS_MAX_RING_GRANT_ORDER,
but not 0.
Signed-off-by: Peng Fan
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: "Roger Pau Monné"
---
Hi,
I am new to xen and reading related soure code, not sure whether
this is correct. Please comments.
Thanks
dr
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
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
--
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: Tempera
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 on this
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 @@
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
>
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 1
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;
>> ph
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 yo
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 di
Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv
Signed-off-by: Peng Fan
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/arch/arm/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 09ff1ea..dcb23b7 100644
--- a/xen/a
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
Cc: Julien Grall
Cc: Stefano Stabellini
---
xen/a
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
Cc: Julien
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).
>
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_
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
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
Cc: Julien Grall
Cc: Stefano Stabellini
---
V2:
Take Julien's better commit message. Thanks.
xen/include/asm-arm/config.h
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 fro
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 ARM
|->ID: PREPARE, name: "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.linuxfoundati
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 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
>> passhthro
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 comments
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
1 - 100 of 124 matches
Mail list logo
