On Fri, Jan 21, 2011 at 5:21 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2011-01-21 17:37, Blue Swirl wrote: >> On Fri, Jan 21, 2011 at 8:46 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >>> ÂHi, >>> >>>> By the way, we don't have a QEMUState but instead use globals. >>> >>> /me wants to underline this. >>> >>> IMO it is absolutely pointless to worry about ways to pass around kvm_state. >>> ÂThere never ever will be a serious need for that. >>> >>> We can stick with the current model of keeping global state in global >>> variables. ÂAnd just do the same with kvm_state. >>> >>> Or we can move to have all state in a QEMUState struct which we'll pass >>> around basically everywhere. ÂThen we can simply embed or reference >>> kvm_state there. >>> >>> I'd tend to stick with the global variables as I don't see the point in >>> having a QEMUstate. ÂI doubt we'll ever see two virtual machines driven by a >>> single qemu process. ÂYMMV. >> >> Global variables are signs of a poor design. > > s/are/can be/. > >> QEMUState would not help >> that, instead more specific structures should be designed, much like >> what I've proposed for KVMState. Some of these new structures should >> be even passed around when it makes sense. >> >> But I'd not start kvm_state redesign around global variables or QEMUState. > > We do not need to move individual fields yet, but we need to define > classes of fields and strategies how to deal with them long-term. Then > we can move forward, and that already in the right direction. Excellent plan. > Obvious classes are > Â- static host capabilities and means for the KVM core to query them OK. There could be other host capabilities here in the future too, like Xen. I don't think there are any Xen capabilities ATM though but IIRC some recently sent patches had something like those. > Â- per-VM fields What is per-VM which is not machine or CPU architecture specific? > Â- fields related to memory management OK. I'd add fourth possible class: - device, CPU and machine configuration, like nographic, win2k_install_hack, no_hpet, smp_cpus etc. Maybe also irqchip_in_kernel could fit here, though it obviously depends on a host capability too. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
