Re: Keystone Issue

[Marc Zyngier <maz@xxxxxxxxxx>]

On 2020-06-17 15:45, CodeWiz2280 wrote:
> On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > On 2020-06-16 19:13, CodeWiz2280 wrote:
> > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > >>
> > >> On 2020-06-15 20:14, CodeWiz2280 wrote:
> > >>
> > >> [...]
> > >>
> > >> > Also, the latest linux kernel still has the X-Gene storm distributor
> > >> > address as "0x78010000" in the device tree, which is what the Xen code
> > >> > considers a match with the old firmware.  What were the addresses for
> > >> > the device tree supposed to be changed to?
> > >>
> > >> We usually don't care, as the GIC address is provided by the
> > >> bootloader,
> > >> whether via DT or ACPI (this is certainly what happens on Mustang).
> > >> Whatever is still in the kernel tree is just as dead as the platform
> > >> it
> > >> describes.
> > >>
> > >> > Is my understanding
> > >> > correct that there is a different base address required to access the
> > >> > "non-secure" region instead of the "secure" 0x78010000 region?  I'm
> > >> > trying to see if there are corresponding different addresses for the
> > >> > keystone K2E, but haven't found them yet in the manuals.
> > >>
> > >> There is no such address. Think of the NS bit as an *address space*
> > >> identifier.
> > >>
> > >> The only reason XGene presents the NS part of the GIC at a different
> > >> address is because XGene is broken enough not to have EL3, hence no
> > >> secure mode. To wire the GIC (and other standard ARM IPs) to the core,
> > >> the designers simply used the CPU NS signal as an address bit.
> > >>
> > >> On your platform, the NS bit does exist. I strongly suppose that it
> > >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot
> > >> is possible to work around this.
> > >>
> > > I do have a question about this out to TI, but at least this method
> > > gives me something to work with in the meantime.  I was just looking
> > > to confirm that there wouldn't be any other undesirable side effects
> > > with Dom0 or DomU when using it.  Was there an actual FPGA for the
> > > X-Gene that needed to be updated which controlled the GIC access?  Or
> > > by firmware do you mean the boot loader (e.g. uboot).  Thanks for the
> > > support so far to all.
> >
> > As I said, the specific case of XGene was just a matter of picking the
> > right address, as the NS bit is used as an address bit on this 
> > platform.
> > This was possible because this machine doesn't have any form of
> > security. So no HW was changed, no FPGA reprogrammed. Only a firmware
> > table was fixed to point to the right spot. Not even u-boot or EFI was
> > changed.
> Ok, thank you for clarifying.  I have one more question if you don't
> mind.  I'm aware that dom0 can share physical memory with dom1 via
> grant tables.
> However, is it possible to reserve a chunk of contiguous physical
> memory and directly allocate it only to dom1?
> For example, if I wanted dom1 to have access to 8MB of contiguous
> memory at 0x8200_0000 (in addition to whatever virtual memory Xen
> gives it).
> How would one go about doing this on ARM?  Is there something in the
> guest config or device tree that can be set?  Thanks for you help.
That's a question for someone who understands Xen (KVM maintainer here, 
sorry).
My hunch is that you could simply represent this memory as a device, and 
map that "device" into the guest. You'd still need Xen to give you the 
right memory attributes so that you can map it cacheable at Stage-1.
        M.
--
Jazz is not dead. It just smells funny...