Re: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500

[Shlomo Pongratz]

Hi Pavel,

Please see in-line.
Best regards,

S.P.

________________________________________
From: Pavel Fedin address@hidden
Sent: Wednesday, May 13, 2015 4:57 PM
To: Shlomo Pongratz; address@hidden
Subject: RE: [Qemu-devel] [PATCH v2] Add virt-v3 machine that uses GIC-500

 Hello!

> 1. In fdt_add_timer why you didn't used the 24 bit limit I posed on the 
> irqflags? Please
note that
> the argument is 32 bits wide and 8 bits are for flags.

  Simply missed it when checking for differences. Please fix. :) Perhaps it is 
the reason
why >=24 CPUs fail for you.

I wonder how it works for you. Do you aware of an alternative way to configure 
the clock irqflags for more then 24 cores, or is it just ignored. According to 
Linux documentation this fdt field sets the clock IRQ affinity.

My current status is as follows:
With 64 cores there is no printouts what so ever.  
With 32 cores the boot usually get stuck after the message "[   45.719102] SCSI 
subsystem initialized"
With 24 cores the system noontimes complete the boot and sometimes get stuck 
like the 32 cores system.

> 2. In machvirt_init, I used TYPE_AARCH64_CPU while you reverted it to 
> TYPE_ARM_CPU, I
> assume this is because you want to support cortex-a15. Don't you think It 
> should be
according
> to the cortex type?

 Yes, i just left it as it was because it already works fine with ARM64. 
Actually,
TYPE_AARCH64_CPU is a subclass of TYPE_ARM_CPU.

I see but I guess that I want aarch64_cpu_initfn to be called and not 
arm_cpu_initfn.

> (BTW you removed cortex-a53).

 Yes, because i didn't see how it is different from a57 (or a15). I tried to 
follow
minimal intervention principle.
 But perhaps i was wrong because there was real support for a53 added recently:
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg01304.html, so feel 
free to
re-add it back.

I agree with you I think this should wait for the patch you mentioned above to 
be integrated.

 BTW, just for interest, have you tried to do anything with KVM support of 
vGICv3? I have
some code but it's inherently unstable and lock up for unknown (yet) reason.

No, this is because I don't have an ARM64 based server needed for running KVM 
for ARM64.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia