KVM call agenda for Tuesday 3

KVM call agenda for Tuesday 3

[Juan Quintela]

Hi

First of all, Happy New Year to everybody (even for the people whose
calendar is different O:-)

Please send in any agenda items you are interested in covering.

Thanks, Juan.

[Qemu-devel] KVM call agenda for Tuesday 3

[Juan Quintela]

Hi

First of all, Happy New Year to everybody (even for the people whose
calendar is different O:-)

Please send in any agenda items you are interested in covering.

Thanks, Juan.

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Andreas Färber]

Am 02.01.2012 13:09, schrieb Juan Quintela:
> First of all, Happy New Year to everybody (even for the people whose
> calendar is different O:-)

+1

> Please send in any agenda items you are interested in covering.

QOM: If Anthony is available, I'd be interested in hearing an update on
the roadmap. In particular,
* when can we expect to be able to model SoCs rather than CPUs? Will
this affect command line usage - are we going to have '-device
ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
container's default?
* are the announced remaining 3 series going to touch CPUState? a) Are
CPU features being refactored (standardized) for QOM or should we copy
current x86 code for controlling ARM FPU? b) Any plans for adding
inheritence, e.g., for CPU_COMMON and CPU reset?
* what's the effect on VMState? Will VMState continue to coexist with
QOM, or does QOM replace VMState at some point? Is it worth introducing
new size mechanisms now or should we postpone SD/AHCI migration until
QOM is merged?

Testing: A brief clarification on scope, goals and relations (overlap?)
of all frameworks proposed might be better than a flame war? ;)

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

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Andreas Färber]

Am 02.01.2012 13:09, schrieb Juan Quintela:
> First of all, Happy New Year to everybody (even for the people whose
> calendar is different O:-)

+1

> Please send in any agenda items you are interested in covering.

QOM: If Anthony is available, I'd be interested in hearing an update on
the roadmap. In particular,
* when can we expect to be able to model SoCs rather than CPUs? Will
this affect command line usage - are we going to have '-device
ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
container's default?
* are the announced remaining 3 series going to touch CPUState? a) Are
CPU features being refactored (standardized) for QOM or should we copy
current x86 code for controlling ARM FPU? b) Any plans for adding
inheritence, e.g., for CPU_COMMON and CPU reset?
* what's the effect on VMState? Will VMState continue to coexist with
QOM, or does QOM replace VMState at some point? Is it worth introducing
new size mechanisms now or should we postpone SD/AHCI migration until
QOM is merged?

Testing: A brief clarification on scope, goals and relations (overlap?)
of all frameworks proposed might be better than a flame war? ;)

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

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Paolo Bonzini]

On 01/02/2012 02:46 PM, Andreas Färber wrote:
> QOM: If Anthony is available, I'd be interested in hearing an update on
> the roadmap. In particular,
> * when can we expect to be able to model SoCs rather than CPUs? Will
> this affect command line usage - are we going to have '-device
> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
> container's default?
> * are the announced remaining 3 series going to touch CPUState? a) Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU? b) Any plans for adding
> inheritence, e.g., for CPU_COMMON and CPU reset?

Also, Anthony, what are the remaining 3 series exactly? :)

In particular, we should decide as soon as possible about moving 
features up from Device to Object or to new intermediate classes (e.g. 
IntrospectableObject for properties?), because I would like to start 
dogfooding QOM.  Right now, we have legacy properties but qdev functions 
still poke directly into the structs rather than using them.

> * what's the effect on VMState? Will VMState continue to coexist with
> QOM, or does QOM replace VMState at some point? Is it worth introducing
> new size mechanisms now or should we postpone SD/AHCI migration until
> QOM is merged?

I think no.  Postponing new device models (virtio-scsi) might make some 
sense, but VMState is definitely going to be with us for some time---at 
least it's not disappearing soon enough that we should halt any 
development in that area.

Paolo

Re: KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 08:11 AM, Paolo Bonzini wrote:
> On 01/02/2012 02:46 PM, Andreas Färber wrote:
>> QOM: If Anthony is available, I'd be interested in hearing an update on
>> the roadmap. In particular,
>> * when can we expect to be able to model SoCs rather than CPUs? Will
>> this affect command line usage - are we going to have '-device
>> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
>> container's default?
>> * are the announced remaining 3 series going to touch CPUState? a) Are
>> CPU features being refactored (standardized) for QOM or should we copy
>> current x86 code for controlling ARM FPU? b) Any plans for adding
>> inheritence, e.g., for CPU_COMMON and CPU reset?
>
> Also, Anthony, what are the remaining 3 series exactly? :)

2/4 is on the list.  It's adding the type infrastructure such that when you do 
-device e1000, as far as QOM is concerned you're creating an E1000 object which 
inherits from a PCIDevice, etc.

But device creation still more or less happens with qdev.  You couldn't directly 
create a useful E1000 device by doing object_new(TYPE_E1000).

I just effectively squashed 3/4 and 4/4 into a single series.  This new series 
(now 3/4) makes it so you can do object_new(TYPE_E1000).  It basically reduces 
qdev to just the management of bus relationships.

The new 4/4 series converts BusState to QOM.  The effect is that a BusState is 
an Object (but not a device).  The children are shown as links so the entire 
qdev tree is now just a subset of the QOM graph.

I think that's it for infrastructure series.  After that, the two areas I'm 
interested in focusing on are converting CPUs to qdev and then refactoring the 
pc machine init code to just essentially be a thin wrapper for object_new(TYPE_PC).

> In particular, we should decide as soon as possible about moving features up
> from Device to Object or to new intermediate classes (e.g. IntrospectableObject
> for properties?),

I think I move properties from Device to Object in either 2/4 or 3/4.  Anyway, 
that's my plan.

> because I would like to start dogfooding QOM.

Cool!

> Right now, we
> have legacy properties but qdev functions still poke directly into the structs
> rather than using them.

Yeah, I had some concerns about legacy properties before Christmas but I haven't 
fully context switched back in yet.  I'll try to remember what they were and 
send a note out.

>> * what's the effect on VMState? Will VMState continue to coexist with
>> QOM, or does QOM replace VMState at some point? Is it worth introducing
>> new size mechanisms now or should we postpone SD/AHCI migration until
>> QOM is merged?
>
> I think no. Postponing new device models (virtio-scsi) might make some sense,

I don't think postponing is really necessary.  Rebasing really isn't all that 
difficult as it turns out.  I would rather we take our time reviewing things and 
not rush into a new infrastructure.

> but VMState is definitely going to be with us for some time---at least it's not
> disappearing soon enough that we should halt any development in that area.

Yeah, as I mentioned in my other note, I think it's more or less orthogonal to QOM.

Regards,

Anthony Liguori

> Paolo
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 08:11 AM, Paolo Bonzini wrote:
> On 01/02/2012 02:46 PM, Andreas Färber wrote:
>> QOM: If Anthony is available, I'd be interested in hearing an update on
>> the roadmap. In particular,
>> * when can we expect to be able to model SoCs rather than CPUs? Will
>> this affect command line usage - are we going to have '-device
>> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
>> container's default?
>> * are the announced remaining 3 series going to touch CPUState? a) Are
>> CPU features being refactored (standardized) for QOM or should we copy
>> current x86 code for controlling ARM FPU? b) Any plans for adding
>> inheritence, e.g., for CPU_COMMON and CPU reset?
>
> Also, Anthony, what are the remaining 3 series exactly? :)

2/4 is on the list.  It's adding the type infrastructure such that when you do 
-device e1000, as far as QOM is concerned you're creating an E1000 object which 
inherits from a PCIDevice, etc.

But device creation still more or less happens with qdev.  You couldn't directly 
create a useful E1000 device by doing object_new(TYPE_E1000).

