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. > >> - 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
