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

[Alistair Francis]

On Tue, Mar 1, 2016 at 4:07 PM, Peter Maydell <address@hidden> wrote:
> 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.

Yeah, I'll think about this and see if I can think of something.

>
>>> 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.

I didn't think of that, that's a good point.

I'll have a look on the mailing list to see what I can find. Right now
(I haven't looked yet) I'm thinking that maybe it would be a good idea
to rename the 'cpu' option to 'cpu-num' and allow it to specify a
number. Then when we have a standard CPU plan the 'cpu' property can
be extended to follow that and users can use either option.

>
>>> 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.)

Would it be too much on the user to ask them to specify the data
endianess they would like the data written in?  Then QEMU can convert
the data from the cpu endianess to the specified endianess.

Thanks,

Alistair

>
> thanks
> -- PMM
>