I just effectively squashed 3/4 and 4/4 into a single series.  This new series 
(now 3/4) makes it so you can do object_new(TYPE_E1000).  It basically reduces 
qdev to just the management of bus relationships.

The new 4/4 series converts BusState to QOM.  The effect is that a BusState is 
an Object (but not a device).  The children are shown as links so the entire 
qdev tree is now just a subset of the QOM graph.

I think that's it for infrastructure series.  After that, the two areas I'm 
interested in focusing on are converting CPUs to qdev and then refactoring the 
pc machine init code to just essentially be a thin wrapper for object_new(TYPE_PC).

> In particular, we should decide as soon as possible about moving features up
> from Device to Object or to new intermediate classes (e.g. IntrospectableObject
> for properties?),

I think I move properties from Device to Object in either 2/4 or 3/4.  Anyway, 
that's my plan.

> because I would like to start dogfooding QOM.

Cool!

> Right now, we
> have legacy properties but qdev functions still poke directly into the structs
> rather than using them.

Yeah, I had some concerns about legacy properties before Christmas but I haven't 
fully context switched back in yet.  I'll try to remember what they were and 
send a note out.

>> * what's the effect on VMState? Will VMState continue to coexist with
>> QOM, or does QOM replace VMState at some point? Is it worth introducing
>> new size mechanisms now or should we postpone SD/AHCI migration until
>> QOM is merged?
>
> I think no. Postponing new device models (virtio-scsi) might make some sense,

I don't think postponing is really necessary.  Rebasing really isn't all that 
difficult as it turns out.  I would rather we take our time reviewing things and 
not rush into a new infrastructure.

> but VMState is definitely going to be with us for some time---at least it's not
> disappearing soon enough that we should halt any development in that area.

Yeah, as I mentioned in my other note, I think it's more or less orthogonal to QOM.

Regards,

Anthony Liguori

> Paolo
>

Re: KVM call agenda for Tuesday 3

[Paolo Bonzini]

On 01/03/2012 02:12 AM, Anthony Liguori wrote:
> 2/4 is on the list. It's adding the type infrastructure such that when
> you do -device e1000, as far as QOM is concerned you're creating an
> E1000 object which inherits from a PCIDevice, etc.

Yes, sorry, that was quite obvious.  I was not sure about what the other 
two parts were.

> But device creation still more or less happens with qdev. You couldn't
> directly create a useful E1000 device by doing object_new(TYPE_E1000).
>
> I just effectively squashed 3/4 and 4/4 into a single series. This new
> series (now 3/4) makes it so you can do object_new(TYPE_E1000). It
> basically reduces qdev to just the management of bus relationships.
>
> The new 4/4 series converts BusState to QOM. The effect is that a
> BusState is an Object (but not a device). The children are shown as
> links so the entire qdev tree is now just a subset of the QOM graph.
>
> I think that's it for infrastructure series. After that, the two areas
> I'm interested in focusing on are converting CPUs to qdev and then
> refactoring the pc machine init code to just essentially be a thin
> wrapper for object_new(TYPE_PC).

Nice.

>> In particular, we should decide as soon as possible about moving
>> features up from Device to Object or to new intermediate classes
>> (e.g. IntrospectableObject for properties?),
>
> I think I move properties from Device to Object in either 2/4 or 3/4.
> Anyway, that's my plan.

I would prefer to have an intermediate class for two reasons: 1) so that 
we can reuse refcounting and interfaces even for light-weight objects; 
2) so that we can keep interface implementations as subclasses of 
Object, without carrying a useless baggage for properties (that would be 
true for refcounting too, but the cost is much smaller).

Paolo

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Paolo Bonzini]

On 01/03/2012 02:12 AM, Anthony Liguori wrote:
> 2/4 is on the list. It's adding the type infrastructure such that when
> you do -device e1000, as far as QOM is concerned you're creating an
> E1000 object which inherits from a PCIDevice, etc.

Yes, sorry, that was quite obvious.  I was not sure about what the other 
two parts were.

> But device creation still more or less happens with qdev. You couldn't
> directly create a useful E1000 device by doing object_new(TYPE_E1000).
>
> I just effectively squashed 3/4 and 4/4 into a single series. This new
> series (now 3/4) makes it so you can do object_new(TYPE_E1000). It
> basically reduces qdev to just the management of bus relationships.
>
> The new 4/4 series converts BusState to QOM. The effect is that a
> BusState is an Object (but not a device). The children are shown as
> links so the entire qdev tree is now just a subset of the QOM graph.
>
> I think that's it for infrastructure series. After that, the two areas
> I'm interested in focusing on are converting CPUs to qdev and then
> refactoring the pc machine init code to just essentially be a thin
> wrapper for object_new(TYPE_PC).

Nice.

>> In particular, we should decide as soon as possible about moving
>> features up from Device to Object or to new intermediate classes
>> (e.g. IntrospectableObject for properties?),
>
> I think I move properties from Device to Object in either 2/4 or 3/4.
> Anyway, that's my plan.

I would prefer to have an intermediate class for two reasons: 1) so that 
we can reuse refcounting and interfaces even for light-weight objects; 
2) so that we can keep interface implementations as subclasses of 
Object, without carrying a useless baggage for properties (that would be 
true for refcounting too, but the cost is much smaller).

Paolo

Re: KVM call agenda for Tuesday 3

[Peter Maydell]

On 2 January 2012 13:46, Andreas Färber <afaerber@suse.de> wrote:
> * when can we expect to be able to model SoCs rather than CPUs? Will
> this affect command line usage - are we going to have '-device
> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
> container's default?

My initial inclination is to say that specifying the CPU on the
command line is almost always the wrong thing for ARM platforms
(now or in a future QOM world). For instance, if you start the
vexpress-a9 board with something other than -cpu cortex-a9 it won't
complain but it won't do the right thing either (you'll get the
private peripherals for the A9 with whatever CPU core you asked for).

I don't think you want to have the user specifying -device my-soc
on the command line either -- the user should be selecting a board
(machine) model, which will generally nail down which soc and cpu
are used.

-cpu foo is most useful for linux-user mode.

> Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU?

There's a patch to add cpu feature support here:
https://github.com/jowinter/qemu-trustzone/commit/421a2a71daa141da50c54997948d2a6d23013bd4
which I'm hoping will be submitted upstream...

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 2 January 2012 13:46, Andreas Färber <afaerber@suse.de> wrote:
> * when can we expect to be able to model SoCs rather than CPUs? Will
> this affect command line usage - are we going to have '-device
> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
> container's default?

My initial inclination is to say that specifying the CPU on the
command line is almost always the wrong thing for ARM platforms
(now or in a future QOM world). For instance, if you start the
vexpress-a9 board with something other than -cpu cortex-a9 it won't
complain but it won't do the right thing either (you'll get the
private peripherals for the A9 with whatever CPU core you asked for).

I don't think you want to have the user specifying -device my-soc
on the command line either -- the user should be selecting a board
(machine) model, which will generally nail down which soc and cpu
are used.

-cpu foo is most useful for linux-user mode.

> Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU?

There's a patch to add cpu feature support here:
https://github.com/jowinter/qemu-trustzone/commit/421a2a71daa141da50c54997948d2a6d23013bd4
which I'm hoping will be submitted upstream...

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 09:54 AM, Peter Maydell wrote:
> On 2 January 2012 13:46, Andreas Färber<afaerber@suse.de>  wrote:
>> * when can we expect to be able to model SoCs rather than CPUs? Will
>> this affect command line usage - are we going to have '-device
>> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
>> container's default?
>
> My initial inclination is to say that specifying the CPU on the
> command line is almost always the wrong thing for ARM platforms
> (now or in a future QOM world). For instance, if you start the
> vexpress-a9 board with something other than -cpu cortex-a9 it won't
> complain but it won't do the right thing either (you'll get the
> private peripherals for the A9 with whatever CPU core you asked for).
>
> I don't think you want to have the user specifying -device my-soc
> on the command line either -- the user should be selecting a board
> (machine) model, which will generally nail down which soc and cpu
> are used.

