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%)
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
© 2016 - 2024 Red Hat, Inc.