From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48464 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OM1Sy-0006CM-UK for qemu-devel@nongnu.org; Tue, 08 Jun 2010 12:15:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OM1Sx-0004Uk-4I for qemu-devel@nongnu.org; Tue, 08 Jun 2010 12:15:52 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:48012) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OM1Sw-0004UV-VR for qemu-devel@nongnu.org; Tue, 08 Jun 2010 12:15:51 -0400 Received: by gyd5 with SMTP id 5so3399476gyd.4 for ; Tue, 08 Jun 2010 09:15:50 -0700 (PDT) Message-ID: <4C0E6CB2.20507@codemonkey.ws> Date: Tue, 08 Jun 2010 11:15:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com> <201006081530.19546.paul@codesourcery.com> <4C0E6199.6030706@codemonkey.ws> <201006081636.12242.paul@codesourcery.com> <4C0E6894.9000901@redhat.com> In-Reply-To: <4C0E6894.9000901@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Glauber Costa , Paul Brook , qemu-devel@nongnu.org On 06/08/2010 10:58 AM, Paolo Bonzini wrote: > On 06/08/2010 05:36 PM, Paul Brook wrote: >>>> Once you eliminate machine_register_core that knowledge has >>>> >>>> somehow got to come from your device tree description file. Having a >>>> single device tree that can morph into significantly different >>>> machines >>>> seems like unnecessary complexity given this is a user-specified file. >>> >>> 99% of qemu users will never touch a device tree. The practical matter >>> is, we're going to have to provide higher level interfaces that allow a >>> user to significantly morph a base device tree into something >>> different. >> >> That's the bit I don't get. Why are we significantly morphing a base >> device >> tree? Surely it's easier to just use a different base tree. > > Because at some point the base tree will have to be written in C. Of > course you have to decide where to stop allowing customization, but > anyway it will be significantly more complex than a QemuOpts config > file. QemuOpts obviously doesn't have the flexibility to create an > entire device tree. > > Want to let the user add an IDE controller? Fine, you need to provide > him with a way of writing the following logic: > > for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) { > hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS); > } > pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1); > > What do you do? Invent your own language (another YaST? no thanks)? > Massive refactoring of QEMU's bowels (cannot solve all the problems, > Anthony gave more examples in the email I replied to)? Keep C code > (then you're not doing anything different than what Anthony's > MachineCore is doing)? Or punt all of the complexity to the user such that have to manually figure out where in the device tree a drive has to be inserted. That's not really reasonable IMHO. > I think there are four choices: > > 1) only merge the first 5-7 patches of the series, basically up to the > creation of -machine and conversion of -kernel/-initrd/-M/-m. This is > also what is needed for KVM's irqchip. Think about some other smart > way to implement default devices. Or don't declare MachineCore options stable across releases. I concur that we probably don't want to support some of these interfaces long term but I think we can pretty quickly figure out some better interfaces. The advantage of a full conversion is that it allows us to focus on improving the interfaces since we'll have the architecture in place. > 2) do not expose some things to the config files. This requires > implementing an additional QemuOpts feature for internal options, plus > the current patchset. It means that moving machine types out to > config files is not possible. I dislike having internal only options as it means we have to keep things within qemu. For things like max_cpus, I think we just need to validate that we've got passed sane values. Setting max_cpus in a global config is actually a really useful thing for downstreams to do since they are all having a fixed support statement of X VCPUs per VM. > 3) put some things into an implementation-dependent namespace, i.e. > __pci or __default_device or __serial. In the future it's possible to > these things in config files, just nobody has to worry about users > relying on them and can refactor to death. This is the current > patchset plus some search and replace, and is my favorite. Yeah, I'm good with being explicit. I'd prefer x-pci or x-serial since we've already established that as the experimential namespace. > 4) expose everything to the user, at the cost of regretting it later. > This is the current patchset. > > > One "smart way to implement default devices" could be an inclusion > mechanism where a machine can ask qemu to read other config files. > Then you'd have config files for the default serial/parallel/etc. > This could also be implemented on top of choices 2/3/4 though. Default devices are a real pain. Fortunately, we only mess with it in s390 so I'm fairly certain we can simplify things considerable. It's just not something I wanted to tackle in this series. Regards, Anthony Liguori > Paolo