qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/4] linux-user: select CPU type according EL


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v3 0/4] linux-user: select CPU type according ELF header values
Date: Thu, 18 Jan 2018 14:33:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

Le 18/01/2018 à 14:17, Igor Mammedov a écrit :
> On Wed, 17 Jan 2018 17:15:38 +0100
> Laurent Vivier <address@hidden> wrote:
> 
>> Le 17/01/2018 à 16:49, Igor Mammedov a écrit :
>>> On Tue, 16 Jan 2018 23:22:08 +0100
>>> Laurent Vivier <address@hidden> wrote:
>>>   
>>>> This idea has been suggested to me before by Philippe
>>>> Mathieu-Daudé, and recently YunQiang Su has proposed a
>>>> patch to manage the MIPS r6 case.
>>>>
>>>> Based on this, this series tries to clean-up the original
>>>> patch, and introduces the use for m68k architecture and
>>>> port the patch from YunQiang Su.
>>>>
>>>> v3: fix code indent problem reported by patchew
>>>>     remove useless "!= 0"
>>>>     check for EF_M68K_M68000
>>>>     add EF_M68K_* flags in elf.h
>>>>     set 680x0 default CPU to m68040
>>>>     change "#if ... #endif" structure for ppc
>>>> v2: move cpu_model selection to linux-user/*/target_elf.h
>>>>     provide eflags to cpu_get_model() instead of fd
>>>>     (and modify other patches accordingly)  
>>> Sorry for not noticing it earlier, but could you please
>>> fix series to use cpu type names instead of cpu_model?
>>>
>>> I've just posted series that completes cpu_model refactoring
>>>   [PATCH 00/24] generalize parsing of cpu_model (part 4)
>>> which removes remnants of the code using cpu_model to
>>> instantiate CPUs, including reworking how default
>>> cpu type for *-user is picked up.
>>>
>>> After that cpu_model shouldn't be used anywhere in the code
>>> except of routines that process "-cpu" CLI and cpu types
>>> should be used directly.
>>>
>>> So you might not need 1/4 after that or it would have
>>> to be reworked and probably other patches where where
>>> cpu_model is used.  
>>
>> If I understand correctly, in linux-user/main.c we have to use
>> cpu_create() instead of cpu_init(), and provide the cpu_type instead of
>> the cpu_model?
> yes, that's what my series does.
> 
>> In linux-user/main.c, How can I detect we want to use the default one
>> (we were relying on "cpu_model == NULL" until now) to be able to compute
>> the default one from the ELF header?
> maybe something along this lines would do the job:
> 
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 4624cc9..c5d567f 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -43,6 +43,7 @@ static const char *filename;
>  static const char *argv0;
>  static int gdbstub_port;
>  static envlist_t *envlist;
> +/* default type in case it's not possible to deduce from program */
>  static const char *cpu_type = TARGET_DEFAULT_CPU_TYPE;
>  unsigned long mmap_min_addr;
>  unsigned long guest_base;
> @@ -4250,6 +4251,12 @@ static int parse_args(int argc, char **argv)
>      }
>  
>      filename = argv[optind];
> +    if (cpu_type is not set by user) {
> +        /* override default type if we can get it from executable */
> +        override_cpu_type = cpu_get_type(filename)
> +        if (override_cpu_type)
> +           cpu_type = override_cpu_type
> +    }
>      exec_path = argv[optind];
>  

No, because the fd can be provided by the kernel (with binfmt and
"open-binary" attribute, provided by getauxval(AT_EXECFD)), but I think
we can manage this in linux-user/main.c:main() by setting cpu_type to
NULL and calling cpu_get_type() to set it in this case.

Thanks,
Laurent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]