On Thu, Jan 20, 2011 at 9:33 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2011-01-19 20:32, Blue Swirl wrote: >> On Wed, Jan 19, 2011 at 4:57 PM, Anthony Liguori >> <aliguori@xxxxxxxxxxxxxxxxxx> wrote: >>> On 01/19/2011 07:15 AM, Markus Armbruster wrote: >>>> >>>> So they interact with KVM (need kvm_state), and they interact with the >>>> emulated PCI bus. ÂCould you elaborate on the fundamental difference >>>> between the two interactions that makes you choose the (hypothetical) >>>> KVM bus over the PCI bus as device parent? >>>> >>> >>> It's almost arbitrary, but I would say it's the direction that I/Os flow. >>> >>> But if the underlying observation is that the device tree is not really a >>> tree, you're 100% correct. ÂThis is part of why a factory interface that >>> just takes a parent bus is too simplistic. >>> >>> I think we ought to introduce a -pci-device option that is specifically for >>> creating PCI devices that doesn't require a parent bus argument but provides >>> a way to specify stable addressing (for instancing, using a linear index). >> >> I think kvm_state should not be a property of any device or bus. It >> should be split to more logical pieces. >> >> Some parts of it could remain in CPUState, because they are associated >> with a VCPU. >> >> Also, for example irqfd could be considered to be similar object to >> char or block devices provided by QEMU to devices. Would it make sense >> to introduce new host types for passing parts of kvm_state to devices? >> >> I'd also make coalesced MMIO stuff part of memory object. We are not >> passing any state references when using cpu_physical_memory_rw(), but >> that could be changed. > > There are currently no VCPU-specific bits remaining in kvm_state. I think fields vcpu_events, robust_singlestep, debugregs, kvm_sw_breakpoints, xsave, xcrs belong to CPUX86State. They may be the same for all VCPUs but still they are sort of CPU properties. I'm not sure about fd field. > It may > be a good idea to introduce an arch-specific kvm_state and move related > bits over. This should probably contain only irqchip_in_kernel, pit_in_kernel and many_ioeventfds, maybe fd. > It may also once be feasible to carve out memory management > related fields if we have proper abstractions for that, but I'm not > completely sure here. I'd put slots, vmfd, coalesced_mmio, broken_set_mem_region, migration_log into the memory object. > Anyway, all these things are secondary. The primary topic here is how to > deal with kvm_state and its fields that have VM-global scope. If it is an opaque blob which contains various unrelated stuff, no clear place will be found. By the way, we don't have a QEMUState but instead use globals. Perhaps this should be reorganized as well. For fd field, maybe even using a global variable could be justified, since it is used for direct access to kernel, not unlike a system call. -- 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