Let's separate out what a user *should* do from what a user *can* do.

A user *should* have a command line syntax that reflects something that makes 
sense to them.  For instance, qemu-system-arm --machine beaglebone

I don't really care what the SoC or CPU in my beaglebone is.  I just want to 
emulate one.

But I do believe we want to make it possible for -device to create a CPU even 
when it doesn't make sense.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 09:54 AM, Peter Maydell wrote:
> On 2 January 2012 13:46, Andreas Färber<afaerber@suse.de>  wrote:
>> * when can we expect to be able to model SoCs rather than CPUs? Will
>> this affect command line usage - are we going to have '-device
>> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
>> container's default?
>
> My initial inclination is to say that specifying the CPU on the
> command line is almost always the wrong thing for ARM platforms
> (now or in a future QOM world). For instance, if you start the
> vexpress-a9 board with something other than -cpu cortex-a9 it won't
> complain but it won't do the right thing either (you'll get the
> private peripherals for the A9 with whatever CPU core you asked for).
>
> I don't think you want to have the user specifying -device my-soc
> on the command line either -- the user should be selecting a board
> (machine) model, which will generally nail down which soc and cpu
> are used.

Let's separate out what a user *should* do from what a user *can* do.

A user *should* have a command line syntax that reflects something that makes 
sense to them.  For instance, qemu-system-arm --machine beaglebone

I don't really care what the SoC or CPU in my beaglebone is.  I just want to 
emulate one.

But I do believe we want to make it possible for -device to create a CPU even 
when it doesn't make sense.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 01:14, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Let's separate out what a user *should* do from what a user *can* do.
>
> A user *should* have a command line syntax that reflects something that
> makes sense to them.  For instance, qemu-system-arm --machine beaglebone
>
> I don't really care what the SoC or CPU in my beaglebone is.  I just want to
> emulate one.
>
> But I do believe we want to make it possible for -device to create a CPU
> even when it doesn't make sense.

So there's a couple of things here that fall in the "can't do that" bin:

1. trying to instantiate more than one device which has a CPU in it
(eg the default one from the machine/SoC model, and the second one
from the -device my-soc command line argument). (Basic QEMU limitation.)

2. trying to replace an existing device in the machine model with a
different one which isn't connection-compatible with it. For instance,
in a fully QOM world, trying to run a beagle machine with (say) a 926
CPU should fail to instantiate, because the 926 CPU won't have the right
set of irq/gpio inputs and outputs that the beagle machine needs to
connect up to. (This is the QOM equivalent of trying to ram a 486
into a Pentium CPU socket.)

I don't think we even have syntax for 2 at the moment except for the
weird special case of "-cpu foo".

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 01:14, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Let's separate out what a user *should* do from what a user *can* do.
>
> A user *should* have a command line syntax that reflects something that
> makes sense to them.  For instance, qemu-system-arm --machine beaglebone
>
> I don't really care what the SoC or CPU in my beaglebone is.  I just want to
> emulate one.
>
> But I do believe we want to make it possible for -device to create a CPU
> even when it doesn't make sense.

So there's a couple of things here that fall in the "can't do that" bin:

1. trying to instantiate more than one device which has a CPU in it
(eg the default one from the machine/SoC model, and the second one
from the -device my-soc command line argument). (Basic QEMU limitation.)

2. trying to replace an existing device in the machine model with a
different one which isn't connection-compatible with it. For instance,
in a fully QOM world, trying to run a beagle machine with (say) a 926
CPU should fail to instantiate, because the 926 CPU won't have the right
set of irq/gpio inputs and outputs that the beagle machine needs to
connect up to. (This is the QOM equivalent of trying to ram a 486
into a Pentium CPU socket.)

I don't think we even have syntax for 2 at the moment except for the
weird special case of "-cpu foo".

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Alex Bradbury]

On 3 January 2012 10:26, Peter Maydell <peter.maydell@linaro.org> wrote:
> I don't think we even have syntax for 2 at the moment except for the
> weird special case of "-cpu foo".

It currently is quite common to e.g. use a versatilepb machine model
but switch the CPU for arm1176, cortex-a8 etc with -cpu. Will this
still be possible?

Alex

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Alex Bradbury]

On 3 January 2012 10:26, Peter Maydell <peter.maydell@linaro.org> wrote:
> I don't think we even have syntax for 2 at the moment except for the
> weird special case of "-cpu foo".

It currently is quite common to e.g. use a versatilepb machine model
but switch the CPU for arm1176, cortex-a8 etc with -cpu. Will this
still be possible?

Alex

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/03/2012 04:26 AM, Peter Maydell wrote:
> On 3 January 2012 01:14, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> Let's separate out what a user *should* do from what a user *can* do.
>>
>> A user *should* have a command line syntax that reflects something that
>> makes sense to them.  For instance, qemu-system-arm --machine beaglebone
>>
>> I don't really care what the SoC or CPU in my beaglebone is.  I just want to
>> emulate one.
>>
>> But I do believe we want to make it possible for -device to create a CPU
>> even when it doesn't make sense.
>
> So there's a couple of things here that fall in the "can't do that" bin:
>
> 1. trying to instantiate more than one device which has a CPU in it
> (eg the default one from the machine/SoC model, and the second one
> from the -device my-soc command line argument). (Basic QEMU limitation.)

But this is something that shouldn't be a limitation IMHO.

> 2. trying to replace an existing device in the machine model with a
> different one which isn't connection-compatible with it.

So for the PC, I imagine we would have something like a 
socket[0]:link<X86CPUState> property.  You would set topology by setting 
properties to make a single CPU appear to have multiple cores/threads.

For what you're getting at, you actually want to model the CPUs in QOM such that 
you would have an ARM926 is-a ARMCPU is-a CPUCommon.

Then you could have the beagle machine have a link<ARM926>.  If it always has a 
single CPU, you make it a child<ARM926> and the user can't change it.

They can still set properties on the CPU so if there are flags they need to 
tweak, they could.

> For instance,
> in a fully QOM world, trying to run a beagle machine with (say) a 926
> CPU should fail to instantiate, because the 926 CPU won't have the right
> set of irq/gpio inputs and outputs that the beagle machine needs to
> connect up to. (This is the QOM equivalent of trying to ram a 486
> into a Pentium CPU socket.)
>
> I don't think we even have syntax for 2 at the moment except for the
> weird special case of "-cpu foo".

Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We 
could do it very simply and flat or model the individual CPUs as proper types 
which lets you do fancier things with links.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/03/2012 04:26 AM, Peter Maydell wrote:
> On 3 January 2012 01:14, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> Let's separate out what a user *should* do from what a user *can* do.
>>
>> A user *should* have a command line syntax that reflects something that
>> makes sense to them.  For instance, qemu-system-arm --machine beaglebone
>>
>> I don't really care what the SoC or CPU in my beaglebone is.  I just want to
>> emulate one.
>>
>> But I do believe we want to make it possible for -device to create a CPU
>> even when it doesn't make sense.
>
> So there's a couple of things here that fall in the "can't do that" bin:
>
> 1. trying to instantiate more than one device which has a CPU in it
> (eg the default one from the machine/SoC model, and the second one
> from the -device my-soc command line argument). (Basic QEMU limitation.)

But this is something that shouldn't be a limitation IMHO.

> 2. trying to replace an existing device in the machine model with a
> different one which isn't connection-compatible with it.

So for the PC, I imagine we would have something like a 
socket[0]:link<X86CPUState> property.  You would set topology by setting 
properties to make a single CPU appear to have multiple cores/threads.

For what you're getting at, you actually want to model the CPUs in QOM such that 
you would have an ARM926 is-a ARMCPU is-a CPUCommon.

