[Qemu-devel] KVM developer call minutes (Jan 12)

[Qemu-devel] KVM developer call minutes (Jan 12)

[Chris Wright]

Attendees: Avi, Dor, Gleb, Michael, Chris, Juan, John, Kevin, Armbru, Amit,
Anthony, Glauber, AlexW, AlexG, Luiz, Jes

Minutes (please reply w/ corrections or follow-ups):
- administrivia
  - no plan to do formal attendance
    - above attendance list is approximate
  - discussion focused on issues relevant to KVM upstream development
  - will try recording the call
  - will produce minutes
- qemu 0.13 kvm feature merge issues
  - looking for post-mortem analysis on what worked and didn't for 0.12 release
    - need harder policy re: feature freeze
  - Is a longer release cycle OK?  Planning for June 1 (6 month vs 3 month)
    - no real objections
    - what about the version?  are we ready for 1.0?
      - going to 1.0 makes sense if we can merge KVM support
  - mtloop (from malc) vs i/o thread 
    - SIGALRM vs. select() timeout
  - SMP changes
    - drop current patchset
    - irqchip conversion
  - need to move to normal main loop, instead of KVM specific main loop
  - eventfd, signalfd, etc..
    - compatibility across platforms is complicated
    - either drop use of signalfd, or create higher-level abstraction
      - higher-level abstraction makes most sense
  - common mechnaism for vcpu locking, vcpu thread launching, etc. for
    device model threading
  - live migration in the I/O thread is showing performance limitation
  - need some more release sync w/ qemu and kvm
    - different developer and user bases
      - lots of feedback from KVM users when qemu-kvm rebases
    - Avi considering restarting snapshot releases
    - already doing regular weekly (or more often for invasive features)
      merges w/ qemu.git
    - unclear there's antything that needs to be done here
  - will qemu-kvm deprecate IA-64?
    - no need to actively remove unless it is in the way or gets to the
      point that it is hopelessly broken
- vhost-net todo's
  - more patch review needed
  - some concern about security implications re: socket binding to qemu
    - needs more eyes
  - current version supports level interrupts
  - anyone interested in working on DMA offloading w/ engine like IOAT 
    - possible to expose DMA engine to guest in virtio?