On 2011-01-21 19:49, Blue Swirl wrote: >>> 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.
Let's start with what is most urgent: - vmfd: file descriptor required for any KVM request that has VM scope (in-kernel device creation, device state synchronizations, IRQ routing etc.) - irqchip_in_kernel: VM uses in-kernel irqchip acceleration (some devices will have to adjust their behavior depending on this) pit_in_kernel would be analogue to irqchip, but it's also conceptually x86-only (irqchips is only used by x86, but not tied to it) and it's not mandatory for a first round of KVM devices for upstream. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