Then you could have the beagle machine have a link<ARM926>.  If it always has a 
single CPU, you make it a child<ARM926> and the user can't change it.

They can still set properties on the CPU so if there are flags they need to 
tweak, they could.

> For instance,
> in a fully QOM world, trying to run a beagle machine with (say) a 926
> CPU should fail to instantiate, because the 926 CPU won't have the right
> set of irq/gpio inputs and outputs that the beagle machine needs to
> connect up to. (This is the QOM equivalent of trying to ram a 486
> into a Pentium CPU socket.)
>
> I don't think we even have syntax for 2 at the moment except for the
> weird special case of "-cpu foo".

Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We 
could do it very simply and flat or model the individual CPUs as proper types 
which lets you do fancier things with links.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 13:37, Anthony Liguori <anthony@codemonkey.ws> wrote:
> For what you're getting at, you actually want to model the CPUs in QOM such
> that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
>
> Then you could have the beagle machine have a link<ARM926>.  If it always
> has a single CPU, you make it a child<ARM926> and the user can't change it.

The CPU should always be a child of the board, surely, even if the user
might want to use a different one? That's just basic composition.
The links should be for "the CPU has two input IRQ lines" and so on.

(Beagle is an A8, incidentally.)

>> For instance,
>> in a fully QOM world, trying to run a beagle machine with (say) a 926
>> CPU should fail to instantiate, because the 926 CPU won't have the right
>> set of irq/gpio inputs and outputs that the beagle machine needs to
>> connect up to. (This is the QOM equivalent of trying to ram a 486
>> into a Pentium CPU socket.)
>>
>> I don't think we even have syntax for 2 at the moment except for the
>> weird special case of "-cpu foo".
>
>
> Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We
> could do it very simply and flat or model the individual CPUs as proper
> types which lets you do fancier things with links.

What I definitely want is that an ARM CPU should look like any other
device in that it has input (and maybe output) GPIO lines, and (for
MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps.
And instantiating and wiring up 926 (a "simple" unicore) should look
pretty much the same at machine model level as wiring up an A9MP
(a "complicated" multicore with built-in peripheral devices, interrupt
controller, etc, which we'd presumably model as a QOM object which
uses composition for all its peripherals and the "actual CPU").

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 13:37, Anthony Liguori <anthony@codemonkey.ws> wrote:
> For what you're getting at, you actually want to model the CPUs in QOM such
> that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
>
> Then you could have the beagle machine have a link<ARM926>.  If it always
> has a single CPU, you make it a child<ARM926> and the user can't change it.

The CPU should always be a child of the board, surely, even if the user
might want to use a different one? That's just basic composition.
The links should be for "the CPU has two input IRQ lines" and so on.

(Beagle is an A8, incidentally.)

>> For instance,
>> in a fully QOM world, trying to run a beagle machine with (say) a 926
>> CPU should fail to instantiate, because the 926 CPU won't have the right
>> set of irq/gpio inputs and outputs that the beagle machine needs to
>> connect up to. (This is the QOM equivalent of trying to ram a 486
>> into a Pentium CPU socket.)
>>
>> I don't think we even have syntax for 2 at the moment except for the
>> weird special case of "-cpu foo".
>
>
> Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We
> could do it very simply and flat or model the individual CPUs as proper
> types which lets you do fancier things with links.

What I definitely want is that an ARM CPU should look like any other
device in that it has input (and maybe output) GPIO lines, and (for
MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps.
And instantiating and wiring up 926 (a "simple" unicore) should look
pretty much the same at machine model level as wiring up an A9MP
(a "complicated" multicore with built-in peripheral devices, interrupt
controller, etc, which we'd presumably model as a QOM object which
uses composition for all its peripherals and the "actual CPU").

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/03/2012 07:57 AM, Peter Maydell wrote:
> On 3 January 2012 13:37, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> For what you're getting at, you actually want to model the CPUs in QOM such
>> that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
>>
>> Then you could have the beagle machine have a link<ARM926>.  If it always
>> has a single CPU, you make it a child<ARM926>  and the user can't change it.
>
> The CPU should always be a child of the board, surely, even if the user
> might want to use a different one? That's just basic composition.
> The links should be for "the CPU has two input IRQ lines" and so on.

Not in the PC world.

You buy a motherboard with an empty CPU socket and then purchase a CPU 
separately and plug it in.

link<> essentially models any type of socket whereas child<> basically means 
"soldered to the board or embedded in silicon".

It may be true for SoCs that CPUs are always child<> but that's not universal.

>
> (Beagle is an A8, incidentally.)
>
>>> For instance,
>>> in a fully QOM world, trying to run a beagle machine with (say) a 926
>>> CPU should fail to instantiate, because the 926 CPU won't have the right
>>> set of irq/gpio inputs and outputs that the beagle machine needs to
>>> connect up to. (This is the QOM equivalent of trying to ram a 486
>>> into a Pentium CPU socket.)
>>>
>>> I don't think we even have syntax for 2 at the moment except for the
>>> weird special case of "-cpu foo".
>>
>>
>> Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We
>> could do it very simply and flat or model the individual CPUs as proper
>> types which lets you do fancier things with links.
>
> What I definitely want is that an ARM CPU should look like any other
> device in that it has input (and maybe output) GPIO lines, and (for
> MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps.
> And instantiating and wiring up 926 (a "simple" unicore) should look
> pretty much the same at machine model level as wiring up an A9MP
> (a "complicated" multicore with built-in peripheral devices, interrupt
> controller, etc, which we'd presumably model as a QOM object which
> uses composition for all its peripherals and the "actual CPU").

I think I agree with all of this.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/03/2012 07:57 AM, Peter Maydell wrote:
> On 3 January 2012 13:37, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> For what you're getting at, you actually want to model the CPUs in QOM such
>> that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
>>
>> Then you could have the beagle machine have a link<ARM926>.  If it always
>> has a single CPU, you make it a child<ARM926>  and the user can't change it.
>
> The CPU should always be a child of the board, surely, even if the user
> might want to use a different one? That's just basic composition.
> The links should be for "the CPU has two input IRQ lines" and so on.

Not in the PC world.

You buy a motherboard with an empty CPU socket and then purchase a CPU 
separately and plug it in.

link<> essentially models any type of socket whereas child<> basically means 
"soldered to the board or embedded in silicon".

It may be true for SoCs that CPUs are always child<> but that's not universal.

>
> (Beagle is an A8, incidentally.)
>
>>> For instance,
>>> in a fully QOM world, trying to run a beagle machine with (say) a 926
>>> CPU should fail to instantiate, because the 926 CPU won't have the right
>>> set of irq/gpio inputs and outputs that the beagle machine needs to
>>> connect up to. (This is the QOM equivalent of trying to ram a 486
>>> into a Pentium CPU socket.)
>>>
>>> I don't think we even have syntax for 2 at the moment except for the
>>> weird special case of "-cpu foo".
>>
>>
>> Yeah, it's still not clear to me how much we want to model CPUs in QOM.  We
>> could do it very simply and flat or model the individual CPUs as proper
>> types which lets you do fancier things with links.
>
> What I definitely want is that an ARM CPU should look like any other
> device in that it has input (and maybe output) GPIO lines, and (for
> MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps.
> And instantiating and wiring up 926 (a "simple" unicore) should look
> pretty much the same at machine model level as wiring up an A9MP
> (a "complicated" multicore with built-in peripheral devices, interrupt
> controller, etc, which we'd presumably model as a QOM object which
> uses composition for all its peripherals and the "actual CPU").

I think I agree with all of this.

Regards,

Anthony Liguori

> -- PMM
>

Re: KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 14:02, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/03/2012 07:57 AM, Peter Maydell wrote:
>> The CPU should always be a child of the board, surely, even if the user
>> might want to use a different one? That's just basic composition.
>> The links should be for "the CPU has two input IRQ lines" and so on.
>
> Not in the PC world.
>
> You buy a motherboard with an empty CPU socket and then purchase a CPU
> separately and plug it in.
>
> link<> essentially models any type of socket whereas child<> basically means
> "soldered to the board or embedded in silicon".
>
> It may be true for SoCs that CPUs are always child<> but that's not
> universal.

OK, that makes sense, although it leaves me a bit unclear how we
handle the legacy "-cpu" option (clearly useful for users but what it
ought to do to the underlying set of qom objects will vary from machine
to machine...)

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Peter Maydell]

On 3 January 2012 14:02, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/03/2012 07:57 AM, Peter Maydell wrote:
>> The CPU should always be a child of the board, surely, even if the user
>> might want to use a different one? That's just basic composition.
>> The links should be for "the CPU has two input IRQ lines" and so on.
>
> Not in the PC world.
>
> You buy a motherboard with an empty CPU socket and then purchase a CPU
> separately and plug it in.
>
> link<> essentially models any type of socket whereas child<> basically means
> "soldered to the board or embedded in silicon".
>
> It may be true for SoCs that CPUs are always child<> but that's not
> universal.

OK, that makes sense, although it leaves me a bit unclear how we
handle the legacy "-cpu" option (clearly useful for users but what it
ought to do to the underlying set of qom objects will vary from machine
to machine...)

-- PMM

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 07:46 AM, Andreas Färber wrote:
> Am 02.01.2012 13:09, schrieb Juan Quintela:
>> First of all, Happy New Year to everybody (even for the people whose
>> calendar is different O:-)
>
> +1
>
>> Please send in any agenda items you are interested in covering.
>
> QOM: If Anthony is available, I'd be interested in hearing an update on
> the roadmap. In particular,

The moons aligned and I ended up with a week before Christmas of no meetings so 
I ended up doing a bunch of QOM conversions.

In my latest qom-rebase branch, I've got qdev buses modeled through QOM which 
was pretty much the finishing touch.  It's just a matter of how much time we 
need to merge everything.

> * when can we expect to be able to model SoCs rather than CPUs? Will
> this affect command line usage - are we going to have '-device
> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
> container's default?

This is all a bit tricky to get right.  In order to exploit QOM for composition, 
we need to eliminate the qdev "everything has a parent bus" requirement.  I 
believe that that is done in series 3/4.

> * are the announced remaining 3 series going to touch CPUState?

No, but that's the next thing I want to do.  It should be trivial to convert 
CPUState to a proper Object and make -cpu just be a short hand for -device 
x86-cpu,nx=off,mmx2=on,....

> a) Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU? b)

It will definitely be object properties.

> Any plans for adding
> inheritence, e.g., for CPU_COMMON and CPU reset?

Initially, no, but in the long term, it might make sense.  It's probably more 
likely that we have a CPUCommon interface that all of the CPUs implement for 
things like the soft TLB code.  I'm not really sure yet.

> * what's the effect on VMState? Will VMState continue to coexist with
> QOM, or does QOM replace VMState at some point?

VMState is sort of orthogonal to QOM.  What I do want to change is that instead 
of having devices register VMState descriptions, all device serialization 
happens through a virtual method and flows through the composition tree.

> Is it worth introducing
> new size mechanisms now or should we postpone SD/AHCI migration until
> QOM is merged?

I need to look carefully at those patches.

> Testing: A brief clarification on scope, goals and relations (overlap?)
> of all frameworks proposed might be better than a flame war? ;)

