e working
> on an ARM64 port of MiniOS.
>
> Anastassios, in CC, is interested get MiniOS running on ARM64 as well.
>
> Do you know what is missing to get MiniOS booting? I have found a tree
> on your github for the port [1], is it the latest version?
>
> Cheers,
--
陈鲍孜 (Chen Ba
On Tue, Mar 15, 2016 at 06:37:43PM +, Julien Grall wrote:
> (CC Chen for the omap port)
>
> Hi Lars,
>
> On 15/03/16 10:56, Lars Kurth wrote:
> >Folks,
> >
> >I just noticed a cluster of issues related to Xen unstable hanging on
> >various ARM boards. See
> >*
> >http://xenproject.org/help/
Hi all,
With plenty of ugly hacks, mini-os is now able to boot on my arm64 board:
(d37) - Mini-OS booting -
(d37) - Setup CPU -
(d37) - Setup booting pagetable -
(d37) - MMU on -
(d37) - Setup stack -
(d37) - Jumping to C entry -
(d37) Checking DTB at ffbff000...
(d37) map_console, phys =
it://xenbits.xen.org/people/julieng/xen-unstable.git branch
> gicv2-on-gicv3-v2
>
> For all the changes see in each patch.
I have rebased the 8+ CPU patch series onto this version. It looks fine for me.
You may add "Tested-by: Chen Baozi ".
Cheers,
Baozi.
From: Chen Baozi
Each vGIC driver supports different maximum numbers of vCPU. For
example, GICv2 is limited to 8 vCPUs, while GICv3 can support up
to 4096 vCPUs if we use both AFF0 and AFF1. Thus, domain_max_vcpus
should depend on not only MAX_VIRT_CPUS but also the version
of vGIC that the
From: Chen Baozi
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is unnecessarily big at the
moment
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Acked-by: Ian Cam
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Reviewed-by: Julien
From: Chen Baozi
The old unsigned long type of vcpu_mask can only express 64 cpus at the
most, which might not be enough for the guest which used vGICv3. We
introduce a new struct sgi_target for the target cpu list of SGI, which
holds the affinity path information (only level 1 at the moment
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Both PSCI 0.1 and PSCI
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
Acked-by: Ian Campbell
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. (See the note of 'Bits[15:0]' in '5.7.29 ICC_SGI0R_EL1
ICC_SGI1R_EL1 and ICC_ASGI1R_EL1, GICv3 Architecture Specification')
That is to say the upper 4 bits of affinity
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
From: Chen Baozi
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is unnecessary big at the
moment
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Acked-by: Ian Cam
From: Chen Baozi
Each vGIC driver supports different maximum numbers of vCPU. For
example, GICv2 is limited to 8 vCPUs, while GICv3 can support up
to 4096 vCPUs if we use both AFF0 and AFF1. Thus, domain_max_vcpus
should depend on not only MAX_VIRT_CPUS but also the version
of vGIC that the
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. (See the note of 'Bits[15:0]' in '5.7.29 ICC_SGI0R_EL1
ICC_SGI1R_EL1 and ICC_ASGI1R_EL1, GICv3 Architecture Specification')
That is to say the upper 4 bits of affinity
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Reviewed-by: Julien
From: Chen Baozi
The old unsigned long type of vcpu_mask can only express 64 cpus at the
most, which might not be enough for the guest which used vGICv3. We
introduce a new struct sgi_target for the target cpu list of SGI, which
holds the affinity path information (only level 1 at the moment
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Both PSCI 0.1 and PSCI
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
Acked-by: Ian Campbell
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
On Thu, Jun 11, 2015 at 09:05:06PM +0800, Chen Baozi wrote:
> From: Chen Baozi
>
> The old unsigned long type of vcpu_mask can only express 64 cpus at the
> most, which might not be enough for the guest which used vGICv3. We
> introduce a new struct sgi_target for the target
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Acked-by: Ian Cam
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which will be more than 8
when GICv3 is used on arm64. So the domain_max_vcpus should return
the value according to the vGIC the domain uses.
We didn't keep it as th
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Also make the code for
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
Acked-by: Ian Campbell
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2
From: Chen Baozi
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is unnecessary big at the
moment
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Reviewed-by: Julien
From: Chen Baozi
The old unsigned long type of vcpu_mask can only express 64 cpus at the
most, which might not be enough for the guest which used vGICv3. We
introduce a new struct sgi_target for the target cpu list of SGI, which
holds the affinity path information. For GICv2 that has no affinity
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. (See the note of 'Bits[15:0]' in '5.7.29 ICC_SGI0R_EL1
ICC_SGI1R_EL1 and ICC_ASGI1R_EL1, GICv3 Architecture Specification')
That is to say the upper 4 bits of affinity
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
Hi Julien,
On Thu, Jun 11, 2015 at 07:47:11AM -0400, Julien Grall wrote:
> Hi Chen,
>
> On 11/06/2015 07:16, Chen Baozi wrote:
> >On Thu, Jun 11, 2015 at 10:37:05AM +0100, Ian Campbell wrote:
> >>On Thu, 2015-06-11 at 17:20 +0800, Chen Baozi wrote:
> >>>On F
On Thu, Jun 11, 2015 at 10:37:05AM +0100, Ian Campbell wrote:
> On Thu, 2015-06-11 at 17:20 +0800, Chen Baozi wrote:
> > On Fri, Jun 05, 2015 at 05:22:56PM +0100, Ian Campbell wrote:
> > > On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
> > > > From: Chen Baozi
On Fri, Jun 05, 2015 at 05:22:56PM +0100, Ian Campbell wrote:
> On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
> > From: Chen Baozi
> >
> > evtchn_init will call domain_max_vcpus to allocate poll_mask. On
> > arm/arm64 platform, this number is determined by the
On Fri, Jun 05, 2015 at 05:05:29PM +0100, Ian Campbell wrote:
> On Mon, 2015-06-01 at 20:56 +0800, Chen Baozi wrote:
> > From: Chen Baozi
> >
> > Use cpumask_t instead of unsigned long which can only express 64 cpus at
> > the most. Add the {gicv2|gicv3}_sgir_to_cpu
From: Chen Baozi
After we have increased the size of GICR in address space for guest
and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to
support up to 4096 vCPUs in theory. However, it will cost 512M
address space for GICR region, which is not necessary big at the
moment
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which will be more than 8
when GICv3 is used on arm64. So the domain_max_vcpus should return
the value according to the vGIC the domain uses.
We didn't keep it as th
From: Chen Baozi
evtchn_init will call domain_max_vcpus to allocate poll_mask. On
arm/arm64 platform, this number is determined by the vGIC the guest
is going to use, which won't be initialised until arch_domain_create
is called in current implementation. However, moving arch_domain_create
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arc
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
Reviewed-by: Julien
From: Chen Baozi
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c| 30 ++
xen/include/asm-arm/gic_v3_defs.h | 2 ++
2 files changed, 28 insertions
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Also make the code for
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2
On Sun, May 31, 2015 at 07:21:22PM +0100, Julien Grall wrote:
> Hi Chen,
>
> On 31/05/2015 16:37, Chen Baozi wrote:
> >
> >>On May 31, 2015, at 21:40, Julien Grall wrote:
> >>
> >>Hi Chen,
> >>
> >>On 30/05/2015 12:07, Chen Baozi wro
On Sat, May 30, 2015 at 07:07:26PM +0800, Chen Baozi wrote:
> From: Chen Baozi
>
> To support more than 16 vCPUs, we have to calculate cpumask with AFF1
> field value in ICC_SGI1R_EL1.
>
> Signed-off-by: Chen Baozi
> ---
> xen/arch/arm/vgic-v3.c| 9
> On May 31, 2015, at 21:40, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> From: Chen Baozi
>>
>> GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
>> to 128 on arm64.
>
> Where did you
> On May 31, 2015, at 21:35, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> From: Chen Baozi
>>
>> When a guest uses vGICv2, the maximum number of vCPU it can support
>> should not be as many as MAX_VIRT_CPUS
Hi Julien,
> On May 31, 2015, at 21:14, Julien Grall wrote:
>
> Hi Chen,
>
> On 30/05/2015 12:07, Chen Baozi wrote:
>> From: Chen Baozi
>>
>> To support more than 16 vCPUs, we have to calculate cpumask with AFF1
>> field value in ICC_SGI1
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Since the domain_max_vcpus has been changed to depends on vgic_ops,
we could have done more work in order to drop the definition of
MAX_VIRT_CPUS. However, because it is still used for
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arc
From: Chen Baozi
evtchn_init() will call domain_max_vcpus() to allocate poll_mask, which
needs the max vCPU number returned by domain_max_vcpus(). On arm/arm64
platform, this number is determined by the vGIC the guest is going to
use, which won't be initialised until arch_domain_create
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which is 128 at the moment.
So the domain_max_vcpus should return the value according to the vGIC
the domain uses.
We didn't keep it as the old static inline form be
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
To support more than 16 vCPUs, we have to calculate cpumask with AFF1
field value in ICC_SGI1R_EL1.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c| 9 -
xen/include/asm-arm/gic_v3_defs.h | 3 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
- Also make the code for
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
On Sat, May 30, 2015 at 10:08:21AM +0800, Chen Baozi wrote:
> Hi Julien,
>
> On Fri, May 29, 2015 at 05:08:08PM +0100, Julien Grall wrote:
> > On 29/05/15 16:55, Ian Campbell wrote:
> > > On Fri, 2015-05-29 at 16:44 +0100, Julien Grall wrote:
> > >
> >
On Fri, May 29, 2015 at 04:49:42PM +0100, Julien Grall wrote:
> Hi Chen,
>
> On 28/05/15 11:15, Chen Baozi wrote:
> > From: Chen Baozi
> >
> > According to ARM CPUs bindings, the reg field should match the MPIDR's
> > affinity bits. We will use AFF0 an
Hi Julien,
On Fri, May 29, 2015 at 05:08:08PM +0100, Julien Grall wrote:
> On 29/05/15 16:55, Ian Campbell wrote:
> > On Fri, 2015-05-29 at 16:44 +0100, Julien Grall wrote:
> >
> >>> +name = GCSPRINTF("cpu@%lx", mpidr_aff);
> >>
> >> It's not necessary to change the cpu@.
> >
> > AIUI it
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c | 16
From: Chen Baozi
When a guest uses vGICv2, the maximum number of vCPU it can support
should not be as many as MAX_VIRT_CPUS, which is 128 at the moment.
So the domain_max_vcpus should return the value according to the vGIC
version the domain uses.
We didn't keep it as the old static inline
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c | 1 -
xen/include/asm-arm/config.h | 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
Signed-off-by: Chen Baozi
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arc
Hi Andrew,
On Thu, May 28, 2015 at 09:50:38AM +0100, Andrew Cooper wrote:
> On 28/05/15 08:44, Chen Baozi wrote:
> > From: Chen Baozi
> >
> > Since the maximum vcpu information is already saved in the struct domain,
> > there is no need for domain_max_vpu
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIDR affinity information when booting with vPSCI
in vGIC
Signed-off-by: Chen Baozi
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
Use cpumask_t instead of unsigned long which can only express 64 cpus at
the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs
to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v2.c | 16
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
xen/arc
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c | 1 -
xen/include/asm-arm/config.h | 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic
From: Chen Baozi
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest up to 128 vCPUs, which is the maxium number that GIC
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maximum number that GIC-500 supports.
Signed-off-by: Chen Baozi
Reviewed-by: Julien Grall
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Chen Baozi
Since the maximum vcpu information is already saved in the struct domain,
there is no need for domain_max_vpus to return the fixed value.
Signed-off-by: Chen Baozi
---
xen/include/asm-arm/domain.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen
From: Chen Baozi
According to ARM CPUs bindings, the reg field should match the MPIDR's
affinity bits. We will use AFF0 and AFF1 when constructing the reg value
of the guest at the moment, for it is enough for the current max vcpu
number.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_
actorize the code to find a vCPU from the
> affinity in a single place. It will be easier to change the way to do it
> later.
>
> Signed-off-by: Julien Grall
> Cc: Chen Baozi
Acked-by: Chen Baozi
> ---
> xen/arch/arm/vgic-v3.c | 100
> ++-
On Sun, May 24, 2015 at 01:51:21PM +0100, Julien Grall wrote:
> Hi Chen,
>
> On 23/05/2015 14:52, Chen Baozi wrote:
> >From: Chen Baozi
> >
> >There are 3 places to change:
> >
> >* Initialise vMPIDR value in vcpu_initialise()
> >* Find the vCPU fr
On Sat, May 23, 2015 at 03:46:32PM +0100, Julien Grall wrote:
> Hi Chen,
>
> On 23/05/2015 14:52, Chen Baozi wrote:
> >From: Chen Baozi
> >
> >GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
> >to 128 on arm64.
>
> This series have
From: Chen Baozi
This patch does the same thing as the previous one but for dom0 kernel.
Signed-off-by: Chen Baozi
---
xen/arch/arm/domain_build.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index
From: Chen Baozi
There are 3 places to change:
* Initialise vMPIDR value in vcpu_initialise()
* Find the vCPU from vMPIDR affinity information when accessing GICD
registers in vGIC
* Find the vCPU from vMPIRR affinity information when booting with vPSCI
in vGIC
Signed-off-by: Chen Baozi
From: Chen Baozi
Use the AFF1 value of ICC_SGI1R_EL1 when injecting SGI in vGIC,
which expands the number of supported vCPU more than 16 that
target list bitmap can hold independently.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic.c | 10 --
1 file changed, 8 insertions(+), 2
From: Chen Baozi
Linux kernel sometimes uses the 'hwid' which is fetched from DT node
of CPU as the MPIDR. We set the logical CPUID in the corresponding DT
node to MPIDR to keep consistency.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_arm.c | 11 +--
1 file changed, 9
From: Chen Baozi
Since the size of GICR is determined by the number of CPU
cores, add 'nr_cpus' parameter when creating its DT node
and set gicr0_size dynamically.
Signed-off-by: Chen Baozi
---
tools/libxl/libxl_arm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
di
From: Chen Baozi
GICv3 restricts that the maximum number of CPUs in affinity 0 (one
cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused.
Current implementation considers that AFF0 is equal to vCPUID, which
makes all vCPUs in one cluster, limiting its number to 16. If we would
From: Chen Baozi
Currently it only supports up to 8 vCPUs. Increase the region to hold
up to 128 vCPUs, which is the maxium number that GIC-500 supports.
Signed-off-by: Chen Baozi
---
xen/include/public/arch-arm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen
From: Chen Baozi
GIC-500 supports up to 128 cores in a single SoC. Increase MAX_VIRT_CPUS
to 128 on arm64.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic-v3.c | 2 +-
xen/include/asm-arm/config.h | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic
From: Chen Baozi
[Sorry for the incorrect list address previously.]
Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due
to the fixed size of redistributor mmio region. Increasing the size
makes the number expand to 16 because of AFF0 restriction on GICv3.
To create a guest
From: Chen Baozi
Signed-off-by: Chen Baozi
---
xen/include/public/arch-arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c029e0f..cbcda74 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include
1 - 100 of 128 matches
Mail list logo
