- 0x8000d000 + 1 = 0x8001
Signed-off-by: Shlomo Pongratz
Changes since v3:
* Use Peter Maydell's suggestion for fixing the bug,
that is compute a 64 bits limit from the upper 32 bits of the base
and the given 32 bits limit.
Changes
Please see inline
On 22/01/2024 01:17, Philippe Mathieu-Daudé wrote:
Hi Shlomo,
On 21/1/24 17:47, Shlomo Pongratz wrote:
From: Shlomo Pongratz
Hanlde wrap around when calculating the viewport size
caused by the fact that perior to version 460A the limit variable
was 32bit
From: Shlomo Pongratz
Hanlde wrap around when calculating the viewport size
caused by the fact that perior to version 460A the limit variable
was 32bit quantity and not 64 bits quantity.
In the i.MX 6Dual/6Quad Applications Processor Reference Manual
document on which the
See Inline.
On 15/01/2024 18:47, Peter Maydell wrote:
On Mon, 15 Jan 2024 at 13:51, Shlomo Pongratz wrote:
On 15/01/2024 12:37, Peter Maydell wrote:
For instance, the kernel code suggests that pre-460A
there's a 32 bit limit register, and post-460A there
is a 64-bit limit (wi
On 15/01/2024 12:37, Peter Maydell wrote:
See inline.
On Mon, 15 Jan 2024 at 05:58, Shlomo Pongratz wrote:
Thank you.
Please see comments inline.
On Fri, Jan 12, 2024 at 7:03 PM Peter Maydell wrote:
On Tue, 9 Jan 2024 at 12:45, Shlomo Pongratz wrote:
Hi; thanks for this patch.
Hanlde
Thank you.
Please see comments inline.
On Fri, Jan 12, 2024 at 7:03 PM Peter Maydell wrote:
On Tue, 9 Jan 2024 at 12:45, Shlomo Pongratz wrote:
Hi; thanks for this patch.
Hanlde wrap around caused by the fact that perior to version 460A
Is this "460A" version number a vers
Thank you.
Please see comments inline.
On Fri, Jan 12, 2024 at 7:03 PM Peter Maydell wrote:
>
> On Tue, 9 Jan 2024 at 12:45, Shlomo Pongratz wrote:
>
> Hi; thanks for this patch.
>
> > Hanlde wrap around caused by the fact that perior to version 460A
>
> Is this &quo
4G the overflow is avoided
Signed-off-by: Shlomo Pongratz
Changes since v1:
* Seperate subject and description
---
hw/pci-host/designware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
index
Signed-off-by: Shlomo Pongratz
---
hw/pci-host/designware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
index dd9e389c07..7ce4a6b64d 100644
--- a/hw/pci-host/designware.c
+++ b/hw/pci-host/designware.c
Thank you, see comment inside.
On Sun, Dec 24, 2023 at 1:11 PM BALATON Zoltan wrote:
>
> On Sun, 24 Dec 2023, Shlomo Pongratz wrote:
> > Hi,
> > I'm working on a AARCH64 project that uses the designeware
> > (hw/pci-host/designware.c).
> > I've copied t
ted?
But the main problem is that during the initialization of the
controller registers in BAR0 all the read and writes are actually done
into the config space.
Any ideas?
Thank you
Shlomo Pongratz.
.
Signed-off-by: Shlomo Pongratz
---
hw/pci-host/designware.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
index f477f97847..4558d552ab 100644
--- a/hw/pci-host/designware.c
+++ b/hw/pci-host/designware.c
@@ -340,7 +340,8
dé wrote:
>
> > Cc'ing VFIO maintainers.
> >
> > On 12/9/23 14:39, Shlomo Pongratz wrote:
> > > Hi,
> > > I'm running qemu-system-aarch64 (QEMU emulator version 7.0.93) on
> > > Ubuntu 20.04.4 LTS i with Intel's i7.
> > > I'm
+3,9 @@
> *
> * Copyright (c) 2012 Linaro Limited
> * Copyright (c) 2015 Huawei.
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> * Written by Peter Maydell
> - * Extended to 64 cores by Shlomo Pongratz
> + * Reworked for GICv3 by Shlomo Pongratz and Pavel Fedin
>
On Tuesday, February 16, 2016, Shlomo Pongratz
wrote:
>
>
> On Tuesday, February 16, 2016, Peter Maydell > wrote:
>
>> On 31 January 2016 at 15:54, Shlomo Pongratz
>> wrote:
>> > I will do a new revision of the GICv3.
>> > I needed to get a time
On Friday, January 29, 2016, Christopher Covington
wrote:
> On 10/20/2015 01:22 PM, Shlomo Pongratz wrote:
> > From: Shlomo Pongratz >
> >
> > This patch is a first step multicores support for arm64.
> >
> > This implemntation was tested up to
-Original Message-
From: Pavel Fedin [mailto:p.fe...@samsung.com]
Sent: 2015年10月28日 19:13
To: 'Peter Crosthwaite'; 'Paolo Bonzini'
Cc: 'Peter Maydell'; 'Shlomo Pongratz'; 'QEMU Developers'; Shlomo Pongratz
Subject: RE: [Qemu-devel] [P
on.c
> > index 032ece2..2082d05 100644
> > --- a/hw/intc/arm_gicv3_common.c
> > +++ b/hw/intc/arm_gicv3_common.c
> > @@ -3,8 +3,9 @@
> > *
> > * Copyright (c) 2012 Linaro Limited
> > * Copyright (c) 2015 Huawei.
> > + * Copyright (c) 2015 Samsung Elec
Hi,
On Thursday, October 22, 2015, Pavel Fedin wrote:
> Hello!
>
> >> It has nothing to do with KVM. EFI is a firmware, which originates from
> Intel, but now adopted by ARM64 architecture too. You can also run
> >> it under qemu, if you want to make kind of "full" machine. And it
> writes some
Hi
On Thursday, October 22, 2015, Pavel Fedin wrote:
> Hello!
>
> > I've implemented the registers accessed by Linux driver in
> drivers/irqchip/irq-gic-v3.c
> > If this register is used only with KVM e.g. virt/kvm/arm/vgic-v3.c than
> it is out of my mandate.
>
> It has nothing to do with KVM
Hi
On Thursday, October 22, 2015, Pavel Fedin wrote:
> Hello!
>
> > -Original Message-
> > From: Shlomo Pongratz [mailto:shlomopongr...@gmail.com ]
> > Sent: Tuesday, October 20, 2015 8:22 PM
> > To: qemu-devel@nongnu.org
> > Cc: p.fe...@sa
O.K.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > Do you mean that in virt.c::create_gic I'll take the cpu's affinity from
> the cpu's property and not directly from
> > ARM_CPU(qemu_get_cpu(i))->mp_affinity
>
> I mean that you can do it in your GIC's realize function. And
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > I just added a placeholder, I didn't add any functionality.
>
> I see. Just wanted to say, that if we accept my proposal (implementing
> ITS as a separate object), then the only thing we would do with this
> placeholder is to rem
Hi,
As far as I understand Figure 1 in GICv3 architecture document the
interrupts from device goes to the distributor and from it to the
re-distributors or from the deices via the ITS to the re-distributors.
So eventually ITS should be part of the GIC. That is if the ITS is a
different entity how
Hi,
I just added a placeholder, I didn't add any functionality.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > This patch includes a placeholder code for future spi and its
> > implementation.
>
> Forgot to comment on this. I see that here you are building an ITS into
> GIC
O.K.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> >> The system register implementation belongs in the gic code, not
> >> target-arm/. We already have support for devices that say
> >> "I have some system registers, please add them to this CPU".
>
> > I don't understand.
> >
I just wanted to understand. I don't have any preferences.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > As far as I understand Figure 1 in GICv3 architecture document the
> interrupts from device goes to the distributor and from it to the
> > re-distributors or from the dei
On Wednesday, October 21, 2015, Peter Maydell
wrote:
> On 21 October 2015 at 12:33, Shlomo Pongratz > wrote:
> > I assume I can add the system registers to target-arm/cpu.c but I wonder
> if
> > someone really needs to simulate more than 8 AArch32 CPU(s)
>
> The sys
See inline
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> >> See this:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg02349.html.
> This is also a part of my live migration RFC.
> >> I remember that Peter told long time ago that "it should really be a
> property",
See inline.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > I can't find the patch that handles the for example modification of
> "uint8_t sgi_pending[GIC_NR_SGIS][GIC_NCPU]" to fixed-size bitmaps. as
> > GIC_NCPU is not a constant and uint8_t need to have the size of nubmer
>
See inline
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > I see, just how do I pass the gic version from the command line?
>
> Easy. -machine virt,gic-version=3
>
> > GICV3 is accessed by system instructions that exists only in ARCH64.
>
> Wrong. In 32-bit mode the CPU sees
See inline.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > -Original Message-
> > From: Shlomo Pongratz [mailto:shlomopongr...@gmail.com ]
> > Sent: Tuesday, October 20, 2015 8:22 PM
> > To: qemu-devel@nongnu.org
> >
From: Shlomo Pongratz
This patch is a first step multicores support for arm64.
This implemntation was tested up to 100 cores.
Things left to do:
Support SPI, ITS and ITS CONTROL, note that this patch porpose is to enable
running multi cores using the "virt" virtual machine and th
From: Shlomo Pongratz
This patch incudes the GIC functionality that is exposed to the CPU
via system instructions. In GICv2 this functionality was exposed via
memory mapped access.
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_cpu_interface.c
From: Shlomo Pongratz
This patch includes the part of the GIC's code that handles
the interrupts.
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_interrupts.c | 295 +
hw/intc/arm_gicv3_interrupts.h
From: Shlomo Pongratz
Add system instructions used by the Linux (kernel) GICv3
device driver
Signed-off-by: Shlomo Pongratz
---
target-arm/cpu-qom.h | 1 +
target-arm/cpu.h | 12 ++
target-arm/cpu64.c | 118 +++
3 files changed, 131
From: Shlomo Pongratz
This patch includes the code that binds together the codes of
all the previous patches.
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3.c | 134 ++
2 files changed, 135 insertions
From: Shlomo Pongratz
Add virt-v3 machine that uses GIC-500.
Registers the CPU system instructions and bind them to the GIC.
Pass the cores' affinity to the GIC.
Signed-off-by: Shlomo Pongratz
---
hw/arm/virt.c | 87 ++-
include/h
From: Shlomo Pongratz
This patch includes the code that implements the functionality of
the redisributer, which is the main enhancment of GICv3 over GICv3
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_redist.c | 460
From: Shlomo Pongratz
This patch includes a placeholder code for future spi and its
implementation.
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_spi_its.c | 359
hw/intc/arm_gicv3_spi_its.h | 11 ++
3
From: Shlomo Pongratz
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs| 1 +
hw/intc/arm_gicv3_dist.c | 655 +++
hw/intc/arm_gicv3_dist.h | 9 +
hw/intc/gicv3_internal.h | 8 +
4 files changed, 673 insertions(+)
create mode 100644
Thanks,
I'll fix it and submit together with with the changes required by Peter.
Best regards,
S.P.
On Thursday, September 24, 2015, Christopher Covington
wrote:
> On 09/24/2015 02:03 PM, Christopher Covington wrote:
> > Hi,
> >
> > On 09/17/2015 01:38 PM, Shlomo
See inline.
On Thursday, September 17, 2015, Peter Maydell
wrote:
> On 17 September 2015 at 19:18, Shlomo Pongratz > wrote:
> > On Thursday, September 17, 2015, Peter Maydell >
> >> This still seems to have the same issues as were noted in previous
> >> round
Thanks
Please see inline
Best regards,
S.P.
On Thursday, September 17, 2015, Peter Maydell
wrote:
> On 17 September 2015 at 18:38, Shlomo Pongratz > wrote:
> > From: Shlomo Pongratz >
> >
> > This patch is a first step toward 128 cores support for arm64.
> &g
From: Shlomo Pongratz
Implement GIC-500 from GICv3 family for arm64
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported.
This is because the largest integer type has the size of 64 bits and modifying
essential data structures in order to support
From: Shlomo Pongratz
Add system instructions used by the Linux (kernel) GICv3
device driver
Signed-off-by: Shlomo Pongratz
---
target-arm/cpu-qom.h | 1 +
target-arm/cpu.h | 12 ++
target-arm/cpu64.c | 118 +++
3 files changed, 131
From: Pavel Fedin
I would like to offer this, slightly improved implementation. The key thing is
a new
kernel_irqchip_type member in Machine class. Currently it it used only by virt
machine for
its internal purposes, however in future it is to be passed to KVM in
kvm_irqchip_create(). The varia
From: Shlomo Pongratz
Add files need to maintain the GIC-500 state.
Signed-off-by: Shlomo Pongratz
---
hw/intc/arm_gicv3_common.c | 120 ++-
hw/intc/gicv3_internal.h | 161 +
include/hw/intc/arm_gicv3.h
From: Shlomo Pongratz
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported.
This is because largest integer type has the size of 64 bits and modifying
essential data structures in order to support 128 cores will require
the usage of bitops.
Things
...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
;CN=Shlomo Pongratz;X-NUM-GUESTS=0:mailto:shlomopongr...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
TRUE;CN=lav...@bezeqint.net;X-NUM-GUESTS=0:mailto:lav...@bezeqint.net
This patch doesn't apply on latest git commit i.e. 298fae389 from Sep 7.
Can you please rebase?
Best regards,
S.P.
On Friday, September 4, 2015, Peter Maydell
wrote:
> On 4 September 2015 at 07:49, Pavel Fedin > wrote:
> > Hi! This message is mainly for Peter. I say you reviewed my major sets,
> but looks like missed this
> > one. If it is OK, we could apply it, and i could successfully bring back
> the mis
On Monday, August 3, 2015, Peter Maydell wrote:
> On 3 August 2015 at 08:19, Pavel Fedin >
> wrote:
> > Hello!
> >
> >> > gicdev = qdev_create(NULL, gictype);
> >> > -qdev_prop_set_uint32(gicdev, "revision", 2);
> >> > +
> >> > +for (i = 0; i < vbi->smp_cpus; i++) {
> >> > +
Hi,
See inline.
On Friday, July 24, 2015, Peter Maydell wrote:
> On 24 July 2015 at 10:55, Pavel Fedin >
> wrote:
> > From: Shlomo Pongratz >
> >
> > This class is to be used by both software and KVM implementations of
> GICv3
> >
>
> > +++
Sorry, weekend.
But I'll test it as soon as possible.
S.P.
On Fri, Jul 24, 2015, 10:13 Pavel Fedin wrote:
> Hello!
>
> > This Doesn't compile, a problem with KVM_DEV_TYPE_ARM_VGIC_V2.
> > I assume this is include file issue as it exists in
> linux-headers/linux/kvm.h
> > Note that everything sh
Hi,
This Doesn't compile, a problem with KVM_DEV_TYPE_ARM_VGIC_V2.
I assume this is include file issue as it exists in
linux-headers/linux/kvm.h
Note that everything should compile also for TCG only.
Best regards,
S.P.
On Wednesday, July 22, 2015, Pavel Fedin wrote:
> This patch introduces k
See inline
On Wednesday, July 22, 2015, Christopher Covington
wrote:
> On 07/14/2015 04:45 AM, Peter Maydell wrote:
> > On 14 July 2015 at 09:32, Shlomo Pongratz > wrote:
> >> Hi,
> >>
> >> I'm running aarm64 QEMU and I'm counting the number of
Hi,
I'm running aarm64 QEMU and I'm counting the number of instructions which
"belong" to user space vs kernel space. My measurements shows that 99
percent of instructions are in kernel space.
I've used both the address of the instructions and the EL just to be sure.
I also added an option to disa
Jun 4, 2015 7:18 PM, "Peter Maydell" wrote:
> On 4 June 2015 at 17:40, Shlomo Pongratz wrote:
> > From: Pavel Fedin
>
> Hi. I think this patch largely makes sense, but I have some comments
> below. If you want to fix these and resend as a standalone patch
> I
From: Shlomo Pongratz
Implement GIC-500 from GICv3 family for arm64
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported for two reasons:
First the largest integer type has the size of 64 bits and modifying
essential data structures in order to
From: Shlomo Pongratz
Add system instructions used by the Linux (kernel) GICv3
device driver
Signed-off-by: Shlomo Pongratz
---
target-arm/cpu.h | 12 ++
target-arm/cpu64.c | 105 +
2 files changed, 117 insertions(+)
diff --git a
From: Shlomo Pongratz
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported for two reasons:
First the largest integer type has the size of 64 bits and modifying
essential data structures in order to support 128 cores will require
the usage of
ad of hardcoded CPUS_PER_CLUSTER
definition. This would allow to emulate real machines with different
layouts. However, in case of KVM we would still have to inherit IDs from
the host.
Signed-off-by: Shlomo Pongratz
Signed-off-by: Pavel Fedin
---
hw/arm/virt.c| 6 +-
target-arm/cpu-qom.h
From: Pavel Fedin
I would like to offer this, slightly improved implementation. The key thing is
a new
kernel_irqchip_type member in Machine class. Currently it it used only by virt
machine for
its internal purposes, however in future it is to be passed to KVM in
kvm_irqchip_create(). The varia
Hi
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Monday, 01 June, 2015 12:04 PM
> To: Shlomo Pongratz; qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; 'Ashok Kumar'
> Subject: RE: [Qemu-devel] [PATCH] Use Aff1 with mp
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Wednesday, 27 May, 2015 7:12 PM
> To: shlomopongr...@gmail.com
> Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1
Hi,
See below.
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Friday, 29 May, 2015 9:45 AM
> To: Shlomo Pongratz; qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; 'Ashok Kumar'
> Subject: RE: [PATCH] Use Aff1 with mpidr
>
; From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Friday, 22 May, 2015 1:33 PM
> To: qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; 'Ashok Kumar'; Shlomo Pongratz
> Subject: [PATCH] Use Aff1 with mpidr
>
> This is an improved and KVM-aware alternative to
&g
See below.
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Thursday, 28 May, 2015 12:30 PM
> To: Shlomo Pongratz
> Cc: shlomopongr...@gmail.com; qemu-devel@nongnu.org;
> peter.mayd...@linaro.org
> Subject: Re: [Qemu-devel] [PATCH RFC
> -Original Message-
> From: Igor Mammedov [mailto:imamm...@redhat.com]
> Sent: Wednesday, 27 May, 2015 7:12 PM
> To: shlomopongr...@gmail.com
> Cc: qemu-devel@nongnu.org; peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 1/4] Use Aff1
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Monday, 25 May, 2015 6:27 PM
> To: 'Eric Auger'; qemu-devel@nongnu.org; shlomopongr...@gmail.com;
> Shlomo Pongratz
> Subject: RE: [Qemu-devel] [PATCH RFC V2 2/4] Implment GIC-5
Hi Pavel,
No problem.
Best regards,
S.P.
On Friday, May 22, 2015, Pavel Fedin wrote:
> Hello!
>
> > Please find some more comments inline.
>
> Since there are notes about code style, i would add one more thing.
> structures of v3
> implementation keep old names (like GICState), and i would
On Friday, May 22, 2015, Pavel Fedin wrote:
> Hello!
>
> > The GIC-500 provides registers for managing interrupt sources, interrupt
> behavior, and interrupt
> > routing to one or more cores. It supports:
> > • Multiprocessor environments with up to 128 cores.
> > • Up to 32 affinity-level 1 clu
On Thursday, May 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > In order to support up to 128 cores with GIC-500 (GICv3 implementation)
> > affinity1 must be used. GIC-500 support up to 32 clusters with up to
> > 8 cores in a cluster. So for example, if one wishes to have 16 cores,
> > the options
> -Original Message-
> From: Eric Auger [mailto:eric.au...@linaro.org]
> Sent: Tuesday, 19 May, 2015 5:39 PM
> To: shlomopongr...@gmail.com; qemu-devel@nongnu.org
> Cc: peter.mayd...@linaro.org; Shlomo Pongratz
> Subject: Re: [Qemu-devel] [PATCH RFC V2 4/4] Add virtv2
Hi Pavel,
Please see in-line.
Best regards,
S.P.
From: Pavel Fedin [p.fe...@samsung.com]
Sent: Wednesday, May 13, 2015 4:57 PM
To: Shlomo Pongratz; qemu-devel@nongnu.org
Subject: RE: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500
Hello
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Tuesday, 12 May, 2015 3:33 PM
> To: Shlomo Pongratz; qemu-devel@nongnu.org
> Subject: RE: [PATCH v2] Add virt-v3 machine that uses GIC-500
>
> Hello!
>
> > BTW did you try going
> -Original Message-
> From: Pavel Fedin [mailto:p.fe...@samsung.com]
> Sent: Tuesday, 12 May, 2015 12:06 PM
> To: Shlomo Pongratz; qemu-devel@nongnu.org
> Subject: RE: [PATCH v2] Add virt-v3 machine that uses GIC-500
>
> Hello!
>
> > I just pulled last g
Hi Pavel,
Thank you,
I just pulled last git and git am-ed your patch on-top of my first 3 patches
and got this error:
/home/shlomo/qemu-new.git/qemu-64/hw/arm/virt.c: In function ‘fdt_add_gic_node’:
/home/shlomo/qemu-new.git/qemu-64/hw/arm/virt.c:366:17: error:
‘KVM_DEV_TYPE_ARM_VGIC_V3’ undec
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> > The issue is similar to what you have noticed.
>
> In this case it's probably not your fault.
>
> > The larger the number of smp cores it is more likely that the boot will
> get stuck.
> > I've commuted this patch series as an RFC becau
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> ➢ Thank you for your comment, I might do it after solving the stability
> issues.
>
> What kind of stability issues do you have ?
> You know, i was testing 64-bit qemu in TCG mode, and i have also seen
> weird behavior. The kernel just
On Thursday, May 7, 2015, Pavel Fedin wrote:
> Hello!
>
> Why do we need 'virt2' ? I am currently working on testing your
> implementation, and i try to use different approach. I see this as
> '-machine
> virt,gicv=N' option, where N is 2 or 3. Isn't it better than duplicating
> the
> whole vir
On 10 آذار, 2015 ص 09:06, Pei XiaoYong wrote:
于 2015/3/9 22:41, shlomo.pongr...@toganetworks.com 写道:
From: Shlomo Pongratz
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported for two reasons:
First the largest integer type has the size of 64
On 10 آذار, 2015 ص 03:18, Shannon Zhao wrote:
On 2015/3/9 22:41, shlomo.pongr...@toganetworks.com wrote:
From: Shlomo Pongratz
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported for two reasons:
First the largest integer type has the size of
On 09 آذار, 2015 م 05:13, Peter Maydell wrote:
On 9 March 2015 at 23:41, wrote:
From: Shlomo Pongratz
This patch is a first step toward 128 cores support for arm64.
At first only 64 cores are supported for two reasons:
First the largest integer type has the size of 64 bits and modifying
Hi Peter,
Thank you for your response.
You are correct, I'm implementing fully emulated GIC-500.
I assume that you are correct and indeed I have a bug in the implementation, I
think it is related to timing somehow as by adding debug printouts the system
is more likely to boot.
I'll prepare a RF
Hi,
I'm trying to implement GICv3 (actually GIC-500) in order to support more than
8 cores for ARM64.
Up to 24 cores I didn't notice any significant problems (just slow boot) but
with 64 or 32 cores the Linux kernel is usually got stuck, seldom it completes
the boot.
When examining the register
Hi,
I want to add a new PEX HW device emulation to QEMU, but I can't find a
skeleton/template driver or documentation that explains how to do it.
Are there any guidelines for this task?
Best regards,
S.P.
88 matches
Mail list logo