In short, with QOM, I'm touching an alarming amount of code and am scared to 
death of breaking things.  So I'm looking to improve my ability to test more 
exotic things.

There are some notes that I haven't responded to yet as I've been AFK for the 
past few days, but I will most likely tomorrow.

Regards,

Anthony Liguori

> Regards,
> Andreas
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/02/2012 07:46 AM, Andreas Färber wrote:
> Am 02.01.2012 13:09, schrieb Juan Quintela:
>> First of all, Happy New Year to everybody (even for the people whose
>> calendar is different O:-)
>
> +1
>
>> Please send in any agenda items you are interested in covering.
>
> QOM: If Anthony is available, I'd be interested in hearing an update on
> the roadmap. In particular,

The moons aligned and I ended up with a week before Christmas of no meetings so 
I ended up doing a bunch of QOM conversions.

In my latest qom-rebase branch, I've got qdev buses modeled through QOM which 
was pretty much the finishing touch.  It's just a matter of how much time we 
need to merge everything.

> * when can we expect to be able to model SoCs rather than CPUs? Will
> this affect command line usage - are we going to have '-device
> ti-tms570' rather than '-cpu cortex-r4' then, or -cpu overriding the
> container's default?

This is all a bit tricky to get right.  In order to exploit QOM for composition, 
we need to eliminate the qdev "everything has a parent bus" requirement.  I 
believe that that is done in series 3/4.

> * are the announced remaining 3 series going to touch CPUState?

No, but that's the next thing I want to do.  It should be trivial to convert 
CPUState to a proper Object and make -cpu just be a short hand for -device 
x86-cpu,nx=off,mmx2=on,....

> a) Are
> CPU features being refactored (standardized) for QOM or should we copy
> current x86 code for controlling ARM FPU? b)

It will definitely be object properties.

> Any plans for adding
> inheritence, e.g., for CPU_COMMON and CPU reset?

Initially, no, but in the long term, it might make sense.  It's probably more 
likely that we have a CPUCommon interface that all of the CPUs implement for 
things like the soft TLB code.  I'm not really sure yet.

> * what's the effect on VMState? Will VMState continue to coexist with
> QOM, or does QOM replace VMState at some point?

VMState is sort of orthogonal to QOM.  What I do want to change is that instead 
of having devices register VMState descriptions, all device serialization 
happens through a virtual method and flows through the composition tree.

> Is it worth introducing
> new size mechanisms now or should we postpone SD/AHCI migration until
> QOM is merged?

I need to look carefully at those patches.

> Testing: A brief clarification on scope, goals and relations (overlap?)
> of all frameworks proposed might be better than a flame war? ;)

In short, with QOM, I'm touching an alarming amount of code and am scared to 
death of breaking things.  So I'm looking to improve my ability to test more 
exotic things.

There are some notes that I haven't responded to yet as I've been AFK for the 
past few days, but I will most likely tomorrow.

Regards,

Anthony Liguori

> Regards,
> Andreas
>

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Andreas Färber]

Anthony,

Am 03.01.2012 02:04, schrieb Anthony Liguori:
> On 01/02/2012 07:46 AM, Andreas Färber wrote:
>> Am 02.01.2012 13:09, schrieb Juan Quintela:
>>> First of all, Happy New Year to everybody (even for the people whose
>>> calendar is different O:-)
>>
>> +1
>>
>>> Please send in any agenda items you are interested in covering.
>>
>> QOM: If Anthony is available, I'd be interested in hearing an update on
>> the roadmap. In particular,
> 
> The moons aligned and I ended up with a week before Christmas of no
> meetings so I ended up doing a bunch of QOM conversions.
[...]

Does your answering of the proposed topics by email indicate that you're
still on vacation and won't be attending the call? Or will today's call
take place with some topics? :S

Andreas

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

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Anthony Liguori]

On 01/03/2012 07:52 AM, Andreas Färber wrote:
> Anthony,
>
> Am 03.01.2012 02:04, schrieb Anthony Liguori:
>> On 01/02/2012 07:46 AM, Andreas Färber wrote:
>>> Am 02.01.2012 13:09, schrieb Juan Quintela:
>>>> First of all, Happy New Year to everybody (even for the people whose
>>>> calendar is different O:-)
>>>
>>> +1
>>>
>>>> Please send in any agenda items you are interested in covering.
>>>
>>> QOM: If Anthony is available, I'd be interested in hearing an update on
>>> the roadmap. In particular,
>>
>> The moons aligned and I ended up with a week before Christmas of no
>> meetings so I ended up doing a bunch of QOM conversions.
> [...]
>
> Does your answering of the proposed topics by email indicate that you're
> still on vacation and won't be attending the call? Or will today's call
> take place with some topics? :S

