[Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 06/03/2010 01:07 AM, Jan Kiszka wrote:
> Glauber Costa wrote:
>    
>> On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote:
>>      
>>>>
>>>> +QemuOptsList qemu_machine_opts = {
>>>> +    .name = "M",
>>>> +    .head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head),
>>>> +    .desc = {
>>>> +        {
>>>> +            .name = "mach",
>>>> +            .type = QEMU_OPT_STRING,
>>>> +        },{
>>>> +            .name = "irqchip",
>>>> +            .type = QEMU_OPT_STRING,
>>>> +        },
>>>>          
>>> Can't we make the concrete machine define what options it needs? Pushing
>>> this into the generic code may soon end up in a bunch of very special
>>> switches that are unused on most machines or even have no meaning for them.
>>>
>>> Also, I would suggest to introduce the generic part first, and then add
>>> first users like the x86 irqchip.
>>>        
>> Yeah, in general, I do agree with you.
>>
>> Me and anthony talked about it for a while some time ago, and more or less
>> concluded that it could be possible to avoid that, putting a little think
>> which options to add.
>>
>> the "irqchip" option, if you note, is not x86-specific, in any case.
>> Any machine has an irqchip.
>>      
> ...but the majority has no choice among different models. This option
> simply makes only sense for x86 now and in the foreseeable future.
>
>    
>> The first idea was to use something like
>> "apic=in_kernel|userspace" which would be, that, very x86-centric.
>>
>> So, since letting machines define their own options adds complexity,
>> my take would be to add those common options, and add infrastructure
>> for machine-specific options when we see something that makes it
>> unavoidable.
>>
>> What do you think?
>>
>>      
> I have no general concerns if you document irqchip as a x86-only machine
> option without effect on other machines and you promise to clean this up
> once done with in-kernel irqchip support (which is clearly more
> important). But the current design should not stay that way for a longer
> period to avoid what I sketched above.
>    

What I think we need to do is actually use an empty QemuOptsList for the 
-machine option, make sure that the driver is present, then re-validate 
the list with a QemuOptsList that's included in the machine state.

We should, of course, have a #define of MACHINE_COMMON_OPTS.  This would 
allow machine specific options (like irqchip).  I don't think irqchip is 
the best name really.  I think it should be apic=kernel|user.

Regards,

Anthony Liguori

> Jan
>