Re: [Qemu-devel] [PATCH v3 1/2] generic-loader: Add a generic loader

[Peter Maydell]

On 1 March 2016 at 23:56, Alistair Francis <address@hidden> wrote:
> On Fri, Feb 26, 2016 at 8:22 AM, Peter Maydell <address@hidden> wrote:

>> Writing directly to cpu->as is not very generic. In particular,
>> how should this interact with TrustZone, where you might want to
>> write the image to the Secure address space?
>
> Hmmm.... Good point. Do you have any ideas for a solution?

Not really. For loading images into the virt board's secure-only
flash I took the approach of having the loader let you load
into a particular MemoryRegion, and then wiring up -bios etc
to be "load into this device" rather than "load at this address".
But that could be awkward to specify for the user.

>> Is the internal QEMU CPU index really the right thing to expose to
>> the user? Should we be considering letting the user specify by
>> MPIDR or some other thing? By path-to-CPU-in-QOM-tree?
>
> I don't have a problem with numbers. I don't see it as too confusing
> as it is generally pretty obvious which CPU you are targeting. It also
> matches what the 'info cpus' command prints. The kernel also just uses
> numbers when printing out CPU info. Plus I would consider this a more
> advanced feature. People who don't know about the CPUs in the system
> can still use -kernel.

The difficulty is that command line UI is ABI for us -- once
we pick it we're stuck with it. So we need to be sure we
get it right...

>> (We should be consistent with however the user specifies CPUs
>> for things like CPU hotplug, anyway.)

...hence this hint to try to find out how we're already
specifying (or planning to specify) CPUs elsewhere.

>> Doesn't defining this as a UINT64 property mean that the same qemu
>> command line will write different data on a big-endian and little-endian
>> host ?
>
> Yeah, I'm not really sure what to do here. All my use cases are both
> LE, so I don't have any test cases.
>
> If I am understanding this right I should swap the bytes if the host
> and guest endianess are different?

You need to first define what you want as a user interface,
ie what you mean when you say data=0x123456. Then you can
figure out what the right way to convert that to the values
to write into the guest memory. (You might decide that the
user-facing UI really needs to be something more flexible
or less confusing than "here's a number which I'm going to
convert into a byte string somehow".)

Your constraints are that the same command line must do the
same thing on any host, and that you want it to "make sense"
to the user whether the guest CPU is big or little endian.
(This is why I'm not sure about data=0x12345678, because the
natural interpretation of that depends on CPU endianness.)

thanks
-- PMM