I'll be on the call so we can talk about it.

Regards,

Anthony Liguori

>
> Andreas
>

Re: KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
> Please send in any agenda items you are interested in covering.

Status of virtio drivers for Windows:
 * Unsupported in community today
 * Bugs languish on bug tracker/mailing list
 * Risking a reputation of not supporting Windows guests properly
 * Ideally:
  * Developers respond to bugs
  * Developers are on IRC
  * We have QEMU.org signed virtio Windows drivers
  * A pony
 * Does anyone care?

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
> Please send in any agenda items you are interested in covering.

Status of virtio drivers for Windows:
 * Unsupported in community today
 * Bugs languish on bug tracker/mailing list
 * Risking a reputation of not supporting Windows guests properly
 * Ideally:
  * Developers respond to bugs
  * Developers are on IRC
  * We have QEMU.org signed virtio Windows drivers
  * A pony
 * Does anyone care?

Re: KVM call agenda for Tuesday 3

[Dor Laor]

On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>> Please send in any agenda items you are interested in covering.
>
> Status of virtio drivers for Windows:
>   * Unsupported in community today

Why?

>   * Bugs languish on bug tracker/mailing list

There are 1.2 developers on them and Vadim does the enlightenment 
support for kvm too. I don't see plenty of issues that are currently 
actively, open, can you point us to such?

>   * Risking a reputation of not supporting Windows guests properly
>   * Ideally:
>    * Developers respond to bugs
>    * Developers are on IRC
>    * We have QEMU.org signed virtio Windows drivers

There is a legal issue w/ WHQL drivers but self sign is not a probably 
and I believe that's what we have today.

>    * A pony
>   * Does anyone care?
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Dor Laor]

On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>> Please send in any agenda items you are interested in covering.
>
> Status of virtio drivers for Windows:
>   * Unsupported in community today

Why?

>   * Bugs languish on bug tracker/mailing list

There are 1.2 developers on them and Vadim does the enlightenment 
support for kvm too. I don't see plenty of issues that are currently 
actively, open, can you point us to such?

>   * Risking a reputation of not supporting Windows guests properly
>   * Ideally:
>    * Developers respond to bugs
>    * Developers are on IRC
>    * We have QEMU.org signed virtio Windows drivers

There is a legal issue w/ WHQL drivers but self sign is not a probably 
and I believe that's what we have today.

>    * A pony
>   * Does anyone care?
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>>
>> Status of virtio drivers for Windows:
>>  * Unsupported in community today
>
>
> Why?

Because there is no one around to answer questions or look into bugs
in a timely manner.

I'm not saying that virtio Windows drivers are unsupported, I'm saying
that the _QEMU community_ isn't supporting them if you look at the
mailing list and bug tracker activity.  Perhaps we should direct
questions about the virtio drivers to some place?  I've already been
CCing and bouncing questions from users to Vadim for several months.

>>  * Bugs languish on bug tracker/mailing list
>
>
> There are 1.2 developers on them and Vadim does the enlightenment support
> for kvm too. I don't see plenty of issues that are currently actively, open,
> can you point us to such?

Yes, this is exactly the point.  Vadim is doing a great job but he's
only 1 person.  Having 1.2 people that handle virtio Windows driver
means the bus factor is dangerous and we cannot scale.

The bug that brought this to mind again:
https://bugs.launchpad.net/qemu/+bug/818673

Another email thread on virtio-balloon driver issues (looks unsolved):
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html

> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
> believe that's what we have today.

For a user anything other than first-class native drivers is a red
flag that this software may work poorly - on modern Windows that means
properly signed drivers.

Although signing might seem like a secondary issue I think it's what
actually has stopped us from growing a community around the virtio
Windows drivers.  There are very few people who can help because a
development environment where you can only contribute patches but not
build the code fully takes the fun away.

Basically I'm asking: is there a way we can do the virtio Windows
driver development more in public, in the community, so that we will
grow stronger in KVM Windows guest support?

How do we bootstrap this into more than 1.2 people who can hack on and
help with guest drivers?

My suggestions are for those already involved to actively join IRC,
mailing list, and bug tracker so they can pass on their knowledge and
watch for questions.  Also, if there are known bugs and TODOs then
please post them so folks with time and interest can help get them
fixed.

Stefan

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>
>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>>
>> Status of virtio drivers for Windows:
>>  * Unsupported in community today
>
>
> Why?

Because there is no one around to answer questions or look into bugs
in a timely manner.

I'm not saying that virtio Windows drivers are unsupported, I'm saying
that the _QEMU community_ isn't supporting them if you look at the
mailing list and bug tracker activity.  Perhaps we should direct
questions about the virtio drivers to some place?  I've already been
CCing and bouncing questions from users to Vadim for several months.

>>  * Bugs languish on bug tracker/mailing list
>
>
> There are 1.2 developers on them and Vadim does the enlightenment support
> for kvm too. I don't see plenty of issues that are currently actively, open,
> can you point us to such?

Yes, this is exactly the point.  Vadim is doing a great job but he's
only 1 person.  Having 1.2 people that handle virtio Windows driver
means the bus factor is dangerous and we cannot scale.

The bug that brought this to mind again:
https://bugs.launchpad.net/qemu/+bug/818673

Another email thread on virtio-balloon driver issues (looks unsolved):
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html

> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
> believe that's what we have today.

For a user anything other than first-class native drivers is a red
flag that this software may work poorly - on modern Windows that means
properly signed drivers.

Although signing might seem like a secondary issue I think it's what
actually has stopped us from growing a community around the virtio
Windows drivers.  There are very few people who can help because a
development environment where you can only contribute patches but not
build the code fully takes the fun away.

Basically I'm asking: is there a way we can do the virtio Windows
driver development more in public, in the community, so that we will
grow stronger in KVM Windows guest support?

How do we bootstrap this into more than 1.2 people who can hack on and
help with guest drivers?

My suggestions are for those already involved to actively join IRC,
mailing list, and bug tracker so they can pass on their knowledge and
watch for questions.  Also, if there are known bugs and TODOs then
please post them so folks with time and interest can help get them
fixed.

Stefan

Re: KVM call agenda for Tuesday 3

[Andreas Färber]

Am 03.01.2012 14:12, schrieb Stefan Hajnoczi:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
>> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
>> believe that's what we have today.
> 
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
> 
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
> 
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?

Well, that's why we're putting effort into AHCI emulation. It's almost
as fast for hard disks and has native driver support, avoiding the whole
WHQL issue and providing a much nicer user experience.

Andreas

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

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Andreas Färber]

Am 03.01.2012 14:12, schrieb Stefan Hajnoczi:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
>> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
>> believe that's what we have today.
> 
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
> 
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
> 
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?

Well, that's why we're putting effort into AHCI emulation. It's almost
as fast for hard disks and has native driver support, avoiding the whole
WHQL issue and providing a much nicer user experience.

Andreas

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

Re: KVM call agenda for Tuesday 3

[Vadim Rozenfeld]

