Skip to contentSkip to conversation

KVM Call agenda 2013-01-29

DISCUSSION Juan Quintela 1 participant 1 message Jan 29, 2013 KVM

lore
Share & tools
lore
#0 lore raw

As Today there were lots of topics, here is a collapsed agenda, basically three main topics now that Buildbot is dropped:

* Buildbot: discussed on the list (Andreas retired it)

* Replacing select(2) so that we will not hit the 1024 fd_set limit in the future. (stefan)

* Outstanding virtio work for 1.4
- Multiqueue virtio-net (Amos/Michael)
- Refactorings (Fred/Peter)
- virtio-ccw (Cornelia/Alex)
We need to work out the ordering here and what's reasonable to merge over the next week.

* What's the plan for -device and IRQ assignment? (Alex)

We need to start coming up with a solution to connect irq lines between cmdline created devices and interrupt controllers. Currently, I'm aware of 2 potential users

- virtio-mmio
- device assignment on platform devices

I see 2 options:

- create a new platform bus that enumerates IRQs linearly, similar to how the ISA bus works
- allow arbitrary irq pin connection using a global pin namespace

Surely what you want is to specify IRQ connections via something like "my-uart.irq => interrupt-controller.in[14]" (adjust punctuation to taste)?

They're just device-to-device connections.

You also need some way of specifying where in a memory map mmio devices should live. This is a little tricky because you don't want to assume a global flat address space (in future if we get the memory APIs right then devices could be in the address space of just one of 4 CPUs, for instance).

      "my-uart.regs => cpu1.memory[0x4000..0x4100]" ?