[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] KVM call minutes for Mar 23
From: |
Chris Wright |
Subject: |
[Qemu-devel] KVM call minutes for Mar 23 |
Date: |
Tue, 23 Mar 2010 08:08:07 -0700 |
User-agent: |
Mutt/1.5.20 (2009-08-17) |
migration (we didn't end last week)
- monotonic increasing version doesn't capture individual features
(backporting features may not require earlier features, now id is
incorrect)
- use subsections
- can create new namespace within subsection (ide/$featre/$distro)
- would need to coordinate section naming
- documentation of on-wire migration protocol needed, can be there
- rewind file (non-trivial) to update version to earlier id
- send maximum always, not worrying about non-linear feature creep
virtIODevice model (see Virtio cleaup thread). What is the best model for this?
- multiple inheritance concern...far enough away, can handle on list,
nothing pressing here
state and roadmap for upstream merge of in-kernel device models
- glauber has posted, received feedback, working through feedback,
will respin and repost soon
merging qemu-kvm.git's implementation as is and cleaning it up in qemu.git?
- would need to drop features, so people will still use qemu-kvm
- extboot, ia64, in-kernel pit, device assignment, associated cmd line options
- the biggest blocking is glauber's smp/irq chip
- kvmctl (ported to qemu now) could go into
- agraf glad to help w/ device assignment
- avi wants to move it to uio + irqfd
(need uio iommu support and msi support)
libqemu and libvirt
- simple qmp wrapper would be enough
- would drop the libvirt functionality (like hv agnostic)
- separate issues...
- 1) libqemu as a simple mgmt interface to qemu
- 2) libvirt qemu-direct, libvirt users ability to get all qemu features
- approaching from different ends of problem...could coexist.
- out of time...next week, on list in the interim
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] KVM call minutes for Mar 23,
Chris Wright <=