On Fri, Jan 21, 2011 at 6:17 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2011-01-21 19:04, Blue Swirl wrote: >> 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? > > I think it would suffice for a first step to consider all per-VM fields > as independent of CPU architecture or machine type. I'm afraid that would not be progress. >>> Â- 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. > > I would count everything that cannot be assigned to a concrete device > upfront to the dynamic state of a machine, thus class 2. The point is, > (potentially) every device of that machine requires access to it, just > like (indirectly, via the KVM core services) to some KVM VM state bits. The machine class should not be a catch-all, it would be like QEMUState or KVMState then. Perhaps each field or variable should be listed and given more thought. -- 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
