The EL2 and EL3 work is working well now and interanlly we now have
tests that expect to start in EL3 and transition through EL2 to EL1. To
make this easy to run let's expose the secure property to the machine
and then use that to enable EL2.

This series also does some machine/name tidying up and makes the first
move to deprecating the EP108 machine, which was just an early access
development board.

Alistair Francis (5):
  xlnx-ep108: Rename to ZCU102
  xlnx-zcu102: Manually create the machines
  xlnx-zcu102: Add a machine level secure property
  xlnx-zynqmp: Allow the secure prop to enable EL2
  xlnx-zcu102: Mark the EP108 machine as deprecated

 hw/arm/Makefile.objs                   |   2 +-
 hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} | 131 ++++++++++++++++++++++++++++-----
 hw/arm/xlnx-zynqmp.c                   |   2 +-
 3 files changed, 114 insertions(+), 21 deletions(-)
 rename hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} (51%)

-- 
2.11.0

On Thu, Aug 17, 2017 at 11:51:59AM -0700, Alistair Francis wrote:
> The EL2 and EL3 work is working well now and interanlly we now have
> tests that expect to start in EL3 and transition through EL2 to EL1. To
> make this easy to run let's expose the secure property to the machine
> and then use that to enable EL2.
> 
> This series also does some machine/name tidying up and makes the first
> move to deprecating the EP108 machine, which was just an early access
> development board.

Hi Alistair,

Reconsidering this, I tend to agree that we're probably better off with
EL2/no-GICv2-virt compared to the possible confusiong of having EL2
without GICv2-virt..

But I wonder if we should have similar options as the virt machine?
I.e, a virtualization option to enable EL2.

Cheers,
Edgar


> 
> Alistair Francis (5):
>   xlnx-ep108: Rename to ZCU102
>   xlnx-zcu102: Manually create the machines
>   xlnx-zcu102: Add a machine level secure property
>   xlnx-zynqmp: Allow the secure prop to enable EL2
>   xlnx-zcu102: Mark the EP108 machine as deprecated
> 
>  hw/arm/Makefile.objs                   |   2 +-
>  hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} | 131 ++++++++++++++++++++++++++++-----
>  hw/arm/xlnx-zynqmp.c                   |   2 +-
>  3 files changed, 114 insertions(+), 21 deletions(-)
>  rename hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} (51%)
> 
> -- 
> 2.11.0
> 

On Tue, Aug 22, 2017 at 10:24 AM, Edgar E. Iglesias
<edgar.iglesias@xilinx.com> wrote:
> On Thu, Aug 17, 2017 at 11:51:59AM -0700, Alistair Francis wrote:
>> The EL2 and EL3 work is working well now and interanlly we now have
>> tests that expect to start in EL3 and transition through EL2 to EL1. To
>> make this easy to run let's expose the secure property to the machine
>> and then use that to enable EL2.
>>
>> This series also does some machine/name tidying up and makes the first
>> move to deprecating the EP108 machine, which was just an early access
>> development board.
>
> Hi Alistair,
>
> Reconsidering this, I tend to agree that we're probably better off with
> EL2/no-GICv2-virt compared to the possible confusiong of having EL2
> without GICv2-virt..
>
> But I wonder if we should have similar options as the virt machine?
> I.e, a virtualization option to enable EL2.

That's fine with me.

Just to clarify do you think we should keep the secure option for EL3
and add a virt option for EL2?

Thanks,
Alistair

>
> Cheers,
> Edgar
>
>
>>
>> Alistair Francis (5):
>>   xlnx-ep108: Rename to ZCU102
>>   xlnx-zcu102: Manually create the machines
>>   xlnx-zcu102: Add a machine level secure property
>>   xlnx-zynqmp: Allow the secure prop to enable EL2
>>   xlnx-zcu102: Mark the EP108 machine as deprecated
>>
>>  hw/arm/Makefile.objs                   |   2 +-
>>  hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} | 131 ++++++++++++++++++++++++++++-----
>>  hw/arm/xlnx-zynqmp.c                   |   2 +-
>>  3 files changed, 114 insertions(+), 21 deletions(-)
>>  rename hw/arm/{xlnx-ep108.c => xlnx-zcu102.c} (51%)
>>
>> --
>> 2.11.0
>>

On 22 August 2017 at 18:57, Alistair Francis
<alistair.francis@xilinx.com> wrote:
> On Tue, Aug 22, 2017 at 10:24 AM, Edgar E. Iglesias
> <edgar.iglesias@xilinx.com> wrote:
>> On Thu, Aug 17, 2017 at 11:51:59AM -0700, Alistair Francis wrote:
>>> The EL2 and EL3 work is working well now and interanlly we now have
>>> tests that expect to start in EL3 and transition through EL2 to EL1. To
>>> make this easy to run let's expose the secure property to the machine
>>> and then use that to enable EL2.
>>>
>>> This series also does some machine/name tidying up and makes the first
>>> move to deprecating the EP108 machine, which was just an early access
>>> development board.
>>
>> Hi Alistair,
>>
>> Reconsidering this, I tend to agree that we're probably better off with
>> EL2/no-GICv2-virt compared to the possible confusiong of having EL2
>> without GICv2-virt..
>>
>> But I wonder if we should have similar options as the virt machine?
>> I.e, a virtualization option to enable EL2.
>
> That's fine with me.
>
> Just to clarify do you think we should keep the secure option for EL3
> and add a virt option for EL2?

I think unless you have a really strong reason to be different
(eg back-compat with existing guests) then following what
the 'virt' board does for machine options is probably going
to be least confusing. NB that that does include letting you
specify some combos that don't work, like gicv2 + virt...

(We should really get round to implementing virt support in
the GICv2, though.)

thanks
-- PMM