qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework
Date: Thu, 03 Jun 2010 08:11:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

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




reply via email to

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