Re: [Qemu-devel] [PATCH v2] target-arm: Extract some external ARM CPU API

[Peter Crosthwaite]

On Tue, Oct 27, 2015 at 7:18 AM, Pavel Fedin <address@hidden> wrote:

 Hello!

> But Peter C has a better grasp of the current status of
> multiarch than I do, so if he prefers using obj-y then
> I'm happy to take his recommendation.

 I am neutral, and i will accept any solution. OTOH, he agreed with my proposal too, and even promised to pick it up into his patchsets, but suggested to change include pathname to include/hw/arm/cpu.h. And i have the last concern about it because hw/arm/ is a place where board-specific includes are placed.
 Additionally, we already have three more specific ARM CPU files in include/hw/cpu/, so they just look nice together.

 And you know... Theoretically... As far as i can understand, multi-arch is a way to enable emulation of heterogeneous systems, which combine different CPUs. Am i right about it? In this case, what if in future we have some heterogeneous HW, where e.g. ARM and x86 are interoperating using system registers? In this case, x86-targeted qemu code would probably have to talk to ARM-targeted one. And having this API separated from the inner CPU guts would only help.
 Compared to this architectural improvement, obj-y looks like very simple way to ignore, but not to solve the problem. :)

 So, Peter C, what is your final decision?

If there are no dependent patches on list that are 2.5 candidate, I suggest we just drop this one for the short term. Is there something on list?

I have no objection to the obj-y solution medium term, as there are already multiple users of the ARM CP API using their obj-y privileges to access it. Certainly don't wait on MA to send your patches. These obj-y's will need to be converted en-masse so adding GIC to the list of TBDs is not a big issue IMO. So I would just prepend the obj-y conversion as P1 of the series implementing your GIC CP functionality.

Note that multi-arch does not multiple-compile obj-y for the MA build itself. There is still only one compile of obj-y for the MA binary. The basic guideline is:

common-obj-y -> Compiled only once absolutely

obj-y -> Multiple compiled per output binary

arch-obj-y -> Multiple compiled per output binary and multiple compiled per CPU arch within multi-arch build

Ideally obj-y eventually evaporates. Genuinely CPU specific stuff and performance sensitive stuff (like the TCG translate+execute) are converted from obj-y to arch-obj-y. The current multi-arch work does this:

https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg03929.html

Everything else should be common-obj-y. So the follow up is to remove the (mostly false) deps of device land on CPU-target specifics. So we should do what your patch is doing only, on a much bigger scale. But the obj-y conversion won't inhibit multi-arch functionality.

Regards,

Peter

 

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia