KVM call agenda for 2013-01-29

Hi

Please send in any agenda topics you are interested in.

Later, Juan.

Am 28.01.2013 11:59, schrieb Juan Quintela:

Buildbot situation:
* Trees are not being added/updated in a timely fashion
* Insufficient build test coverage of trees (ppc, s390x, MinGW, BSD)

http://buildbot.b1-systems.de/qemu/builders

Stefan H. has access to some of the build slaves but not to the main buildbot server for configuration, it seems.

If Daniel does not have sufficient time to administer it, can we maybe have that set up on qemu.org instead, with more than one person that has access to it?

Regards,
Andreas

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Hi Andreas,

thanks for bringing this topic up.

January was quite busy month for me so far I could only handle minor changes on the buildbot. I hesitate to make larger changes to avoid I break other stuff. So I just queued them up once I have more time (beginning in February or so)

I bounced now all open request from you and the suggestion of Gerd (with regards to append the log on the mail) to Christian Berendt - who is also maintaining the buildbot on buildbot.b1-systems.de

Primary reason why I hesitated to add new trees in the last weeks is pretty simple:
- we run out of buildslave power
- lack of time to setup new buildslaves

If anyone has some spare time and could provide us for a longer period buildslaves please drop me and Christian a mail for further instruction.

With regards to the build test coverage for all trees we would have to refactor the configuration a lot to make it more easier to add and maintain it in an easy way.

If you have some time left feel free to come up with a patch for that. This is on my list - but it requires more time then I have available right now to make it "right".

(The failing macosx buildslave is known issue on the MacOSX site. The maintainer has also to investigate that at some later point due to lack of sufficient time.)

JFYI, the main buildbot configuration which controls everything (beside buildslave credentials) is accessible to everyone:
http://people.b1-systems.de/~gollub/buildbot/

If you are familiar with buildbot feel free to incorporate your suggested changes directly on a copy and send me or Christian the diff so we just have to review and apply it.

JFYI, I just requested if I am allowed to grant Stefan root access to our box. I would not mind to give him access - but need to check back with our IT first.

Best Regards,
Daniel

Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: [email protected]

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Hi Daniel,

Am 28.01.2013 15:29, schrieb Daniel Gollub:

[snip]

Some kind of reply indicating so would've been nice, you were already CC'ed last year a few times. ;)

Anyway, my point is that we are approaching Hard Freeze and seeing weekly pulls with recurring breakages on one or another platform (pci on ppc, s390x on mingw32). Some people have been assuming that if they don't get mails from the build bots then their tree is okay to merge.

Our shortened release cycle leads to two weeks of Soft Freeze where everyone pushes their queues before Feb 1 and most breakages occur. During Hard Freeze we can still try to fix anything the bots report, but catching errors before they land in master would be better:

At QEMU Summit Anthony requested that each submaintainer's tree be added to the buildbot system; if there are as you now indicate build power shortages, I suggest you specify what exactly is needed, maybe someone in the community can help out. To me it was not clear at least. The revived ppc slave is hopefully not running into a bottleneck yet. :)

I'll take a look at the config later.

Thanks,
Andreas

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Thanks offering this. Unfortunately I can't accept because I'm at the limit of keeping up with my other QEMU responsibilities. I don't have enough time to do this job well.

Gerd: Are you willing to co-maintain the QEMU buildmaster with Daniel and Christian? It would be awesome if you could do this given your experience running and customizing buildbot.

Stefan

Hi,

I'll try to set aside some time for that. Christians idea to host the config at github is good, that certainly makes it easier to balance things to more people.

Another thing which would be helpful: Any chance we can setup a maintainer tree mirror @ git.qemu.org? A single repository where each maintainer tree shows up as a branch?

This would make the buildbot setup *alot* easier. We can go for a AnyBranchScheduler then with BuildFactory and BuildConfig shared, instead of needing one BuildFactory and BuildConfig per branch. Also makes the buildbot web interface less cluttered as we don't have a insane amount of BuildConfigs any more. And saves some resources (bandwidth + diskspace) for the buildslaves.

I think people who want to look what is coming or who want to test stuff cooking it would be a nice service too if they have a one-stop shop where they can get everything.

cheers,
Gerd

I will setup a tree based on the 'T:' fields in MAINTAINERS. So if you want your tree to be part of buildbot, please make sure that you have a correct entry in MAINTAINERS.

Regards,

Anthony Liguori

I sent a pull request that makes the BuildFactory definitions simpler using a single create_build_factory() function:

https://github.com/b1-systems/buildbot/pull/1

Keep in mind that BuildFactories differ not just by repo/branch but also:
* in-tree or out-of-tree
* extra ./configure arguments
* gmake instead of make

I think this means it is not as simple as defining a single BuildFactory.

Stefan

Stefan, I'll have a look later this day.

Christian.

Christian Berendt
Tel.: +49-171-5542175
Mail: [email protected]

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

I merged the two pending pull requests and added the configurations of the qemu-kvm and kvm buildbots to the GitHub repository.

The daily cronjob on the buildbot system is now active and the configuration provided on GitHub will now be used.

The open change requests will be processed tomorrow.

Hope everything is still working, if not drop me a line.

Christian.

Christian Berendt
Solution Architect
Mail: [email protected]

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Excellent, thank you!

Stefan

I moved the configuration on GitHub (https://github.com/b1-systems/buildbot). I'll add a cron job to the buildbot system to regular pull and apply the latest configuration. Simply open a pull request to modify the configuration.

I'll implement open requests for configuration changes as soon as possible (should be done tomorrow).

Christian.

Christian Berendt
Solution Architect
Mail: [email protected]

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Thanks Christian! I have updated the QEMU wiki page:

http://wiki.qemu.org/ContinuousIntegration

Stefan

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.

Regards,

Anthony Liguori

- What's the plan for -device and IRQ assignment?

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

Alex

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]" ?

-- PMM

Am 28.01.2013 11:59, schrieb Juan Quintela:

I/O port rework:
* Proposal by Hervé: move I/O port list registration to ISA
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html

This causes modeling issues since PCI VGA/QXL then register I/O ports via ISADevice API (using NULL ISADevice* argument) and require an ISABus in machines that may not have one (e.g., New World Macs). (kind of a QOM multi-inheritence issue)

Trivial conversion patches were reviewed by me and merged already. Remaining question is how to proceed conceptually and design-wise in lack of memory and ISA maintainers.

Background is that ppc has no concept of PIO and needs a "forwarding" from PCI I/O MemoryRegion to PIO currently:
http://git.qemu.org/?p=qemu.git;a=commit;h=a178274efabcbbc5d44805b51def874e47051325
http://git.qemu.org/?p=qemu.git;a=commit;h=a3cfa18eb075c7ef78358ca1956fe7b01caa1724

Regards,
Andreas

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg