1:46 p.m.
This allows "," to be used a separator between each CPU range. Note
that commas inside key=value command-line options have to be escaped
using ",,", so the command-line will look like:
-numa node,cpus=A,,B,,C,,D
Note that the following format, currently used by libvirt:
-numa nodes,cpus=A,B,C,D
will _not_ work yet, as "," is the option separator for the command-line
option parser, and it will require changing the -numa option parsing
code to handle "cpus" as a special case.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
vl.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/vl.c b/vl.c
index 955d2ff..cd247be 100644
--- a/vl.c
+++ b/vl.c
@@ -1244,7 +1244,7 @@ char *get_boot_devices_list(size_t *size)
return list;
}
-static void numa_node_parse_cpus(int nodenr, const char *cpus)
+static void numa_node_parse_cpu_range(int nodenr, const char *cpus)
{
char *endptr;
unsigned long long value, endvalue;
@@ -1288,6 +1288,18 @@ error:
exit(1);
}
+static void numa_node_parse_cpus(int nodenr, const char *option)
+{
+ char **parts;
+ int i;
+
+ parts = g_strsplit(option, ",", 0);
+ for (i = 0; parts[i]; i++) {
+ numa_node_parse_cpu_range(nodenr, parts[i]);
+ }
+ g_strfreev(parts);
+}
+
static void numa_add(const char *optarg)
{
char option[128];
--
1.8.1
2:23 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Eduardo Habkost <ehabkost(a)redhat.com> writes:
This allows "," to be used a separator between each CPU
range. Note
that commas inside key=value command-line options have to be escaped
using ",,", so the command-line will look like:
-numa node,cpus=A,,B,,C,,D
This is really, really ugly, and an embarrassment to document. Which
you didn't ;)
What about
-numa node,cpus=A,cpus=B,cpus=C,cpus=D
Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
it could be (unless you use Laszlo's opt-visitor), but that could be
improved.
Note that the following format, currently used by libvirt:
-numa nodes,cpus=A,B,C,D
will _not_ work yet, as "," is the option separator for the command-line
option parser, and it will require changing the -numa option parsing
code to handle "cpus" as a special case.
No way.
2:39 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Markus Armbruster <armbru(a)redhat.com> writes:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> This allows "," to be used a separator between each CPU range. Note
> that commas inside key=value command-line options have to be escaped
> using ",,", so the command-line will look like:
>
> -numa node,cpus=A,,B,,C,,D
This is really, really ugly, and an embarrassment to document. Which
you didn't ;)
What about
-numa node,cpus=A,cpus=B,cpus=C,cpus=D
Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
it could be (unless you use Laszlo's opt-visitor), but that could be
improved.
No more of this.
-numa node,cpus=A:B:C:D
if you want to express a list.
Regards,
Anthony Liguori
> Note that the following format, currently used by libvirt:
>
> -numa nodes,cpus=A,B,C,D
>
> will _not_ work yet, as "," is the option separator for the command-line
> option parser, and it will require changing the -numa option parsing
> code to handle "cpus" as a special case.
No way.
2:49 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Anthony Liguori <anthony(a)codemonkey.ws> writes:
Markus Armbruster <armbru(a)redhat.com> writes:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>
>> This allows "," to be used a separator between each CPU range. Note
>> that commas inside key=value command-line options have to be escaped
>> using ",,", so the command-line will look like:
>>
>> -numa node,cpus=A,,B,,C,,D
>
> This is really, really ugly, and an embarrassment to document. Which
> you didn't ;)
>
> What about
>
> -numa node,cpus=A,cpus=B,cpus=C,cpus=D
>
> Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
> it could be (unless you use Laszlo's opt-visitor), but that could be
> improved.
No more of this.
-numa node,cpus=A:B:C:D
if you want to express a list.
Okay for command line and human monitor, just don't let it bleed into
QMP.
4:04 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Markus Armbruster <armbru(a)redhat.com> writes:
Anthony Liguori <anthony(a)codemonkey.ws> writes:
> Markus Armbruster <armbru(a)redhat.com> writes:
>
>> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>>
>>> This allows "," to be used a separator between each CPU range.
Note
>>> that commas inside key=value command-line options have to be escaped
>>> using ",,", so the command-line will look like:
>>>
>>> -numa node,cpus=A,,B,,C,,D
>>
>> This is really, really ugly, and an embarrassment to document. Which
>> you didn't ;)
>>
>> What about
>>
>> -numa node,cpus=A,cpus=B,cpus=C,cpus=D
>>
>> Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
>> it could be (unless you use Laszlo's opt-visitor), but that could be
>> improved.
>
> No more of this.
>
> -numa node,cpus=A:B:C:D
>
> if you want to express a list.
Okay for command line and human monitor, just don't let it bleed into
QMP.
Footnotes:
1. Using colons for lists works only as long as the list elements don't
contain colons. Fine for numbers. No good for filenames, network
addresses, ...
2. QemuOpts helped us reduce the number of ad hoc option parsers,
improving consistency and error messages quite a bit. Having every user
of colon lists roll their own ad hoc parser slides back into the hole
that motivated QemuOpts. Let's try to avoid that, please.
3. The existing QemuOpts syntax for list-valued options (repeating the
option) doesn't have either of these problems.
9:36 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
On Fri, Feb 22, 2013 at 11:04:24AM +0100, Markus Armbruster wrote:
Markus Armbruster <armbru(a)redhat.com> writes:
> Anthony Liguori <anthony(a)codemonkey.ws> writes:
>
>> Markus Armbruster <armbru(a)redhat.com> writes:
>>
>>> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>>>
>>>> This allows "," to be used a separator between each CPU range.
Note
>>>> that commas inside key=value command-line options have to be escaped
>>>> using ",,", so the command-line will look like:
>>>>
>>>> -numa node,cpus=A,,B,,C,,D
>>>
>>> This is really, really ugly, and an embarrassment to document. Which
>>> you didn't ;)
>>>
>>> What about
>>>
>>> -numa node,cpus=A,cpus=B,cpus=C,cpus=D
>>>
>>> Yes, QemuOpts lets you do that. Getting all the values isn't as easy
as
>>> it could be (unless you use Laszlo's opt-visitor), but that could be
>>> improved.
>>
>> No more of this.
>>
>> -numa node,cpus=A:B:C:D
>>
>> if you want to express a list.
>
> Okay for command line and human monitor, just don't let it bleed into
> QMP.
Footnotes:
1. Using colons for lists works only as long as the list elements don't
contain colons. Fine for numbers. No good for filenames, network
addresses, ...
2. QemuOpts helped us reduce the number of ad hoc option parsers,
improving consistency and error messages quite a bit. Having every user
of colon lists roll their own ad hoc parser slides back into the hole
that motivated QemuOpts. Let's try to avoid that, please.
3. The existing QemuOpts syntax for list-valued options (repeating the
option) doesn't have either of these problems.
The problem here seems to be that we want to reuse option parsing code,
but the only reusable syntax we have for command-line options today is
awful (at least for representing lists).
So our only options seem to be: 1) accept some ugliness and things like
"A,,B,,C" or "cpus=A,cpus=B,cpus=C"; 2) write ad hoc option parsers;
3)
define/choose a new reusable syntax.
We already have at least 2 better ways to represent config data (config
files and QMP+JSON), but why do we insist in using command-line options
with an awful syntax for everything?
--
Eduardo
2:57 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> This allows "," to be used a separator between each CPU range. Note
> that commas inside key=value command-line options have to be escaped
> using ",,", so the command-line will look like:
>
> -numa node,cpus=A,,B,,C,,D
This is really, really ugly, and an embarrassment to document. Which
you didn't ;)
I was trying to have an intermediate solution using the current -numa
parser. I have patches in my queue that will change the code to properly
use QemuOpts later.
It would be interesting to support the "A,B,C,D" format in config files,
though, as it is simple and straighforward when no escaping is required.
What about
-numa node,cpus=A,cpus=B,cpus=C,cpus=D
Looks better for the command-line usage, at least. I will give it a try.
Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
it could be (unless you use Laszlo's opt-visitor), but that could be
improved.
Guess what: -numa doesn't even use QemuOpts, and I am not sure the
current format of -numa will allow QemuOpts to be used easily. I expect
the proper solution using QemuOpts to involve having a
standards-compliant "numa-node" config section instead of this weird
"-numa <type>,..." format where the only valid <type> that ever
existed
was "node".
But I believe it will be feasible to allow "cpus=A,cpus=B" using the
current parser, before we convert to a proper QemuOpts-based
implementaiton.
> Note that the following format, currently used by libvirt:
>
> -numa nodes,cpus=A,B,C,D
>
> will _not_ work yet, as "," is the option separator for the command-line
> option parser, and it will require changing the -numa option parsing
> code to handle "cpus" as a special case.
No way.
Agreed. :-)
The bad news is that libvirt uses this format since forever, this format
never worked, and nobody ever noticed that this was broken.
--
Eduardo
2:54 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
On 02/21/2013 01:57 PM, Eduardo Habkost wrote:
>> Note that the following format, currently used by libvirt:
>>
>> -numa nodes,cpus=A,B,C,D
>>
>> will _not_ work yet, as "," is the option separator for the
command-line
>> option parser, and it will require changing the -numa option parsing
>> code to handle "cpus" as a special case.
>
> No way.
Agreed. :-)
The bad news is that libvirt uses this format since forever, this format
never worked, and nobody ever noticed that this was broken.
Well, libvirt just entered freeze for 1.0.3. I think the best course of
action on libvirt's side is to patch 1.0.3 to flat-out reject any cpumap
that cannot be represented in a syntax understood by qemu 1.4; then a
future libvirt can re-add support for whatever new syntax qemu 1.5 deems
as appropriate.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3:04 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Am 21.02.2013 21:57, schrieb Eduardo Habkost:
On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>
>> This allows "," to be used a separator between each CPU range. Note
>> that commas inside key=value command-line options have to be escaped
>> using ",,", so the command-line will look like:
>>
>> -numa node,cpus=A,,B,,C,,D
>
> This is really, really ugly, and an embarrassment to document. Which
> you didn't ;)
I was trying to have an intermediate solution using the current -numa
parser. I have patches in my queue that will change the code to properly
use QemuOpts later.
Speaking of which, have you considered using QemuOpts for -cpu? Its
custom parsing code will probably not handle , escaping at all. ;)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
7:44 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
On Mon, Feb 25, 2013 at 10:04:07PM +0100, Andreas Färber wrote:
Am 21.02.2013 21:57, schrieb Eduardo Habkost:
> On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>>
>>> This allows "," to be used a separator between each CPU range.
Note
>>> that commas inside key=value command-line options have to be escaped
>>> using ",,", so the command-line will look like:
>>>
>>> -numa node,cpus=A,,B,,C,,D
>>
>> This is really, really ugly, and an embarrassment to document. Which
>> you didn't ;)
>
> I was trying to have an intermediate solution using the current -numa
> parser. I have patches in my queue that will change the code to properly
> use QemuOpts later.
Speaking of which, have you considered using QemuOpts for -cpu? Its
custom parsing code will probably not handle , escaping at all. ;)
It may be possible, but I'm not sure QemuOpts can handle the "+foo,-foo"
options (and I am sure we don't want to extend QemuOpts to support
them).
In either case, it's better to do that after we simplify
x86_cpu_parse_featurestr() (with the current patches from Igor), to make
the conversion easier to review later.
--
Eduardo
3:53 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Eduardo Habkost <ehabkost(a)redhat.com> writes:
On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>
> > This allows "," to be used a separator between each CPU range. Note
> > that commas inside key=value command-line options have to be escaped
> > using ",,", so the command-line will look like:
> >
> > -numa node,cpus=A,,B,,C,,D
>
> This is really, really ugly, and an embarrassment to document. Which
> you didn't ;)
I was trying to have an intermediate solution using the current -numa
parser. I have patches in my queue that will change the code to properly
use QemuOpts later.
It would be interesting to support the "A,B,C,D" format in config files,
though, as it is simple and straighforward when no escaping is required.
Our config file syntax is in a Windows INI dialect: key=value lines
grouped into sections. Our dialect requires values to be enclosed in
quotes. Commonly, the quotes are optional. Could be fixed. It
supports multi-valued keys the common INI way: multiple key=value lines
for the same key, one per value
key = "A,B,C" works when the A, B, C can't contain commas. Fine for a
list of numbers. For long lists, we'd probably want to add a line
continuation feature.
Strings can contain commas, so you'd have to do something like key =
"A", "B", "C". Whether that's still Windows INI is
debatable. More so
since there's already a common way to do it: one line per value.
If we decide INI doesn't meet our needs or desires for pretty syntax, we
should not extend it beyond its limits into QEMU's very own
configuration syntax. We should switch to a common syntax that serves
our needs and desires. For what it's worth, we already parse JSON.
For me, the INI way to do multi-valued keys is still fine.
> What about
>
> -numa node,cpus=A,cpus=B,cpus=C,cpus=D
Looks better for the command-line usage, at least. I will give it a try.
>
> Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
> it could be (unless you use Laszlo's opt-visitor), but that could be
> improved.
Guess what: -numa doesn't even use QemuOpts, and I am not sure the
current format of -numa will allow QemuOpts to be used easily. I expect
the proper solution using QemuOpts to involve having a
standards-compliant "numa-node" config section instead of this weird
"-numa <type>,..." format where the only valid <type> that ever
existed
was "node".
This is the current -numa syntax, as far as I can tell:
-numa node,KEY=VALUE,...
Recognized KEY=VALUE:
nodeid=UINT
mem=SIZE
cpus=[|UINT|UINT-UINT]
Unrecognized KEYs are silently ignored.
This should fit into QemuOpts just fine. Sketch:
static QemuOptsList qemu_numa_opts = {
.name = "numa",
.implied_opt_name = "type"
.head = QTAILQ_HEAD_INITIALIZER(qemu_rtc_numa.head),
.desc = {
{
.name = "type",
.type = QEMU_OPT_STRING,
.help = "node type"
}, {
.name = "nodeid",
.type = QEMU_OPT_NUMBER,
.help = "node ID"
}, {
.name = "mem",
.type = QEMU_OPT_SIZE,
.help = "memory size"
}, {
.name = "cpus",
.type = QEMU_OPT_STRING,
.help = "CPU range"
},
{ /* end of list */ }
},
};
type = qemu_opt_get(opts);
if (!type || strcmp(type, "node)) {
// error
}
// get and record nodeid, mem
// get, parse and record cpus
This rejects unrecognized keys, unlike the current code. Declare bug
fix ;)
To support discontinuous CPU sets, simply get all values of key "cpus".
But I believe it will be feasible to allow "cpus=A,cpus=B"
using the
current parser, before we convert to a proper QemuOpts-based
implementaiton.
>
> > Note that the following format, currently used by libvirt:
> >
> > -numa nodes,cpus=A,B,C,D
> >
> > will _not_ work yet, as "," is the option separator for the
command-line
> > option parser, and it will require changing the -numa option parsing
> > code to handle "cpus" as a special case.
>
> No way.
Agreed. :-)
The bad news is that libvirt uses this format since forever, this format
never worked, and nobody ever noticed that this was broken.
The good news is that it never worked, which simplifies our backward
compatibility worries.
8:04 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
On Tue, Feb 26, 2013 at 10:53:07AM +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost(a)redhat.com> writes:
> On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost(a)redhat.com> writes:
>>
>> > This allows "," to be used a separator between each CPU range.
Note
>> > that commas inside key=value command-line options have to be escaped
>> > using ",,", so the command-line will look like:
>> >
>> > -numa node,cpus=A,,B,,C,,D
>>
>> This is really, really ugly, and an embarrassment to document. Which
>> you didn't ;)
>
> I was trying to have an intermediate solution using the current -numa
> parser. I have patches in my queue that will change the code to properly
> use QemuOpts later.
>
> It would be interesting to support the "A,B,C,D" format in config files,
> though, as it is simple and straighforward when no escaping is required.
Our config file syntax is in a Windows INI dialect: key=value lines
grouped into sections. Our dialect requires values to be enclosed in
quotes. Commonly, the quotes are optional. Could be fixed. It
supports multi-valued keys the common INI way: multiple key=value lines
for the same key, one per value
key = "A,B,C" works when the A, B, C can't contain commas. Fine for a
list of numbers. For long lists, we'd probably want to add a line
continuation feature.
Strings can contain commas, so you'd have to do something like key =
"A", "B", "C". Whether that's still Windows INI is
debatable. More so
since there's already a common way to do it: one line per value.
I was only thinking about the -numa option problem. Having a more
generic solution would surely be even better.
If we decide INI doesn't meet our needs or desires for pretty syntax, we
should not extend it beyond its limits into QEMU's very own
configuration syntax. We should switch to a common syntax that serves
our needs and desires. For what it's worth, we already parse JSON.
I completely agree. But by now I just want to know what we should do
while we don't have a generic parser/syntax that can handle lists in a
pretty way. So:
For me, the INI way to do multi-valued keys is still fine.
Having multiple-valued keys (cpus=A,cpus=B,cpus=C) seems like the best
intermediate solution while we don't have a decent generic syntax.
Except that Anthony doesn't like it.
Anthony, care to explain why exactly you don't want it?
>> What about
>>
>> -numa node,cpus=A,cpus=B,cpus=C,cpus=D
>
> Looks better for the command-line usage, at least. I will give it a try.
>
>>
>> Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
>> it could be (unless you use Laszlo's opt-visitor), but that could be
>> improved.
>
> Guess what: -numa doesn't even use QemuOpts, and I am not sure the
> current format of -numa will allow QemuOpts to be used easily. I expect
> the proper solution using QemuOpts to involve having a
> standards-compliant "numa-node" config section instead of this weird
> "-numa <type>,..." format where the only valid <type> that
ever existed
> was "node".
This is the current -numa syntax, as far as I can tell:
-numa node,KEY=VALUE,...
Recognized KEY=VALUE:
nodeid=UINT
mem=SIZE
cpus=[|UINT|UINT-UINT]
Unrecognized KEYs are silently ignored.
This should fit into QemuOpts just fine. Sketch:
static QemuOptsList qemu_numa_opts = {
.name = "numa",
.implied_opt_name = "type"
.head = QTAILQ_HEAD_INITIALIZER(qemu_rtc_numa.head),
.desc = {
{
.name = "type",
.type = QEMU_OPT_STRING,
.help = "node type"
},
The "node" part is not a "node type", it is an "numa option
type", and
the only valid "option type" today is "node" (which is what makes the
current syntax seem weird to me).
I would simply drop the "numa" part from the command-line argument and
name the new config section "numa-node". I will send patches to do that,
later.
{
.name = "nodeid",
.type = QEMU_OPT_NUMBER,
.help = "node ID"
}, {
.name = "mem",
.type = QEMU_OPT_SIZE,
.help = "memory size"
}, {
I need to double-check that QEMU_OPT_SIZE has exactly the same behavior
of the ad-hoc parser, first.
.name = "cpus",
.type = QEMU_OPT_STRING,
.help = "CPU range"
},
{ /* end of list */ }
},
};
type = qemu_opt_get(opts);
if (!type || strcmp(type, "node)) {
// error
}
// get and record nodeid, mem
// get, parse and record cpus
This rejects unrecognized keys, unlike the current code. Declare bug
fix ;)
Good. :-)
To support discontinuous CPU sets, simply get all values of key "cpus".
I think I have an unfinished work branch that did that. But Paolo also
have a similar patch on his tree that does the conversion to QemuOpts in
a much simpler way.
In either case, first I need to check if QemuOpts will match the ad-hoc
parser behavior, because they use different integer/size parser
functions.
> But I believe it will be feasible to allow "cpus=A,cpus=B" using the
> current parser, before we convert to a proper QemuOpts-based
> implementaiton.
>
>>
>> > Note that the following format, currently used by libvirt:
>> >
>> > -numa nodes,cpus=A,B,C,D
>> >
>> > will _not_ work yet, as "," is the option separator for the
command-line
>> > option parser, and it will require changing the -numa option parsing
>> > code to handle "cpus" as a special case.
>>
>> No way.
>
> Agreed. :-)
>
> The bad news is that libvirt uses this format since forever, this format
> never worked, and nobody ever noticed that this was broken.
The good news is that it never worked, which simplifies our backward
compatibility worries.
Note that only the multiple-CPU-ranges use-case is broken. It works if
all NUMA nodes have simple "A-B" CPU ranges.
--
Eduardo
8:29 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option
Il 26/02/2013 15:04, Eduardo Habkost ha scritto:
> > For me, the INI way to do multi-valued keys is still fine.
Having multiple-valued keys (cpus=A,cpus=B,cpus=C) seems like the best
intermediate solution while we don't have a decent generic syntax.
Even more so since:
1) we already support it for -net;
2) our config file format is not a random INI variant, it's explicitly
based on git's config file format, and it supports multiple-valued keys.
For example here is a stanza of my .git/config file.
[remote "mirror"]
url = git://github.com/bonzini/qemu.git
pushurl = git@github.com:bonzini/qemu.git
fetch = +refs/heads/*:refs/remotes/mirror/*
push = +refs/heads/*:refs/heads/*
push = +refs/heads/master:refs/heads/integration
push = +refs/remotes/origin/master:refs/heads/master
push = +refs/tags/*:refs/tags/*
Paolo
Except that Anthony doesn't like it.
Anthony, care to explain why exactly you don't want it?
4287
days inactive
4292
days old
12 comments
6 participants
participants (6)
-
Andreas Färber -
Anthony Liguori -
Eduardo Habkost -
Eric Blake -
Markus Armbruster -
Paolo Bonzini