Re: [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support

2018-02-05 Thread Igor Mammedov
On Fri, 2 Feb 2018 17:54:43 +
Peter Maydell  wrote:

> On 26 January 2018 at 15:44, Philippe Mathieu-Daudé  wrote:
> > On 01/26/2018 11:33 AM, Peter Maydell wrote:  
> >> On 26 January 2018 at 14:29, Philippe Mathieu-Daudé  
> >> wrote:  
> >>> Why not use arm_any_initfn() here?  
> >>
> >> That function (and the 'any' cpu) are deliberately only
> >> included in the linux-user binaries, not the system-emulation binaries.  
> >
> > why not use the V8 features?  
> 
> What v8 features?
> 
> >> (Also arm_any_initfn() only initializes userspace-visible stuff, it
> >> doesn't provide ID register values etc for kernel-visible things.)  
> >
> > I'd still use an unique arm_max_initfn() such
> >
> >   // initializes userspace-visible stuff
> > #ifndef CONFIG_USER_ONLY
> >   // initializes kernel-visible things
> > #endif  
> 
> >>> Actually what seems cleaner is to move "any" features here, and kill the
> >>> "any" cpu, using "max" for this purpose.  
> >>
> >> We can't kill 'any', that would break back-compatibility
> >> of command lines.  
> >
> > and use an alias for 'any' -> 'max' or just
I'd suggest to place easy any -> max compat hack into
arm_cpu_class_by_name()

> >
> >   { .name = "any", .initfn = arm_max_initfn }, /* backward compat */  
> 
> Yes, we could probably do something similar to this.
> 
> thanks
> -- PMM
> 




Re: [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support

2018-02-02 Thread Peter Maydell
On 26 January 2018 at 15:44, Philippe Mathieu-Daudé  wrote:
> On 01/26/2018 11:33 AM, Peter Maydell wrote:
>> On 26 January 2018 at 14:29, Philippe Mathieu-Daudé  wrote:
>>> Why not use arm_any_initfn() here?
>>
>> That function (and the 'any' cpu) are deliberately only
>> included in the linux-user binaries, not the system-emulation binaries.
>
> why not use the V8 features?

What v8 features?

>> (Also arm_any_initfn() only initializes userspace-visible stuff, it
>> doesn't provide ID register values etc for kernel-visible things.)
>
> I'd still use an unique arm_max_initfn() such
>
>   // initializes userspace-visible stuff
> #ifndef CONFIG_USER_ONLY
>   // initializes kernel-visible things
> #endif

>>> Actually what seems cleaner is to move "any" features here, and kill the
>>> "any" cpu, using "max" for this purpose.
>>
>> We can't kill 'any', that would break back-compatibility
>> of command lines.
>
> and use an alias for 'any' -> 'max' or just
>
>   { .name = "any", .initfn = arm_max_initfn }, /* backward compat */

Yes, we could probably do something similar to this.

thanks
-- PMM



Re: [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support

2018-01-26 Thread Peter Maydell
On 26 January 2018 at 14:29, Philippe Mathieu-Daudé  wrote:
> Hi Peter,
>
> On 12/07/2017 03:14 PM, Peter Maydell wrote:
>> Add support for "-cpu max" for ARM guests. This CPU type behaves
>> like "-cpu host" when KVM is enabled, and like a system CPU with
>> the maximum possible feature set otherwise. (Note that this means
>> it won't be migratable across versions, as we will likely add
>> features to it in future.)
>>
>> Signed-off-by: Peter Maydell 
>> ---

>> +#ifndef TARGET_AARCH64
>> +/* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
>> host);
>> + * otherwise, a CPU with as many features enabled as our emulation supports.
>> + * The version of '-cpu max' for qemu-system-aarch64 is defined in cpu64.c;
>> + * this only needs to handle 32 bits.
>> + */
>> +static void arm_max_initfn(Object *obj)
>> +{
>> +ARMCPU *cpu = ARM_CPU(obj);
>> +
>> +if (kvm_enabled()) {
>> +kvm_arm_set_cpu_features_from_host(cpu);
>> +} else {
>> +cortex_a15_initfn(obj);> +/* In future we might add feature 
>> bits here even if the
>> + * real-world A15 doesn't implement them.
>> + */
>
> Why not use arm_any_initfn() here?

That function (and the 'any' cpu) are deliberately only
included in the linux-user binaries, not the system-emulation binaries.
(Also arm_any_initfn() only initializes userspace-visible stuff, it
doesn't provide ID register values etc for kernel-visible things.)

> Actually what seems cleaner is to move "any" features here, and kill the
> "any" cpu, using "max" for this purpose.

We can't kill 'any', that would break back-compatibility
of command lines.

thanks
-- PMM



Re: [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support

2018-01-26 Thread Philippe Mathieu-Daudé
Hi Peter,

On 12/07/2017 03:14 PM, Peter Maydell wrote:
> Add support for "-cpu max" for ARM guests. This CPU type behaves
> like "-cpu host" when KVM is enabled, and like a system CPU with
> the maximum possible feature set otherwise. (Note that this means
> it won't be migratable across versions, as we will likely add
> features to it in future.)
> 
> Signed-off-by: Peter Maydell 
> ---
>  target/arm/cpu-qom.h |  2 ++
>  target/arm/cpu.c | 24 
>  target/arm/cpu64.c   | 21 +
>  3 files changed, 47 insertions(+)
> 
> diff --git a/target/arm/cpu-qom.h b/target/arm/cpu-qom.h
> index a42495b..d135ff8 100644
> --- a/target/arm/cpu-qom.h
> +++ b/target/arm/cpu-qom.h
> @@ -33,6 +33,8 @@ struct arm_boot_info;
>  #define ARM_CPU_GET_CLASS(obj) \
>  OBJECT_GET_CLASS(ARMCPUClass, (obj), TYPE_ARM_CPU)
>  
> +#define TYPE_ARM_MAX_CPU "max-" TYPE_ARM_CPU
> +
>  /**
>   * ARMCPUClass:
>   * @parent_realize: The parent class' realize handler.
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 9304277..190da97 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1628,6 +1628,27 @@ static void pxa270c5_initfn(Object *obj)
>  cpu->reset_sctlr = 0x0078;
>  }
>  
> +#ifndef TARGET_AARCH64
> +/* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
> host);
> + * otherwise, a CPU with as many features enabled as our emulation supports.
> + * The version of '-cpu max' for qemu-system-aarch64 is defined in cpu64.c;
> + * this only needs to handle 32 bits.
> + */
> +static void arm_max_initfn(Object *obj)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +
> +if (kvm_enabled()) {
> +kvm_arm_set_cpu_features_from_host(cpu);
> +} else {
> +cortex_a15_initfn(obj);> +/* In future we might add feature 
> bits here even if the
> + * real-world A15 doesn't implement them.
> + */

Why not use arm_any_initfn() here?

Actually what seems cleaner is to move "any" features here, and kill the
"any" cpu, using "max" for this purpose.

> +}
> +}
> +#endif
> +
>  #ifdef CONFIG_USER_ONLY
>  static void arm_any_initfn(Object *obj)
>  {
> @@ -1691,6 +1712,9 @@ static const ARMCPUInfo arm_cpus[] = {
>  { .name = "pxa270-b1",   .initfn = pxa270b1_initfn },
>  { .name = "pxa270-c0",   .initfn = pxa270c0_initfn },
>  { .name = "pxa270-c5",   .initfn = pxa270c5_initfn },
> +#ifndef TARGET_AARCH64
> +{ .name = "max", .initfn = arm_max_initfn },
> +#endif

>  #ifdef CONFIG_USER_ONLY
>  { .name = "any", .initfn = arm_any_initfn },
>  #endif

and we can remove the last 3 lines.

> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 670c07a..38dcf32 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -28,6 +28,7 @@
>  #include "hw/arm/arm.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/kvm.h"
> +#include "kvm_arm.h"
>  
>  static inline void set_feature(CPUARMState *env, int feature)
>  {
> @@ -212,6 +213,25 @@ static void aarch64_a53_initfn(Object *obj)
>  define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
>  }
>  
> +/* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
> host);
> + * otherwise, a CPU with as many features enabled as our emulation supports.
> + * The version of '-cpu max' for qemu-system-arm is defined in cpu.c;
> + * this only needs to handle 64 bits.
> + */
> +static void aarch64_max_initfn(Object *obj)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +
> +if (kvm_enabled()) {
> +kvm_arm_set_cpu_features_from_host(cpu);
> +} else {
> +aarch64_a57_initfn(obj);
> +/* In future we might add feature bits here even if the
> + * real-world A57 doesn't implement them.
> + */
> +}
> +}
> +
>  #ifdef CONFIG_USER_ONLY
>  static void aarch64_any_initfn(Object *obj)
>  {
> @@ -240,6 +260,7 @@ typedef struct ARMCPUInfo {
>  static const ARMCPUInfo aarch64_cpus[] = {
>  { .name = "cortex-a57", .initfn = aarch64_a57_initfn },
>  { .name = "cortex-a53", .initfn = aarch64_a53_initfn },
> +{ .name = "max",.initfn = aarch64_max_initfn },
>  #ifdef CONFIG_USER_ONLY
>  { .name = "any", .initfn = aarch64_any_initfn },
>  #endif
> 



Re: [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support

2018-01-26 Thread Philippe Mathieu-Daudé
On 01/26/2018 11:33 AM, Peter Maydell wrote:
> On 26 January 2018 at 14:29, Philippe Mathieu-Daudé  wrote:
>> Hi Peter,
>>
>> On 12/07/2017 03:14 PM, Peter Maydell wrote:
>>> Add support for "-cpu max" for ARM guests. This CPU type behaves
>>> like "-cpu host" when KVM is enabled, and like a system CPU with
>>> the maximum possible feature set otherwise. (Note that this means
>>> it won't be migratable across versions, as we will likely add
>>> features to it in future.)
>>>
>>> Signed-off-by: Peter Maydell 
>>> ---
> 
>>> +#ifndef TARGET_AARCH64
>>> +/* -cpu max: if KVM is enabled, like -cpu host (best possible with this 
>>> host);
>>> + * otherwise, a CPU with as many features enabled as our emulation 
>>> supports.
>>> + * The version of '-cpu max' for qemu-system-aarch64 is defined in cpu64.c;
>>> + * this only needs to handle 32 bits.
>>> + */
>>> +static void arm_max_initfn(Object *obj)
>>> +{
>>> +ARMCPU *cpu = ARM_CPU(obj);
>>> +
>>> +if (kvm_enabled()) {
>>> +kvm_arm_set_cpu_features_from_host(cpu);
>>> +} else {
>>> +cortex_a15_initfn(obj);> +/* In future we might add 
>>> feature bits here even if the
>>> + * real-world A15 doesn't implement them.
>>> + */
>>
>> Why not use arm_any_initfn() here?
> 
> That function (and the 'any' cpu) are deliberately only
> included in the linux-user binaries, not the system-emulation binaries.

why not use the V8 features?

> (Also arm_any_initfn() only initializes userspace-visible stuff, it
> doesn't provide ID register values etc for kernel-visible things.)

I'd still use an unique arm_max_initfn() such

  // initializes userspace-visible stuff
#ifndef CONFIG_USER_ONLY
  // initializes kernel-visible things
#endif

> 
>> Actually what seems cleaner is to move "any" features here, and kill the
>> "any" cpu, using "max" for this purpose.
> 
> We can't kill 'any', that would break back-compatibility
> of command lines.

and use an alias for 'any' -> 'max' or just

  { .name = "any", .initfn = arm_max_initfn }, /* backward compat */

Anyway:
Reviewed-by: Philippe Mathieu-Daudé 

> 
> thanks
> -- PMM
>