On Tue, 2012-01-03 at 13:12 +0000, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
> > On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
> >>
> >> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
> >>>
> >>> Please send in any agenda items you are interested in covering.
> >>
> >>
> >> Status of virtio drivers for Windows:
> >>  * Unsupported in community today
> >
> >
> > Why?
> 
> Because there is no one around to answer questions or look into bugs
> in a timely manner.
> 
> I'm not saying that virtio Windows drivers are unsupported, I'm saying
> that the _QEMU community_ isn't supporting them if you look at the
> mailing list and bug tracker activity.  Perhaps we should direct
> questions about the virtio drivers to some place?  I've already been
> CCing and bouncing questions from users to Vadim for several months.
> 
> >>  * Bugs languish on bug tracker/mailing list
> >
> >
> > There are 1.2 developers on them and Vadim does the enlightenment support
> > for kvm too. I don't see plenty of issues that are currently actively, open,
> > can you point us to such?
> 
> Yes, this is exactly the point.  Vadim is doing a great job but he's
> only 1 person.  Having 1.2 people that handle virtio Windows driver
> means the bus factor is dangerous and we cannot scale.
> 
> The bug that brought this to mind again:
> https://bugs.launchpad.net/qemu/+bug/818673
> 
> Another email thread on virtio-balloon driver issues (looks unsolved):
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
> 
> > There is a legal issue w/ WHQL drivers but self sign is not a probably and I
> > believe that's what we have today.
> 
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
> 
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
> 
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?
> 
More QA resources for WHQL testing against upstream QEMU and KVM, and
different distributions, including Fedora, Ubuntu, etc. And one more
Software Engineer/Software Engineer In Test who will be in touch with
community.

Cheers,
Vadim.
> How do we bootstrap this into more than 1.2 people who can hack on and
> help with guest drivers?
> 
> My suggestions are for those already involved to actively join IRC,
> mailing list, and bug tracker so they can pass on their knowledge and
> watch for questions.  Also, if there are known bugs and TODOs then
> please post them so folks with time and interest can help get them
> fixed.
> 
> Stefan

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Vadim Rozenfeld]

On Tue, 2012-01-03 at 13:12 +0000, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor <dlaor@redhat.com> wrote:
> > On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
> >>
> >> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
> >>>
> >>> Please send in any agenda items you are interested in covering.
> >>
> >>
> >> Status of virtio drivers for Windows:
> >>  * Unsupported in community today
> >
> >
> > Why?
> 
> Because there is no one around to answer questions or look into bugs
> in a timely manner.
> 
> I'm not saying that virtio Windows drivers are unsupported, I'm saying
> that the _QEMU community_ isn't supporting them if you look at the
> mailing list and bug tracker activity.  Perhaps we should direct
> questions about the virtio drivers to some place?  I've already been
> CCing and bouncing questions from users to Vadim for several months.
> 
> >>  * Bugs languish on bug tracker/mailing list
> >
> >
> > There are 1.2 developers on them and Vadim does the enlightenment support
> > for kvm too. I don't see plenty of issues that are currently actively, open,
> > can you point us to such?
> 
> Yes, this is exactly the point.  Vadim is doing a great job but he's
> only 1 person.  Having 1.2 people that handle virtio Windows driver
> means the bus factor is dangerous and we cannot scale.
> 
> The bug that brought this to mind again:
> https://bugs.launchpad.net/qemu/+bug/818673
> 
> Another email thread on virtio-balloon driver issues (looks unsolved):
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
> 
> > There is a legal issue w/ WHQL drivers but self sign is not a probably and I
> > believe that's what we have today.
> 
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
> 
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
> 
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?
> 
More QA resources for WHQL testing against upstream QEMU and KVM, and
different distributions, including Fedora, Ubuntu, etc. And one more
Software Engineer/Software Engineer In Test who will be in touch with
community.

Cheers,
Vadim.
> How do we bootstrap this into more than 1.2 people who can hack on and
> help with guest drivers?
> 
> My suggestions are for those already involved to actively join IRC,
> mailing list, and bug tracker so they can pass on their knowledge and
> watch for questions.  Also, if there are known bugs and TODOs then
> please post them so folks with time and interest can help get them
> fixed.
> 
> Stefan

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Cao,Bing Bu]

On 01/03/2012 09:12 PM, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor<dlaor@redhat.com>  wrote:
>> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>>
>>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>>
>>>> Please send in any agenda items you are interested in covering.
>>>
>>>
>>> Status of virtio drivers for Windows:
>>>   * Unsupported in community today
>>
>>
>> Why?
>
> Because there is no one around to answer questions or look into bugs
> in a timely manner.
>
> I'm not saying that virtio Windows drivers are unsupported, I'm saying
> that the _QEMU community_ isn't supporting them if you look at the
> mailing list and bug tracker activity.  Perhaps we should direct
> questions about the virtio drivers to some place?  I've already been
> CCing and bouncing questions from users to Vadim for several months.
>
>>>   * Bugs languish on bug tracker/mailing list
>>
>>
>> There are 1.2 developers on them and Vadim does the enlightenment support
>> for kvm too. I don't see plenty of issues that are currently actively, open,
>> can you point us to such?
>
> Yes, this is exactly the point.  Vadim is doing a great job but he's
> only 1 person.  Having 1.2 people that handle virtio Windows driver
> means the bus factor is dangerous and we cannot scale.
>
> The bug that brought this to mind again:
> https://bugs.launchpad.net/qemu/+bug/818673
>
> Another email thread on virtio-balloon driver issues (looks unsolved):
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
>
>> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
>> believe that's what we have today.
>
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
>
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
>
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?
>
> How do we bootstrap this into more than 1.2 people who can hack on and
> help with guest drivers?
>
> My suggestions are for those already involved to actively join IRC,
> mailing list, and bug tracker so they can pass on their knowledge and
> watch for questions.  Also, if there are known bugs and TODOs then
> please post them so folks with time and interest can help get them
> fixed.
>
> Stefan
>

Agree.

I am focusing on virtio drivers for windows in the past half a year.
I did some virtio driver test on several windows editions.
And read some virtio driver code to help me understanding it deeper.

But some questions surely will be met,in this occasion,the only way to 
get help is sending mail to Vadim. ;P

I do think it will be very good and helpful for me if there will be a 
place(mailing list,bug tracker,...)that I can join,QA,contribute.


BTW:
what is 1.2 people?
It's 1 and 1/5 ? :)


-- 
Best Regards,
Cao,Bing Bu

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Cao,Bing Bu]

On 01/03/2012 09:12 PM, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor<dlaor@redhat.com>  wrote:
>> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>>
>>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>>
>>>> Please send in any agenda items you are interested in covering.
>>>
>>>
>>> Status of virtio drivers for Windows:
>>>   * Unsupported in community today
>>
>>
>> Why?
>
> Because there is no one around to answer questions or look into bugs
> in a timely manner.
>
> I'm not saying that virtio Windows drivers are unsupported, I'm saying
> that the _QEMU community_ isn't supporting them if you look at the
> mailing list and bug tracker activity.  Perhaps we should direct
> questions about the virtio drivers to some place?  I've already been
> CCing and bouncing questions from users to Vadim for several months.
>
>>>   * Bugs languish on bug tracker/mailing list
>>
>>
>> There are 1.2 developers on them and Vadim does the enlightenment support
>> for kvm too. I don't see plenty of issues that are currently actively, open,
>> can you point us to such?
>
> Yes, this is exactly the point.  Vadim is doing a great job but he's
> only 1 person.  Having 1.2 people that handle virtio Windows driver
> means the bus factor is dangerous and we cannot scale.
>
> The bug that brought this to mind again:
> https://bugs.launchpad.net/qemu/+bug/818673
>
> Another email thread on virtio-balloon driver issues (looks unsolved):
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
>
>> There is a legal issue w/ WHQL drivers but self sign is not a probably and I
>> believe that's what we have today.
>
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
>
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
>
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?
>
> How do we bootstrap this into more than 1.2 people who can hack on and
> help with guest drivers?
>
> My suggestions are for those already involved to actively join IRC,
> mailing list, and bug tracker so they can pass on their knowledge and
> watch for questions.  Also, if there are known bugs and TODOs then
> please post them so folks with time and interest can help get them
> fixed.
>
> Stefan
>

Agree.

