On Thu, Apr 10, 2014 at 10:02 AM, Peter Maydell
<peter.maydell@xxxxxxxxxx> wrote:
> On 17 March 2014 07:12, Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx> wrote:
>> On Fri, Mar 7, 2014 at 5:33 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
>>> Support the Cortex-A57 in the virt machine model.
>>>
>>> Signed-off-by: Peter Maydell <peter.maydell@xxxxxxxxxx>
>>> ---
>>> This should perhaps not be just stealing the a15mpcore_priv
>>> on the basis that it's a GICv2...
>>
>> Wont this mean you gets lots of extraneous hardware? Although, with a
>> pure virtual machine I guess you can do whatever you really want.
>
> No, a15mpcore_priv only has a GIC in it.
>
>>> ---
>>> hw/arm/virt.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index 517f2fe..d985d2e 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -123,6 +123,14 @@ static VirtBoardInfo machines[] = {
>>> .irqmap = a15irqmap,
>>> },
>>> {
>>> + .cpu_model = "cortex-a57",
>>> + /* Use the A15 private peripheral model for now: probably wrong! */
>>> + .qdevname = "a15mpcore_priv",
>>
>> Can you just change this to gics qdev name? The qdev propnames of gic
>> and mpcore ("num-cpu" and "num-irq") should just match. Then perhaps a
>> little callback to set gicv2 version property.
>
> That would miss the other thing a15mpcore_priv does for us,
> which is to wire up the generic timer outputs from the CPU
> objects to the appropriate GIC inputs. (Also the gpio_in
> lines on a15mpcore_priv and the gic itself are not the
> same: a15mpcore_priv only exposise the SPIs.)
>
> We could in theory write an a57mpcore_priv which was a
> carbon copy of a15mpcore_priv, but that seems a bit pointless.
> I think it's probably actually reasonable to use a15mpcore_priv
> here, with an appropriate comment:
>
> /* Our A57 has an A15-style GICv2, so we can use a15mpcore_priv */
I think there are 3 possibilities of what actual h/w may look like. i
agree this is the correct thing to do for one case (and is the only
one qemu is able to support today). The others are:
A57 + SBSA compliant GICv2(M)
A57 + GICv3
The SBSA change is making each register bank within the GIC 64K spaced
instead of 4K spaced to support 64KB pages in OSs and hypervisors.
This is a simple address swizzling trick defined in the SBSA doc.
(Since it's documented it must not be a cute embedded nonsense hack.
:)) Then the M portion is for PCI MSI support which is optional.
Rob
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