I am focusing on virtio drivers for windows in the past half a year.
I did some virtio driver test on several windows editions.
And read some virtio driver code to help me understanding it deeper.

But some questions surely will be met,in this occasion,the only way to 
get help is sending mail to Vadim. ;P

I do think it will be very good and helpful for me if there will be a 
place(mailing list,bug tracker,...)that I can join,QA,contribute.


BTW:
what is 1.2 people?
It's 1 and 1/5 ? :)


-- 
Best Regards,
Cao,Bing Bu

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Wed, Jan 4, 2012 at 2:47 AM, Cao,Bing Bu <mars@linux.vnet.ibm.com> wrote:
> On 01/03/2012 09:12 PM, Stefan Hajnoczi wrote:
>>
>> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor<dlaor@redhat.com>  wrote:
>>>
>>> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>>>
>>>>
>>>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>>>
>>>>>
>>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>>
>>>>
>>>> Status of virtio drivers for Windows:
>>>>  * Unsupported in community today
>>>
>>>
>>>
>>> Why?
>>
>>
>> Because there is no one around to answer questions or look into bugs
>> in a timely manner.
>>
>> I'm not saying that virtio Windows drivers are unsupported, I'm saying
>> that the _QEMU community_ isn't supporting them if you look at the
>> mailing list and bug tracker activity.  Perhaps we should direct
>> questions about the virtio drivers to some place?  I've already been
>> CCing and bouncing questions from users to Vadim for several months.
>>
>>>>  * Bugs languish on bug tracker/mailing list
>>>
>>>
>>>
>>> There are 1.2 developers on them and Vadim does the enlightenment support
>>> for kvm too. I don't see plenty of issues that are currently actively,
>>> open,
>>> can you point us to such?
>>
>>
>> Yes, this is exactly the point.  Vadim is doing a great job but he's
>> only 1 person.  Having 1.2 people that handle virtio Windows driver
>> means the bus factor is dangerous and we cannot scale.
>>
>> The bug that brought this to mind again:
>> https://bugs.launchpad.net/qemu/+bug/818673
>>
>> Another email thread on virtio-balloon driver issues (looks unsolved):
>> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
>>
>>> There is a legal issue w/ WHQL drivers but self sign is not a probably
>>> and I
>>> believe that's what we have today.
>>
>>
>> For a user anything other than first-class native drivers is a red
>> flag that this software may work poorly - on modern Windows that means
>> properly signed drivers.
>>
>> Although signing might seem like a secondary issue I think it's what
>> actually has stopped us from growing a community around the virtio
>> Windows drivers.  There are very few people who can help because a
>> development environment where you can only contribute patches but not
>> build the code fully takes the fun away.
>>
>> Basically I'm asking: is there a way we can do the virtio Windows
>> driver development more in public, in the community, so that we will
>> grow stronger in KVM Windows guest support?
>>
>> How do we bootstrap this into more than 1.2 people who can hack on and
>> help with guest drivers?
>>
>> My suggestions are for those already involved to actively join IRC,
>> mailing list, and bug tracker so they can pass on their knowledge and
>> watch for questions.  Also, if there are known bugs and TODOs then
>> please post them so folks with time and interest can help get them
>> fixed.
>>
>> Stefan
>>
>
> Agree.
>
> I am focusing on virtio drivers for windows in the past half a year.
> I did some virtio driver test on several windows editions.
> And read some virtio driver code to help me understanding it deeper.
>
> But some questions surely will be met,in this occasion,the only way to get
> help is sending mail to Vadim. ;P
>
> I do think it will be very good and helpful for me if there will be a
> place(mailing list,bug tracker,...)that I can join,QA,contribute.

Great, the best way to start is to watch qemu-devel and kvm mailing
lists for Windows-related questions.  The bug tracker automatically
sends notifications to the mailing list so you'll also see new bugs.

Perhaps you want to look into the bug I linked in my previous email.
Several users have reported the problem and it would be great to fix
it:
https://bugs.launchpad.net/qemu/+bug/818673

> BTW:
> what is 1.2 people?
> It's 1 and 1/5 ? :)

The 0.2 is someone who is not working full-time on virtio Windows
drivers.  They have other responsibilities too.

Stefan

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Stefan Hajnoczi]

On Wed, Jan 4, 2012 at 2:47 AM, Cao,Bing Bu <mars@linux.vnet.ibm.com> wrote:
> On 01/03/2012 09:12 PM, Stefan Hajnoczi wrote:
>>
>> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor<dlaor@redhat.com>  wrote:
>>>
>>> On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
>>>>
>>>>
>>>> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
>>>>>
>>>>>
>>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>>
>>>>
>>>> Status of virtio drivers for Windows:
>>>>  * Unsupported in community today
>>>
>>>
>>>
>>> Why?
>>
>>
>> Because there is no one around to answer questions or look into bugs
>> in a timely manner.
>>
>> I'm not saying that virtio Windows drivers are unsupported, I'm saying
>> that the _QEMU community_ isn't supporting them if you look at the
>> mailing list and bug tracker activity.  Perhaps we should direct
>> questions about the virtio drivers to some place?  I've already been
>> CCing and bouncing questions from users to Vadim for several months.
>>
>>>>  * Bugs languish on bug tracker/mailing list
>>>
>>>
>>>
>>> There are 1.2 developers on them and Vadim does the enlightenment support
>>> for kvm too. I don't see plenty of issues that are currently actively,
>>> open,
>>> can you point us to such?
>>
>>
>> Yes, this is exactly the point.  Vadim is doing a great job but he's
>> only 1 person.  Having 1.2 people that handle virtio Windows driver
>> means the bus factor is dangerous and we cannot scale.
>>
>> The bug that brought this to mind again:
>> https://bugs.launchpad.net/qemu/+bug/818673
>>
>> Another email thread on virtio-balloon driver issues (looks unsolved):
>> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
>>
>>> There is a legal issue w/ WHQL drivers but self sign is not a probably
>>> and I
>>> believe that's what we have today.
>>
>>
>> For a user anything other than first-class native drivers is a red
>> flag that this software may work poorly - on modern Windows that means
>> properly signed drivers.
>>
>> Although signing might seem like a secondary issue I think it's what
>> actually has stopped us from growing a community around the virtio
>> Windows drivers.  There are very few people who can help because a
>> development environment where you can only contribute patches but not
>> build the code fully takes the fun away.
>>
>> Basically I'm asking: is there a way we can do the virtio Windows
>> driver development more in public, in the community, so that we will
>> grow stronger in KVM Windows guest support?
>>
>> How do we bootstrap this into more than 1.2 people who can hack on and
>> help with guest drivers?
>>
>> My suggestions are for those already involved to actively join IRC,
>> mailing list, and bug tracker so they can pass on their knowledge and
>> watch for questions.  Also, if there are known bugs and TODOs then
>> please post them so folks with time and interest can help get them
>> fixed.
>>
>> Stefan
>>
>
> Agree.
>
> I am focusing on virtio drivers for windows in the past half a year.
> I did some virtio driver test on several windows editions.
> And read some virtio driver code to help me understanding it deeper.
>
> But some questions surely will be met,in this occasion,the only way to get
> help is sending mail to Vadim. ;P
>
> I do think it will be very good and helpful for me if there will be a
> place(mailing list,bug tracker,...)that I can join,QA,contribute.

Great, the best way to start is to watch qemu-devel and kvm mailing
lists for Windows-related questions.  The bug tracker automatically
sends notifications to the mailing list so you'll also see new bugs.

Perhaps you want to look into the bug I linked in my previous email.
Several users have reported the problem and it would be great to fix
it:
https://bugs.launchpad.net/qemu/+bug/818673

> BTW:
> what is 1.2 people?
> It's 1 and 1/5 ? :)

The 0.2 is someone who is not working full-time on virtio Windows
drivers.  They have other responsibilities too.

Stefan