KVM call minutes for Feb 8

KVM call minutes for Feb 8

[Chris Wright]

Automated builds and testing
- found broken 32-bit
- luiz suggested running against maintainer trees
- daniel gollub offered to take on maintenance
- integration with kvm-autotest?
  - lucas, daniel, stefan...
  - testing each git commit is probably overkill and too expensive
  - current autotest run (each 48-hours to batch it up)
  - stefan currently running once a day, autotest run is 3 hours, so
    daily should work
- need an integration tree to run build test on?
  - probably still too early

QEMU testing
- kvm unit tests
  - small standalone kernel that exercises paths that have shown bugs
    http://git.kernel.org/?p=virt/kvm/kvm-unit-tests.git;a=summary
- Michael Roth recent sent RFC for qtest
  (http://www.mail-archive.com/qemu-devel@nongnu.org/msg54191.html)
  - test module (->init(), ->run()) which runs in place of vcpu threads to
    set up a test framework to do targetted testing, for example, of devices
  - normal C code, access to qemu internal functions
  - not just functional device testing, but can also to fuzz testing
  - looking feedback/users/test developers/etc
- PPC (just kernel + initrd to boot, and verify boots are identical)
  - full install in many cases is too long, and can trigger other issues
    (alex had examples of emulation being slow enough that login screen
    times out)
- tcg basic testing to verify qemu-kvm patch isn't breaking tcg

Cross version migration (new->old version migration thread)
- downstreams want this, support this upstream?
- versions vs. subsections (subsections should allow this to work)
- (as usual) more vmstate conversion needed
- qdev/vmstate both examples of partially completed work that need more
  attention 

[Qemu-devel] KVM call minutes for Feb 8

[Chris Wright]

Automated builds and testing
- found broken 32-bit
- luiz suggested running against maintainer trees
- daniel gollub offered to take on maintenance
- integration with kvm-autotest?
  - lucas, daniel, stefan...
  - testing each git commit is probably overkill and too expensive
  - current autotest run (each 48-hours to batch it up)
  - stefan currently running once a day, autotest run is 3 hours, so
    daily should work
- need an integration tree to run build test on?
  - probably still too early

QEMU testing
- kvm unit tests
  - small standalone kernel that exercises paths that have shown bugs
    http://git.kernel.org/?p=virt/kvm/kvm-unit-tests.git;a=summary
- Michael Roth recent sent RFC for qtest
  (http://www.mail-archive.com/qemu-devel@nongnu.org/msg54191.html)
  - test module (->init(), ->run()) which runs in place of vcpu threads to
    set up a test framework to do targetted testing, for example, of devices
  - normal C code, access to qemu internal functions
  - not just functional device testing, but can also to fuzz testing
  - looking feedback/users/test developers/etc
- PPC (just kernel + initrd to boot, and verify boots are identical)
  - full install in many cases is too long, and can trigger other issues
    (alex had examples of emulation being slow enough that login screen
    times out)
- tcg basic testing to verify qemu-kvm patch isn't breaking tcg

Cross version migration (new->old version migration thread)
- downstreams want this, support this upstream?
- versions vs. subsections (subsections should allow this to work)
- (as usual) more vmstate conversion needed
- qdev/vmstate both examples of partially completed work that need more
  attention 

Re: KVM call minutes for Feb 8

[Stefan Hajnoczi]

On Tue, Feb 8, 2011 at 3:55 PM, Chris Wright <chrisw@redhat.com> wrote:
> Automated builds and testing
> - found broken 32-bit

The broken build was found (and fixed?) before automated qemu.git
builds.  It's a good motivator though.

Stefan

[Qemu-devel] Re: KVM call minutes for Feb 8

[Stefan Hajnoczi]

On Tue, Feb 8, 2011 at 3:55 PM, Chris Wright <chrisw@redhat.com> wrote:
> Automated builds and testing
> - found broken 32-bit

The broken build was found (and fixed?) before automated qemu.git
builds.  It's a good motivator though.

Stefan

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 09:55 AM, Chris Wright wrote:
> Automated builds and testing
> - found broken 32-bit
> - luiz suggested running against maintainer trees
> - daniel gollub offered to take on maintenance
> - integration with kvm-autotest?
>    - lucas, daniel, stefan...
>    - testing each git commit is probably overkill and too expensive
>    - current autotest run (each 48-hours to batch it up)
>    - stefan currently running once a day, autotest run is 3 hours, so
>      daily should work
> - need an integration tree to run build test on?
>    - probably still too early
>    

The best types of tests are in-tree, built by default, and can be run in 
less than a few minutes with a simple command invocation and requires no 
external dependencies.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 09:55 AM, Chris Wright wrote:
> Automated builds and testing
> - found broken 32-bit
> - luiz suggested running against maintainer trees
> - daniel gollub offered to take on maintenance
> - integration with kvm-autotest?
>    - lucas, daniel, stefan...
>    - testing each git commit is probably overkill and too expensive
>    - current autotest run (each 48-hours to batch it up)
>    - stefan currently running once a day, autotest run is 3 hours, so
>      daily should work
> - need an integration tree to run build test on?
>    - probably still too early
>    

The best types of tests are in-tree, built by default, and can be run in 
less than a few minutes with a simple command invocation and requires no 
external dependencies.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Chris Wright <chrisw@redhat.com> writes:

[...]
> - qdev/vmstate both examples of partially completed work that need more
>   attention 

As far as qdev's concerned, I can see two kinds of to-dos:

* Further develop qdev so that more of the machine init code can becomes
  qdev declarations.  Specific ideas welcome.  Patches even more, as
  always.

* Convert the remaining devices.  They are typically used only with
  oddball machines, which makes the conversion hard to test for anyone
  who's not already using them.

  I've said this before: at some point in time (sooner rather than
  later, if you ask me), we need to shoot the stragglers.  I'm pretty
  optimistic that any victims worth keeping will receive timely
  attention then.

Anything else?

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Chris Wright <chrisw@redhat.com> writes:

[...]
> - qdev/vmstate both examples of partially completed work that need more
>   attention 

As far as qdev's concerned, I can see two kinds of to-dos:

* Further develop qdev so that more of the machine init code can becomes
  qdev declarations.  Specific ideas welcome.  Patches even more, as
  always.

* Convert the remaining devices.  They are typically used only with
  oddball machines, which makes the conversion hard to test for anyone
  who's not already using them.

  I've said this before: at some point in time (sooner rather than
  later, if you ask me), we need to shoot the stragglers.  I'm pretty
  optimistic that any victims worth keeping will receive timely
  attention then.

Anything else?

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 8 February 2011 17:13, Markus Armbruster <armbru@redhat.com> wrote:
> As far as qdev's concerned, I can see two kinds of to-dos:
>
> * Further develop qdev so that more of the machine init code can becomes
>  qdev declarations.  Specific ideas welcome.  Patches even more, as
>  always.
>
> * Convert the remaining devices.  They are typically used only with
>  oddball machines, which makes the conversion hard to test for anyone
>  who's not already using them.
>
>  I've said this before: at some point in time (sooner rather than
>  later, if you ask me), we need to shoot the stragglers.  I'm pretty
>  optimistic that any victims worth keeping will receive timely
>  attention then.

So on IRC pbrook wrote:
<pbrook> So we have a bunch of devices that nominally claim to use the
qdev infrastructure, but are still making assumptions that qdev was
supposed to remove, so break horribly when you actually try to use it
as intended.

...and my question is: where is the documentation on how to do
a good conversion of a device to qdev, how it works, what the
assumptions you can/can't make are, etc ? I can't see anything
relevant in the source tree or on the website, but maybe I'm just
looking in the wrong places...

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 01:02 PM, Peter Maydell wrote:
> On 8 February 2011 17:13, Markus Armbruster<armbru@redhat.com>  wrote:
>    
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>>   always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>   oddball machines, which makes the conversion hard to test for anyone
>>   who's not already using them.
>>
>>   I've said this before: at some point in time (sooner rather than
>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>   optimistic that any victims worth keeping will receive timely
>>   attention then.
>>      
> So on IRC pbrook wrote:
> <pbrook>  So we have a bunch of devices that nominally claim to use the
> qdev infrastructure, but are still making assumptions that qdev was
> supposed to remove, so break horribly when you actually try to use it
> as intended.
>
> ...and my question is: where is the documentation on how to do
> a good conversion of a device to qdev, how it works, what the
> assumptions you can/can't make are, etc ?

It's basically good OOP modelling and the way qdev is structured today 
makes it very easy to do bad OOP modelling.

Regards,

Anthony Liguori

>   I can't see anything
> relevant in the source tree or on the website, but maybe I'm just
> looking in the wrong places...
>
> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 01:02 PM, Peter Maydell wrote:
> On 8 February 2011 17:13, Markus Armbruster<armbru@redhat.com>  wrote:
>    
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>>   always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>   oddball machines, which makes the conversion hard to test for anyone
>>   who's not already using them.
>>
>>   I've said this before: at some point in time (sooner rather than
>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>   optimistic that any victims worth keeping will receive timely
>>   attention then.
>>      
> So on IRC pbrook wrote:
> <pbrook>  So we have a bunch of devices that nominally claim to use the
> qdev infrastructure, but are still making assumptions that qdev was
> supposed to remove, so break horribly when you actually try to use it
> as intended.
>
> ...and my question is: where is the documentation on how to do
> a good conversion of a device to qdev, how it works, what the
> assumptions you can/can't make are, etc ?

It's basically good OOP modelling and the way qdev is structured today 
makes it very easy to do bad OOP modelling.

Regards,

Anthony Liguori

>   I can't see anything
> relevant in the source tree or on the website, but maybe I'm just
> looking in the wrong places...
>
> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 8 February 2011 17:13, Markus Armbruster <armbru@redhat.com> wrote:
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>  qdev declarations.  Specific ideas welcome.  Patches even more, as
>>  always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>  oddball machines, which makes the conversion hard to test for anyone
>>  who's not already using them.
>>
>>  I've said this before: at some point in time (sooner rather than
>>  later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>  optimistic that any victims worth keeping will receive timely
>>  attention then.
>
> So on IRC pbrook wrote:
> <pbrook> So we have a bunch of devices that nominally claim to use the
> qdev infrastructure, but are still making assumptions that qdev was
> supposed to remove, so break horribly when you actually try to use it
> as intended.
>
> ...and my question is: where is the documentation on how to do
> a good conversion of a device to qdev, how it works, what the
> assumptions you can/can't make are, etc ? I can't see anything
> relevant in the source tree or on the website, but maybe I'm just
> looking in the wrong places...

Unfortunately, you're not.

Paul created qdev.  Others, including Gerd and myself, put it to use in
targets we care for, working from the examples Paul set and not much
else.  We had to grow it some along the way.  Still, the brain to pick
for what assumptions qdev was supposed to remove is Paul's.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 9 February 2011 08:11, Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> Markus Armbruster <armbru@redhat.com> wrote:
>>> I've said this before: at some point in time (sooner rather than
>>>  later, if you ask me), we need to shoot the stragglers.

>> ...and my question is: where is the documentation on how to do
>> a good conversion of a device to qdev, how it works, what the
>> assumptions you can/can't make are, etc ? I can't see anything
>> relevant in the source tree or on the website, but maybe I'm just
>> looking in the wrong places...
>
> Unfortunately, you're not.

It seems to me that if you want the maintainers of the random
oddball platforms and devices to do qdev conversion, this is
much more likely to happen if it's clearly documented how to
do it. Otherwise the only people who can do a good qdev
conversion are the people who care about qdev and it has
to be their responsibility to convert everybody over...

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 9 February 2011 08:11, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> Markus Armbruster <armbru@redhat.com> wrote:
>>>> I've said this before: at some point in time (sooner rather than
>>>>  later, if you ask me), we need to shoot the stragglers.
>
>>> ...and my question is: where is the documentation on how to do
>>> a good conversion of a device to qdev, how it works, what the
>>> assumptions you can/can't make are, etc ? I can't see anything
>>> relevant in the source tree or on the website, but maybe I'm just
>>> looking in the wrong places...
>>
>> Unfortunately, you're not.
>
> It seems to me that if you want the maintainers of the random
> oddball platforms and devices to do qdev conversion, this is
> much more likely to happen if it's clearly documented how to
> do it. Otherwise the only people who can do a good qdev
> conversion are the people who care about qdev and it has
> to be their responsibility to convert everybody over...

I regret the lack of proper qdev documentation as much as anyone.  For
what it's worth, the lone file on qdev in doc/ bears my fingerprints.
Still, it's difficult for me to second-guess the original designer.
Yes, it's quite fair to ask the folks calling for qdevification (read:
*me*) to support that with better documentation.  But I think it's also
fair to ask the man who designed qdev and has been so critical much of
its use (read: Paul) to provide a bit more guidance.

Paul, please?

Re: [Qemu-devel] KVM call minutes for Feb 8

[Alexander Graf]

On 08.02.2011, at 18:13, Markus Armbruster <armbru@redhat.com> wrote:

> Chris Wright <chrisw@redhat.com> writes:
> 
> [...]
>> - qdev/vmstate both examples of partially completed work that need more
>>  attention 
> 
> As far as qdev's concerned, I can see two kinds of to-dos:
> 
> * Further develop qdev so that more of the machine init code can becomes
>  qdev declarations.  Specific ideas welcome.  Patches even more, as
>  always.
> 
> * Convert the remaining devices.  They are typically used only with
>  oddball machines, which makes the conversion hard to test for anyone
>  who's not already using them.
> 
>  I've said this before: at some point in time (sooner rather than
>  later, if you ask me), we need to shoot the stragglers.  I'm pretty
>  optimistic that any victims worth keeping will receive timely
>  attention then.

This is the wrong approach. If you were to change the syntax of kmalloc in Linux and only converted mainstream x86 users, leaving the rest for the subsystem maintainers to figure out, your patch would simply get rejected.

Asking for help on conversions is one thing, forcing work on others another. I'd gladly give anyone access to 'oddball' machine images.

Alex

> 

Re: [Qemu-devel] KVM call minutes for Feb 8

[Aurelien Jarno]

On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
> Chris Wright <chrisw@redhat.com> writes:
> 
> [...]
> > - qdev/vmstate both examples of partially completed work that need more
> >   attention 
> 
> As far as qdev's concerned, I can see two kinds of to-dos:
> 
> * Further develop qdev so that more of the machine init code can becomes
>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>   always.
> 
> * Convert the remaining devices.  They are typically used only with
>   oddball machines, which makes the conversion hard to test for anyone
>   who's not already using them.
> 
>   I've said this before: at some point in time (sooner rather than
>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>   optimistic that any victims worth keeping will receive timely
>   attention then.
> 

For those oddball machines, qdev doesn't really bring anything, that's
why there is so little interest in converting them, and why I prefer to
spend my time on the emulation correctness than converting those
remaining to qdev. Of course I agree it's something to do, and with an
unlimited amount of free time, I'll do them immediately. 

Let's take for example the SH4 target. It's nice to be able to create 
the whole machine from a script, except your kernel won't boot if the
machine:
- has a different cpu
- doesn't a SM501 chipset
- has not the correct memory size
- doesn't have 2 serial port

That basically only leaves the PCI and USB devices configurable, but
those are already using qdev.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>> Chris Wright <chrisw@redhat.com> writes:
>> 
>> [...]
>> > - qdev/vmstate both examples of partially completed work that need more
>> >   attention 
>> 
>> As far as qdev's concerned, I can see two kinds of to-dos:
>> 
>> * Further develop qdev so that more of the machine init code can becomes
>>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>>   always.
>> 
>> * Convert the remaining devices.  They are typically used only with
>>   oddball machines, which makes the conversion hard to test for anyone
>>   who's not already using them.
>> 
>>   I've said this before: at some point in time (sooner rather than
>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>   optimistic that any victims worth keeping will receive timely
>>   attention then.
>> 
>
> For those oddball machines, qdev doesn't really bring anything, that's
> why there is so little interest in converting them, and why I prefer to
> spend my time on the emulation correctness than converting those
> remaining to qdev. Of course I agree it's something to do, and with an
> unlimited amount of free time, I'll do them immediately. 
>
> Let's take for example the SH4 target. It's nice to be able to create 
> the whole machine from a script, except your kernel won't boot if the
> machine:
> - has a different cpu
> - doesn't a SM501 chipset
> - has not the correct memory size
> - doesn't have 2 serial port
>
> That basically only leaves the PCI and USB devices configurable, but
> those are already using qdev.

I understand where you come from.

Converting to qdev isn't free.  But not doing so isn't free either.

QEMU offers two interfaces to device models, legacy and qdev[*].
Maintaining the legacy interface isn't free.  Users of the legacy
interface serve as bad examples.  If we don't pay attention, we can even
get the two mixed up in the same device model.


[*] The two overlap in places.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>    
>> Chris Wright<chrisw@redhat.com>  writes:
>>
>> [...]
>>      
>>> - qdev/vmstate both examples of partially completed work that need more
>>>    attention
>>>        
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>    qdev declarations.  Specific ideas welcome.  Patches even more, as
>>    always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>    oddball machines, which makes the conversion hard to test for anyone
>>    who's not already using them.
>>
>>    I've said this before: at some point in time (sooner rather than
>>    later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>    optimistic that any victims worth keeping will receive timely
>>    attention then.
>>
>>      
> For those oddball machines, qdev doesn't really bring anything, that's
> why there is so little interest in converting them, and why I prefer to
> spend my time on the emulation correctness than converting those
> remaining to qdev. Of course I agree it's something to do, and with an
> unlimited amount of free time, I'll do them immediately.
>
> Let's take for example the SH4 target. It's nice to be able to create
> the whole machine from a script, except your kernel won't boot if the
> machine:
> - has a different cpu
> - doesn't a SM501 chipset
> - has not the correct memory size
> - doesn't have 2 serial port
>    

qdev needs a v2.  The object model is very difficult to work with and it 
offers little value for the scenario you describe.

A SoC should be modelled as a single object with parameters that can be 
set.  That object will then have other objects embedded through it with 
composition or reference.

So for instance, you might have:

class SH4 {
     SH4CPU cpu[n_vcpus];
     SM501 chipset;
};

class SM501 : public PCIHostController {
      PCIDevice *slots[32];
};

Having a script where you describe this is wrong.  This ought to be an 
object.  For instance, what we really ought to have on x86 is:

qemu -no-machine -device i440fx,id=root -device 
rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root

Part of the problem with qdev v1 is that it doesn't allow for meaningful 
object composition.  The only relationship between devices is through 
BusState which presents a hierarchical parent/child relationship.

We really need a way to do composition and referencing.  For instance, 
if you notice above, SM501 has 32 references to a PCIDevice as opposed 
to having a linked list of children.  The effect is that a PCIDevice 
does not have the PCIHostController as it's "parent" because there's no 
intrinsic parent/child hierarchy.

So really, we're talking about a device graph here instead of a tree.

Regards,

Anthony Liguori

> That basically only leaves the PCI and USB devices configurable, but
> those are already using qdev.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>    
>> Chris Wright<chrisw@redhat.com>  writes:
>>
>> [...]
>>      
>>> - qdev/vmstate both examples of partially completed work that need more
>>>    attention
>>>        
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>    qdev declarations.  Specific ideas welcome.  Patches even more, as
>>    always.
>>
>> * Convert the remaining devices.  They are typically used only with
>>    oddball machines, which makes the conversion hard to test for anyone
>>    who's not already using them.
>>
>>    I've said this before: at some point in time (sooner rather than
>>    later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>    optimistic that any victims worth keeping will receive timely
>>    attention then.
>>
>>      
> For those oddball machines, qdev doesn't really bring anything, that's
> why there is so little interest in converting them, and why I prefer to
> spend my time on the emulation correctness than converting those
> remaining to qdev. Of course I agree it's something to do, and with an
> unlimited amount of free time, I'll do them immediately.
>
> Let's take for example the SH4 target. It's nice to be able to create
> the whole machine from a script, except your kernel won't boot if the
> machine:
> - has a different cpu
> - doesn't a SM501 chipset
> - has not the correct memory size
> - doesn't have 2 serial port
>    

qdev needs a v2.  The object model is very difficult to work with and it 
offers little value for the scenario you describe.

A SoC should be modelled as a single object with parameters that can be 
set.  That object will then have other objects embedded through it with 
composition or reference.

So for instance, you might have:

class SH4 {
     SH4CPU cpu[n_vcpus];
     SM501 chipset;
};

class SM501 : public PCIHostController {
      PCIDevice *slots[32];
};

Having a script where you describe this is wrong.  This ought to be an 
object.  For instance, what we really ought to have on x86 is:

qemu -no-machine -device i440fx,id=root -device 
rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root

Part of the problem with qdev v1 is that it doesn't allow for meaningful 
object composition.  The only relationship between devices is through 
BusState which presents a hierarchical parent/child relationship.

We really need a way to do composition and referencing.  For instance, 
if you notice above, SM501 has 32 references to a PCIDevice as opposed 
to having a linked list of children.  The effect is that a PCIDevice 
does not have the PCIHostController as it's "parent" because there's no 
intrinsic parent/child hierarchy.

So really, we're talking about a device graph here instead of a tree.

Regards,

Anthony Liguori

> That basically only leaves the PCI and USB devices configurable, but
> those are already using qdev.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
>>
>> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>>
>>>
>>> Chris Wright<chrisw@redhat.com>  writes:
>>>
>>> [...]
>>>
>>>>
>>>> - qdev/vmstate both examples of partially completed work that need more
>>>>   attention
>>>>
>>>
>>> As far as qdev's concerned, I can see two kinds of to-dos:
>>>
>>> * Further develop qdev so that more of the machine init code can becomes
>>>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>>>   always.
>>>
>>> * Convert the remaining devices.  They are typically used only with
>>>   oddball machines, which makes the conversion hard to test for anyone
>>>   who's not already using them.
>>>
>>>   I've said this before: at some point in time (sooner rather than
>>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>>   optimistic that any victims worth keeping will receive timely
>>>   attention then.
>>>
>>>
>>
>> For those oddball machines, qdev doesn't really bring anything, that's
>> why there is so little interest in converting them, and why I prefer to
>> spend my time on the emulation correctness than converting those
>> remaining to qdev. Of course I agree it's something to do, and with an
>> unlimited amount of free time, I'll do them immediately.
>>
>> Let's take for example the SH4 target. It's nice to be able to create
>> the whole machine from a script, except your kernel won't boot if the
>> machine:
>> - has a different cpu
>> - doesn't a SM501 chipset
>> - has not the correct memory size
>> - doesn't have 2 serial port
>>
>
> qdev needs a v2.  The object model is very difficult to work with and it
> offers little value for the scenario you describe.
>
> A SoC should be modelled as a single object with parameters that can be set.
>  That object will then have other objects embedded through it with
> composition or reference.
>
> So for instance, you might have:
>
> class SH4 {
>    SH4CPU cpu[n_vcpus];
>    SM501 chipset;
> };
>
> class SM501 : public PCIHostController {
>     PCIDevice *slots[32];
> };
>
> Having a script where you describe this is wrong.  This ought to be an
> object.  For instance, what we really ought to have on x86 is:
>
> qemu -no-machine -device i440fx,id=root -device
> rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root
>
> Part of the problem with qdev v1 is that it doesn't allow for meaningful
> object composition.  The only relationship between devices is through
> BusState which presents a hierarchical parent/child relationship.

That is actually how hardware is usually designed, usually multiple
active masters or cyclic graphs would be too complex.

> We really need a way to do composition and referencing.  For instance, if
> you notice above, SM501 has 32 references to a PCIDevice as opposed to
> having a linked list of children.  The effect is that a PCIDevice does not
> have the PCIHostController as it's "parent" because there's no intrinsic
> parent/child hierarchy.
>
> So really, we're talking about a device graph here instead of a tree.

I think the problem is that there are several semi-overlapping trees
when you take into consideration also IRQ routing, power lines, wakeup
signals etc. and this is not so easy to describe.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
>>
>> On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
>>
>>>
>>> Chris Wright<chrisw@redhat.com>  writes:
>>>
>>> [...]
>>>
>>>>
>>>> - qdev/vmstate both examples of partially completed work that need more
>>>>   attention
>>>>
>>>
>>> As far as qdev's concerned, I can see two kinds of to-dos:
>>>
>>> * Further develop qdev so that more of the machine init code can becomes
>>>   qdev declarations.  Specific ideas welcome.  Patches even more, as
>>>   always.
>>>
>>> * Convert the remaining devices.  They are typically used only with
>>>   oddball machines, which makes the conversion hard to test for anyone
>>>   who's not already using them.
>>>
>>>   I've said this before: at some point in time (sooner rather than
>>>   later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>>   optimistic that any victims worth keeping will receive timely
>>>   attention then.
>>>
>>>
>>
>> For those oddball machines, qdev doesn't really bring anything, that's
>> why there is so little interest in converting them, and why I prefer to
>> spend my time on the emulation correctness than converting those
>> remaining to qdev. Of course I agree it's something to do, and with an
>> unlimited amount of free time, I'll do them immediately.
>>
>> Let's take for example the SH4 target. It's nice to be able to create
>> the whole machine from a script, except your kernel won't boot if the
>> machine:
>> - has a different cpu
>> - doesn't a SM501 chipset
>> - has not the correct memory size
>> - doesn't have 2 serial port
>>
>
> qdev needs a v2.  The object model is very difficult to work with and it
> offers little value for the scenario you describe.
>
> A SoC should be modelled as a single object with parameters that can be set.
>  That object will then have other objects embedded through it with
> composition or reference.
>
> So for instance, you might have:
>
> class SH4 {
>    SH4CPU cpu[n_vcpus];
>    SM501 chipset;
> };
>
> class SM501 : public PCIHostController {
>     PCIDevice *slots[32];
> };
>
> Having a script where you describe this is wrong.  This ought to be an
> object.  For instance, what we really ought to have on x86 is:
>
> qemu -no-machine -device i440fx,id=root -device
> rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root
>
> Part of the problem with qdev v1 is that it doesn't allow for meaningful
> object composition.  The only relationship between devices is through
> BusState which presents a hierarchical parent/child relationship.

That is actually how hardware is usually designed, usually multiple
active masters or cyclic graphs would be too complex.

> We really need a way to do composition and referencing.  For instance, if
> you notice above, SM501 has 32 references to a PCIDevice as opposed to
> having a linked list of children.  The effect is that a PCIDevice does not
> have the PCIHostController as it's "parent" because there's no intrinsic
> parent/child hierarchy.
>
> So really, we're talking about a device graph here instead of a tree.

I think the problem is that there are several semi-overlapping trees
when you take into consideration also IRQ routing, power lines, wakeup
signals etc. and this is not so easy to describe.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/08/2011 11:13 AM, Markus Armbruster wrote:
> Chris Wright<chrisw@redhat.com>  writes:
>
> [...]
>    
>> - qdev/vmstate both examples of partially completed work that need more
>>    attention
>>      
> As far as qdev's concerned, I can see two kinds of to-dos:
>
> * Further develop qdev so that more of the machine init code can becomes
>    qdev declarations.  Specific ideas welcome.  Patches even more, as
>    always.
>    

I think we need to improve the i440fx modelling as a lot of the stuff 
done in the machine init for pc really belongs as part of the i440fx.

In theory, creating an i440fx ought to be essentially equivalent to the 
machine init function today.

> * Convert the remaining devices.  They are typically used only with
>    oddball machines, which makes the conversion hard to test for anyone
>    who's not already using them.
>
>    I've said this before: at some point in time (sooner rather than
>    later, if you ask me), we need to shoot the stragglers.  I'm pretty
>    optimistic that any victims worth keeping will receive timely
>    attention then.
>
> Anything else?
>    

We need to unify the property model.  We have QemuOpts, qdev properties, 
and QObject which basically reinvents variant typing three different ways.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 02/08/2011 11:13 AM, Markus Armbruster wrote:
>> Chris Wright<chrisw@redhat.com>  writes:
>>
>> [...]
>>    
>>> - qdev/vmstate both examples of partially completed work that need more
>>>    attention
>>>      
>> As far as qdev's concerned, I can see two kinds of to-dos:
>>
>> * Further develop qdev so that more of the machine init code can becomes
>>    qdev declarations.  Specific ideas welcome.  Patches even more, as
>>    always.
>>    
>
> I think we need to improve the i440fx modelling as a lot of the stuff
> done in the machine init for pc really belongs as part of the i440fx.
>
> In theory, creating an i440fx ought to be essentially equivalent to
> the machine init function today.
>
>> * Convert the remaining devices.  They are typically used only with
>>    oddball machines, which makes the conversion hard to test for anyone
>>    who's not already using them.
>>
>>    I've said this before: at some point in time (sooner rather than
>>    later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>    optimistic that any victims worth keeping will receive timely
>>    attention then.
>>
>> Anything else?
>>    
>
> We need to unify the property model.  We have QemuOpts, qdev
> properties, and QObject which basically reinvents variant typing three
> different ways.

Make it four: QEMUOptionParameter.

Now let me make it three again.  Unlike the others, a qdev property
describes a perfectly ordinary, non-variant struct member.  It's poor
man's reflection, not a variant type.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/09/2011 02:01 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>
>    
>> On 02/08/2011 11:13 AM, Markus Armbruster wrote:
>>      
>>> Chris Wright<chrisw@redhat.com>   writes:
>>>
>>> [...]
>>>
>>>        
>>>> - qdev/vmstate both examples of partially completed work that need more
>>>>     attention
>>>>
>>>>          
>>> As far as qdev's concerned, I can see two kinds of to-dos:
>>>
>>> * Further develop qdev so that more of the machine init code can becomes
>>>     qdev declarations.  Specific ideas welcome.  Patches even more, as
>>>     always.
>>>
>>>        
>> I think we need to improve the i440fx modelling as a lot of the stuff
>> done in the machine init for pc really belongs as part of the i440fx.
>>
>> In theory, creating an i440fx ought to be essentially equivalent to
>> the machine init function today.
>>
>>      
>>> * Convert the remaining devices.  They are typically used only with
>>>     oddball machines, which makes the conversion hard to test for anyone
>>>     who's not already using them.
>>>
>>>     I've said this before: at some point in time (sooner rather than
>>>     later, if you ask me), we need to shoot the stragglers.  I'm pretty
>>>     optimistic that any victims worth keeping will receive timely
>>>     attention then.
>>>
>>> Anything else?
>>>
>>>        
>> We need to unify the property model.  We have QemuOpts, qdev
>> properties, and QObject which basically reinvents variant typing three
>> different ways.
>>      
> Make it four: QEMUOptionParameter.
>
> Now let me make it three again.  Unlike the others, a qdev property
> describes a perfectly ordinary, non-variant struct member.  It's poor
> man's reflection, not a variant type.
>    

Except that construction of a device requires initialization from an 
array of variants (which is then type checked).  The way we store the 
variants is lossy because we convert back and forth to a string.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 02/09/2011 02:01 AM, Markus Armbruster wrote:
>> Anthony Liguori<anthony@codemonkey.ws>  writes:
[...]
>>> We need to unify the property model.  We have QemuOpts, qdev
>>> properties, and QObject which basically reinvents variant typing three
>>> different ways.
>>>      
>> Make it four: QEMUOptionParameter.
>>
>> Now let me make it three again.  Unlike the others, a qdev property
>> describes a perfectly ordinary, non-variant struct member.  It's poor
>> man's reflection, not a variant type.
>>    
>
> Except that construction of a device requires initialization from an
> array of variants (which is then type checked).  The way we store the
> variants is lossy because we convert back and forth to a string.

Yes, there's overlap, but no, a qdev property isn't yet another variant
type scheme.  Exhibit A of the defense: qdev uses QemuOpts for variant
types.

Let me elaborate.  qdev_device_add() uses QemuOpts as map from name to
variant type value, uses the name to look up the property, then uses
property methods to stuff the variant value it got from QemuOpts into
the (non-variant) struct member described by the property.

I figure QemuOpts was adopted for this purpose because it was already in
use with command line and human monitor.  With QMP added to the mix,
there's friction: QMP uses QDict, not QemuOpts.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/09/2011 06:28 AM, Markus Armbruster wrote:
>> Except that construction of a device requires initialization from an
>> array of variants (which is then type checked).  The way we store the
>> variants is lossy because we convert back and forth to a string.
>>      
> Yes, there's overlap, but no, a qdev property isn't yet another variant
> type scheme.  Exhibit A of the defense: qdev uses QemuOpts for variant
> types.
>
> Let me elaborate.  qdev_device_add() uses QemuOpts as map from name to
> variant type value, uses the name to look up the property, then uses
> property methods to stuff the variant value it got from QemuOpts into
> the (non-variant) struct member described by the property.
>
> I figure QemuOpts was adopted for this purpose because it was already in
> use with command line and human monitor.  With QMP added to the mix,
> there's friction: QMP uses QDict, not QemuOpts.
>    

I'm going to finish QMP before tackling qdev, but at a high level, 
here's how I think we fix this.

Right now, qdev only really supports construction properties.  In 
GObject parlance, this would be properties with G_PARAM_CONSTRUCT_ONLY.

Instead of the current approach of having the construction properties 
automagically set as part of the object prior to initfn() being invoked, 
we should have an init function that takes the full set of construction 
only properties in the native type.

With a schema description of the device's constructor, we can generate 
code that invokes the native constructor based on a QemuOpts, or based 
on a QDict.

So instead of:

static int serial_isa_initfn(ISADevice *dev);

static ISADeviceInfo serial_isa_info = {
     .init       = serial_isa_initfn,
     .qdev.props = (Property[]) {
         DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
         DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
         DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
         DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
         DEFINE_PROP_END_OF_LIST(),
     },
};

We'd have:

void isa_serial_init(ISASerialState *obj, uint32_t index, uint32_t 
iobase, uint32_t irq, CharDriverState *chardev, Error **errp);

// isa_serial.json
[ 'ISASerialState', {'index': 'uint32_t', 'iobase': 'uint32_t', 'irq': 
'uint32_t', 'chardev': 'CharDriverState *'} ]

 From this definition, we can generate code that handles the -device 
argument doing conversion from string to the appropriate types while 
also doing QObject/GVariant conversion to support the qmp_device_add() 
interface.

Also, having a well typed constructor means that we can do safer 
composition because instead of doing:

DeviceState *dev;

dev = qdev_create(NULL, "isa-serial");
qdev_prop_set_uint32(dev, "iobase", 0x274);
qdev_prop_set_uint32(dev, "irq", 0x07);
qdev_init_nofail(dev);

We can just do:

ISASerialState dev;

isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);

I think one of the reasons qdev has not been thoroughly embraced in much 
of QEMU is that the interface is obnoxious to work with in C.  By 
addressing that, I think it'll be much more successful.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Wed, Feb 9, 2011 at 4:44 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/09/2011 06:28 AM, Markus Armbruster wrote:
>>>
>>> Except that construction of a device requires initialization from an
>>> array of variants (which is then type checked).  The way we store the
>>> variants is lossy because we convert back and forth to a string.
>>>
>>
>> Yes, there's overlap, but no, a qdev property isn't yet another variant
>> type scheme.  Exhibit A of the defense: qdev uses QemuOpts for variant
>> types.
>>
>> Let me elaborate.  qdev_device_add() uses QemuOpts as map from name to
>> variant type value, uses the name to look up the property, then uses
>> property methods to stuff the variant value it got from QemuOpts into
>> the (non-variant) struct member described by the property.
>>
>> I figure QemuOpts was adopted for this purpose because it was already in
>> use with command line and human monitor.  With QMP added to the mix,
>> there's friction: QMP uses QDict, not QemuOpts.
>>
>
> I'm going to finish QMP before tackling qdev, but at a high level, here's
> how I think we fix this.
>
> Right now, qdev only really supports construction properties.  In GObject
> parlance, this would be properties with G_PARAM_CONSTRUCT_ONLY.
>
> Instead of the current approach of having the construction properties
> automagically set as part of the object prior to initfn() being invoked, we
> should have an init function that takes the full set of construction only
> properties in the native type.
>
> With a schema description of the device's constructor, we can generate code
> that invokes the native constructor based on a QemuOpts, or based on a
> QDict.
>
> So instead of:
>
> static int serial_isa_initfn(ISADevice *dev);
>
> static ISADeviceInfo serial_isa_info = {
>    .init       = serial_isa_initfn,
>    .qdev.props = (Property[]) {
>        DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
>        DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
>        DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
>        DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
>        DEFINE_PROP_END_OF_LIST(),
>    },
> };
>
> We'd have:
>
> void isa_serial_init(ISASerialState *obj, uint32_t index, uint32_t iobase,
> uint32_t irq, CharDriverState *chardev, Error **errp);
>
> // isa_serial.json
> [ 'ISASerialState', {'index': 'uint32_t', 'iobase': 'uint32_t', 'irq':
> 'uint32_t', 'chardev': 'CharDriverState *'} ]
>
> From this definition, we can generate code that handles the -device argument
> doing conversion from string to the appropriate types while also doing
> QObject/GVariant conversion to support the qmp_device_add() interface.
>
> Also, having a well typed constructor means that we can do safer composition
> because instead of doing:
>
> DeviceState *dev;
>
> dev = qdev_create(NULL, "isa-serial");
> qdev_prop_set_uint32(dev, "iobase", 0x274);
> qdev_prop_set_uint32(dev, "irq", 0x07);
> qdev_init_nofail(dev);
>
> We can just do:
>
> ISASerialState dev;
>
> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);

Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?

I still think that FDT should be used in the future. That would
require that the properties can be set up mechanically, and I don't
see how your proposal would help that.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Wed, Feb 9, 2011 at 4:44 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/09/2011 06:28 AM, Markus Armbruster wrote:
>>>
>>> Except that construction of a device requires initialization from an
>>> array of variants (which is then type checked).  The way we store the
>>> variants is lossy because we convert back and forth to a string.
>>>
>>
>> Yes, there's overlap, but no, a qdev property isn't yet another variant
>> type scheme.  Exhibit A of the defense: qdev uses QemuOpts for variant
>> types.
>>
>> Let me elaborate.  qdev_device_add() uses QemuOpts as map from name to
>> variant type value, uses the name to look up the property, then uses
>> property methods to stuff the variant value it got from QemuOpts into
>> the (non-variant) struct member described by the property.
>>
>> I figure QemuOpts was adopted for this purpose because it was already in
>> use with command line and human monitor.  With QMP added to the mix,
>> there's friction: QMP uses QDict, not QemuOpts.
>>
>
> I'm going to finish QMP before tackling qdev, but at a high level, here's
> how I think we fix this.
>
> Right now, qdev only really supports construction properties.  In GObject
> parlance, this would be properties with G_PARAM_CONSTRUCT_ONLY.
>
> Instead of the current approach of having the construction properties
> automagically set as part of the object prior to initfn() being invoked, we
> should have an init function that takes the full set of construction only
> properties in the native type.
>
> With a schema description of the device's constructor, we can generate code
> that invokes the native constructor based on a QemuOpts, or based on a
> QDict.
>
> So instead of:
>
> static int serial_isa_initfn(ISADevice *dev);
>
> static ISADeviceInfo serial_isa_info = {
>    .init       = serial_isa_initfn,
>    .qdev.props = (Property[]) {
>        DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
>        DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
>        DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
>        DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
>        DEFINE_PROP_END_OF_LIST(),
>    },
> };
>
> We'd have:
>
> void isa_serial_init(ISASerialState *obj, uint32_t index, uint32_t iobase,
> uint32_t irq, CharDriverState *chardev, Error **errp);
>
> // isa_serial.json
> [ 'ISASerialState', {'index': 'uint32_t', 'iobase': 'uint32_t', 'irq':
> 'uint32_t', 'chardev': 'CharDriverState *'} ]
>
> From this definition, we can generate code that handles the -device argument
> doing conversion from string to the appropriate types while also doing
> QObject/GVariant conversion to support the qmp_device_add() interface.
>
> Also, having a well typed constructor means that we can do safer composition
> because instead of doing:
>
> DeviceState *dev;
>
> dev = qdev_create(NULL, "isa-serial");
> qdev_prop_set_uint32(dev, "iobase", 0x274);
> qdev_prop_set_uint32(dev, "irq", 0x07);
> qdev_init_nofail(dev);
>
> We can just do:
>
> ISASerialState dev;
>
> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);

Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?

I still think that FDT should be used in the future. That would
require that the properties can be set up mechanically, and I don't
see how your proposal would help that.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/09/2011 06:48 PM, Blue Swirl wrote:
>
>> We can just do:
>>
>> ISASerialState dev;
>>
>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>      
> Do you mean that there should be a generic way of doing that, like
> sysbus_create_varargs() for qdev, or just add inline functions which
> hide qdev property setup?
>    

qdev properties are construct-only right now.

What qdev is trying to do is provide a mechanism invoke constructors 
through a factory interface where the inputs can come from many places.

Another way of doing this is to just have a normal constructor like:

void isa_serial_init(ISASerialState *dev, uint32_t iobase, ...)
{
      dev->iobase = iobase;
}

And then have an (autogenerated) factory proxy:

static ISASerialState *isa_serial_factory(QemuOpts *opts)
{
      ISASerialState *isa = qemu_mallocz(sizeof(*isa));
      isa_serial_init(isa, qemu_opt_get_int(opts, "iobase"), ...);
      return isa;
}

The advantage of this model is that you can have multiple factory 
interfaces to create a device.  For instance, you can have a QemuOpts 
based factory for -device and a QDict based factory for QMP.

In addition, normal C code doesn't have to deal with any of the factory 
interfaces.  It can just invoke a normal C interface.

Building the factory interface as an intrinsic part of qdev was a 
mistake IMHO.

Regards,

Anthony Liguori

> I still think that FDT should be used in the future. That would
> require that the properties can be set up mechanically, and I don't
> see how your proposal would help that.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/09/2011 06:48 PM, Blue Swirl wrote:
>> ISASerialState dev;
>>
>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>      
> Do you mean that there should be a generic way of doing that, like
> sysbus_create_varargs() for qdev, or just add inline functions which
> hide qdev property setup?
>
> I still think that FDT should be used in the future. That would
> require that the properties can be set up mechanically, and I don't
> see how your proposal would help that.
>    

Yeah, I don't think that is a good idea anymore.  I think this is part 
of why we're having so many problems with qdev.

While (most?) hardware hierarchies can be represented by device tree 
syntax, not all valid device trees correspond to interface and/or useful 
hardware hierarchies.

We want to have an interface to create large chunks of hardware (like an 
i440fx) which then results in a significant portion of a device tree.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/09/2011 06:48 PM, Blue Swirl wrote:
>>>
>>> ISASerialState dev;
>>>
>>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>>
>>
>> Do you mean that there should be a generic way of doing that, like
>> sysbus_create_varargs() for qdev, or just add inline functions which
>> hide qdev property setup?
>>
>> I still think that FDT should be used in the future. That would
>> require that the properties can be set up mechanically, and I don't
>> see how your proposal would help that.
>>
>
> Yeah, I don't think that is a good idea anymore.  I think this is part of
> why we're having so many problems with qdev.
>
> While (most?) hardware hierarchies can be represented by device tree syntax,
> not all valid device trees correspond to interface and/or useful hardware
> hierarchies.

User creates a non-working machine and so gets to fix the problems?
How is that a problem for us?

> We want to have an interface to create large chunks of hardware (like an
> i440fx) which then results in a significant portion of a device tree.

But how would this affect interface to devices? I don't see how that
would be any different with current model and the function call model.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/09/2011 09:15 PM, Blue Swirl wrote:
> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/09/2011 06:48 PM, Blue Swirl wrote:
>>      
>>>> ISASerialState dev;
>>>>
>>>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>>>
>>>>          
>>> Do you mean that there should be a generic way of doing that, like
>>> sysbus_create_varargs() for qdev, or just add inline functions which
>>> hide qdev property setup?
>>>
>>> I still think that FDT should be used in the future. That would
>>> require that the properties can be set up mechanically, and I don't
>>> see how your proposal would help that.
>>>
>>>        
>> Yeah, I don't think that is a good idea anymore.  I think this is part of
>> why we're having so many problems with qdev.
>>
>> While (most?) hardware hierarchies can be represented by device tree syntax,
>> not all valid device trees correspond to interface and/or useful hardware
>> hierarchies.
>>      
> User creates a non-working machine and so gets to fix the problems?
> How is that a problem for us?
>    

It's not about creating a non-working machine.  It's about what 
user-level abstraction we need to provide.

It's a whole lot easier to implement an i440fx device with a fixed set 
of parameters than it is to make every possible subdevice have a proper 
factory interface along with mechanisms to hook everything together.

Basically, we're making things much harder for ourselves than we should.

>> We want to have an interface to create large chunks of hardware (like an
>> i440fx) which then results in a significant portion of a device tree.
>>      
> But how would this affect interface to devices? I don't see how that
> would be any different with current model and the function call model.
>    

If all composition is done through a factory interface, it doesn't.  But 
my main argument here is that we shouldn't try to make all composition 
done through a factory interface--only where it makes sense.

So very concretely, I'm suggesting we do the following to target-i386:

1) make the i440fx device have an embedded ide controller, piix3, and 
usb controller that get initialized automatically.  The piix3 embeds the 
PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
serial, etc.).

2) get rid of the entire concept of machines.  Creating a i440fx is 
essentially equivalent to creating a bare machine.

3) just use the existing -device infrastructure to support all of this.  
A very simple device config corresponds to a very complex device tree 
but that's the desired effect.

4) model the CPUs as devices that take a pointer to a host controller, 
for x86, the normal case would be giving it a pointer to i440fx.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
> So very concretely, I'm suggesting we do the following to target-i386:

> 2) get rid of the entire concept of machines.  Creating a i440fx is
> essentially equivalent to creating a bare machine.

Does that make any sense for anything other than target-i386?
The concept of a machine model seems a pretty obvious one
for ARM boards, for instance, and I'm not sure we'd gain much
by having i386 be different to the other architectures...

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 09:16 AM, Peter Maydell wrote:
> On 10 February 2011 07:47, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> So very concretely, I'm suggesting we do the following to target-i386:
>>      
>    
>> 2) get rid of the entire concept of machines.  Creating a i440fx is
>> essentially equivalent to creating a bare machine.
>>      
> Does that make any sense for anything other than target-i386?
> The concept of a machine model seems a pretty obvious one
> for ARM boards, for instance, and I'm not sure we'd gain much
> by having i386 be different to the other architectures...
>    

Yes, it makes a lot of sense, I just don't know the component names as 
well so bear with me :-)

There are two types of Versatile machines today, Versatile/AB and 
Versatile/PB.  They are both made with the same core, ARM926EJ-S, with 
different expansions.

So you would model arm926ej-s as the chipset and then build up the 
machines by modifying parameters of the chipset (like the board id) 
and/or adding different components on top of it.

A good way to think about what I'm proposing is that machine->init 
really should be a constructor for a device object.

Regards,

Anthony Liguori

> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 08:36, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/10/2011 09:16 AM, Peter Maydell wrote:
>> On 10 February 2011 07:47, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>> 2) get rid of the entire concept of machines.  Creating a i440fx is
>>> essentially equivalent to creating a bare machine.
>>
>> Does that make any sense for anything other than target-i386?
>> The concept of a machine model seems a pretty obvious one
>> for ARM boards, for instance, and I'm not sure we'd gain much
>> by having i386 be different to the other architectures...
>
> Yes, it makes a lot of sense, I just don't know the component names as well
> so bear with me :-)
>
> There are two types of Versatile machines today, Versatile/AB and
> Versatile/PB.  They are both made with the same core, ARM926EJ-S, with
> different expansions.
>
> So you would model arm926ej-s as the chipset and then build up the machines
> by modifying parameters of the chipset (like the board id) and/or adding
> different components on top of it.

Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely
not a property of an ARM926, it's a property of the board (clue is in
the name :-)). I don't think versatile boards have a "chipset" really...

In my understanding the "machine" is the thing that says "I need a
926, and an MMC controller at this address, and some UARTS,
and..." ie it is the thing that does the "modifying parameters"
and "adding different components". So if we'd still be doing that
I don't see how we've "got rid of the concept". I guess I'm missing
the point somehow.

> A good way to think about what I'm proposing is that machine->init really
> should be a constructor for a device object.

If you mean that you want machines to be implemented under the
hood as a single huge "device" you can only have one of that spans
the entire memory map, well I guess that's an implementation
detail. But conceptually machines really do exist, and we definitely
still want users to be able to say "I want a beagle machine; I want
a versatile; I want an n900".

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 10:04 AM, Peter Maydell wrote:
> On 10 February 2011 08:36, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/10/2011 09:16 AM, Peter Maydell wrote:
>>      
>>> On 10 February 2011 07:47, Anthony Liguori<anthony@codemonkey.ws>    wrote:
>>>        
>>>> 2) get rid of the entire concept of machines.  Creating a i440fx is
>>>> essentially equivalent to creating a bare machine.
>>>>          
>>> Does that make any sense for anything other than target-i386?
>>> The concept of a machine model seems a pretty obvious one
>>> for ARM boards, for instance, and I'm not sure we'd gain much
>>> by having i386 be different to the other architectures...
>>>        
>> Yes, it makes a lot of sense, I just don't know the component names as well
>> so bear with me :-)
>>
>> There are two types of Versatile machines today, Versatile/AB and
>> Versatile/PB.  They are both made with the same core, ARM926EJ-S, with
>> different expansions.
>>
>> So you would model arm926ej-s as the chipset and then build up the machines
>> by modifying parameters of the chipset (like the board id) and/or adding
>> different components on top of it.
>>      
> Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely
> not a property of an ARM926, it's a property of the board (clue is in
> the name :-)). I don't think versatile boards have a "chipset" really...
>    

As I said, I'm not well versed in the component names in ARM.

But that said, an actual processor doesn't connect directly to a bunch 
of devices.  It almost always go through some chipset and that chipset 
implements a lot of functionality typically.

I think the name of the component I'm trying to refer to PL300 which I 
believe is the Northbridge used for the Versatile boards.

> In my understanding the "machine" is the thing that says "I need a
> 926, and an MMC controller at this address, and some UARTS,
> and..." ie it is the thing that does the "modifying parameters"
> and "adding different components". So if we'd still be doing that
> I don't see how we've "got rid of the concept". I guess I'm missing
> the point somehow.
>    

A machine today is basically the northbridge, southbridge, plus a bunch 
of default components to make the virtual hardware useful.

I'm suggesting that we model a proper northbridge/southbridge.

>> A good way to think about what I'm proposing is that machine->init really
>> should be a constructor for a device object.
>>      
> If you mean that you want machines to be implemented under the
> hood as a single huge "device" you can only have one of that spans
> the entire memory map, well I guess that's an implementation
> detail. But conceptually machines really do exist, and we definitely
> still want users to be able to say "I want a beagle machine; I want
> a versatile; I want an n900".
>    

An n900 is a very specific hardware configuration that is best 
represented by some sort of configuration file vs. something hard coded 
in QEMU.

The question is, what level of component modelling do we need to do in 
order to make it practical to create such configurations from a file.

Regards,

Anthony Liguori

> -- PMM
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 10:13, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>
>> On 10 February 2011 08:36, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>> So you would model arm926ej-s as the chipset and then build up the
>>> machines
>>> by modifying parameters of the chipset (like the board id) and/or adding
>>> different components on top of it.
>>>
>>
>> Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely
>> not a property of an ARM926, it's a property of the board (clue is in
>> the name :-)). I don't think versatile boards have a "chipset" really...
>>
>
> As I said, I'm not well versed in the component names in ARM.
>
> But that said, an actual processor doesn't connect directly to a bunch of
> devices.  It almost always go through some chipset and that chipset
> implements a lot of functionality typically.
>
> I think the name of the component I'm trying to refer to PL300 which I
> believe is the Northbridge used for the Versatile boards.

PL300 is just a bus interconnect (so you can connect multiple AXI
bus masters (cores) to multiple AXI bus slaves (devices)).
Versatile PB doesn't have anything in the documentation that claims
to be a Northbridge (PBX does, VExpress doesn't).

This is the system diagram for the Versatile Express:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
I don't know what you'd want to claim is a "northbridge" there.
Basically there's an FPGA with a pile of devices in it,
and there's a test chip with the core and some other devices in
it. But from a modelling perspective this is all completely
irrelevant because regardless of where the hardware designer
put the devices, they're just devices at a particular point in the
memory map and with a particular set of interrupt wiring and so
on. I don't see the point in modelling a concept that has no
user-visible effects and doesn't actually make the model any
clearer or simpler.

>> In my understanding the "machine" is the thing that says "I need a
>> 926, and an MMC controller at this address, and some UARTS,
>> and..." ie it is the thing that does the "modifying parameters"
>> and "adding different components". So if we'd still be doing that
>> I don't see how we've "got rid of the concept". I guess I'm missing
>> the point somehow.

> A machine today is basically the northbridge, southbridge, plus a bunch of
> default components to make the virtual hardware useful.

This doesn't really correspond to ARM boards I've looked at,
by and large (for instance there's no mention of the word "northbridge"
in the whole 3700 page OMAP3 TRM). PCs may be best modelled
that way, sure, but I don't think you can cram everything into that mould.

>> If you mean that you want machines to be implemented under the
>> hood as a single huge "device" you can only have one of that spans
>> the entire memory map, well I guess that's an implementation
>> detail. But conceptually machines really do exist, and we definitely
>> still want users to be able to say "I want a beagle machine; I want
>> a versatile; I want an n900".

> An n900 is a very specific hardware configuration that is best represented
> by some sort of configuration file vs. something hard coded in QEMU.

Yes, that's the whole point -- "machine" == "specific hardware
configuration".

That's not getting rid of "machine", it's just saying "we should have
some custom scripting language to define them rather than doing
them in C". You still want, fundamentally, to be able to say
  qemu-system-arm -M machinename

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 10:38:53AM +0000, Peter Maydell wrote:
> This is the system diagram for the Versatile Express:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
> I don't know what you'd want to claim is a "northbridge" there.
> Basically there's an FPGA with a pile of devices in it,
> and there's a test chip with the core and some other devices in
> it. But from a modelling perspective this is all completely
> irrelevant because regardless of where the hardware designer
> put the devices, they're just devices at a particular point in the
> memory map and with a particular set of interrupt wiring and so
> on. I don't see the point in modelling a concept that has no
> user-visible effects and doesn't actually make the model any
> clearer or simpler.
> 
Exactly. This is really the same with x86. The fact that some company
put several devices on the same chip and gave it commercial name
shouldn't govern our design.

> 
> > A machine today is basically the northbridge, southbridge, plus a bunch of
> > default components to make the virtual hardware useful.
> 
> This doesn't really correspond to ARM boards I've looked at,
> by and large (for instance there's no mention of the word "northbridge"
> in the whole 3700 page OMAP3 TRM). PCs may be best modelled
> that way, sure, but I don't think you can cram everything into that mould.
> 
Even on x86 this model is falling apart. Memory controller moves to cpu.
PCI controller will follow.

> >> If you mean that you want machines to be implemented under the
> >> hood as a single huge "device" you can only have one of that spans
> >> the entire memory map, well I guess that's an implementation
> >> detail. But conceptually machines really do exist, and we definitely
> >> still want users to be able to say "I want a beagle machine; I want
> >> a versatile; I want an n900".
> 
> > An n900 is a very specific hardware configuration that is best represented
> > by some sort of configuration file vs. something hard coded in QEMU.
> 
> Yes, that's the whole point -- "machine" == "specific hardware
> configuration".
> 
> That's not getting rid of "machine", it's just saying "we should have
> some custom scripting language to define them rather than doing
> them in C". You still want, fundamentally, to be able to say
>   qemu-system-arm -M machinename
> 
+1

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 10:38:53AM +0000, Peter Maydell wrote:
> This is the system diagram for the Versatile Express:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
> I don't know what you'd want to claim is a "northbridge" there.
> Basically there's an FPGA with a pile of devices in it,
> and there's a test chip with the core and some other devices in
> it. But from a modelling perspective this is all completely
> irrelevant because regardless of where the hardware designer
> put the devices, they're just devices at a particular point in the
> memory map and with a particular set of interrupt wiring and so
> on. I don't see the point in modelling a concept that has no
> user-visible effects and doesn't actually make the model any
> clearer or simpler.
> 
Exactly. This is really the same with x86. The fact that some company
put several devices on the same chip and gave it commercial name
shouldn't govern our design.

> 
> > A machine today is basically the northbridge, southbridge, plus a bunch of
> > default components to make the virtual hardware useful.
> 
> This doesn't really correspond to ARM boards I've looked at,
> by and large (for instance there's no mention of the word "northbridge"
> in the whole 3700 page OMAP3 TRM). PCs may be best modelled
> that way, sure, but I don't think you can cram everything into that mould.
> 
Even on x86 this model is falling apart. Memory controller moves to cpu.
PCI controller will follow.

> >> If you mean that you want machines to be implemented under the
> >> hood as a single huge "device" you can only have one of that spans
> >> the entire memory map, well I guess that's an implementation
> >> detail. But conceptually machines really do exist, and we definitely
> >> still want users to be able to say "I want a beagle machine; I want
> >> a versatile; I want an n900".
> 
> > An n900 is a very specific hardware configuration that is best represented
> > by some sort of configuration file vs. something hard coded in QEMU.
> 
> Yes, that's the whole point -- "machine" == "specific hardware
> configuration".
> 
> That's not getting rid of "machine", it's just saying "we should have
> some custom scripting language to define them rather than doing
> them in C". You still want, fundamentally, to be able to say
>   qemu-system-arm -M machinename
> 
+1

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 11:38 AM, Peter Maydell wrote:
> On 10 February 2011 10:13, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/10/2011 10:04 AM, Peter Maydell wrote:
>>      
>>> On 10 February 2011 08:36, Anthony Liguori<anthony@codemonkey.ws>    wrote:
>>>        
>>>> So you would model arm926ej-s as the chipset and then build up the
>>>> machines
>>>> by modifying parameters of the chipset (like the board id) and/or adding
>>>> different components on top of it.
>>>>
>>>>          
>>> Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely
>>> not a property of an ARM926, it's a property of the board (clue is in
>>> the name :-)). I don't think versatile boards have a "chipset" really...
>>>
>>>        
>> As I said, I'm not well versed in the component names in ARM.
>>
>> But that said, an actual processor doesn't connect directly to a bunch of
>> devices.  It almost always go through some chipset and that chipset
>> implements a lot of functionality typically.
>>
>> I think the name of the component I'm trying to refer to PL300 which I
>> believe is the Northbridge used for the Versatile boards.
>>      
> PL300 is just a bus interconnect (so you can connect multiple AXI
> bus masters (cores) to multiple AXI bus slaves (devices)).
> Versatile PB doesn't have anything in the documentation that claims
> to be a Northbridge (PBX does, VExpress doesn't).
>
> This is the system diagram for the Versatile Express:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html
> I don't know what you'd want to claim is a "northbridge" there.
> Basically there's an FPGA with a pile of devices in it,
> and there's a test chip with the core and some other devices in
> it. But from a modelling perspective this is all completely
> irrelevant because regardless of where the hardware designer
> put the devices, they're just devices at a particular point in the
> memory map and with a particular set of interrupt wiring and so
> on.

But something interacts with each processor and dispatches the I/O 
operations in the address space, no?  I can't believe there are 2^32 
address lines coming off of every arm chip that each device connects.

This relationship of how I/O fans out through various devices is 
important because occasionally platforms do weird things during I/O fan 
out like implement an IOMMU.  If we don't model this I/O dispatch model 
within QEMU, then it's extremely difficult to implement things like IOMMUs.

It might be the case that a platform has a chipset that is a pile of 
well isolated devices that are crammed in the same silicon space but 
that otherwise have very well defined interactions with each other.  
This is the exception though, not the rule.

Particularly when looking at the relationship between certain devices on 
the PC (like the role the pckbd plays in address translation), things 
are simply not so idealized in practice.

But if it makes sense for ARM to describe every single platform device 
through a factory interface, that's fine.

Even in this case, you still want to model things like the distinction 
between the UART16650A and the ISA bus bridge for the serial device.  In 
this case, you want to be able to do composition without going through a 
factory.

>> An n900 is a very specific hardware configuration that is best represented
>> by some sort of configuration file vs. something hard coded in QEMU.
>>      
> Yes, that's the whole point -- "machine" == "specific hardware
> configuration".
>
> That's not getting rid of "machine", it's just saying "we should have
> some custom scripting language to define them rather than doing
> them in C". You still want, fundamentally, to be able to say
>    qemu-system-arm -M machinename
>    

No, qemu-system-arm -M /path/to/n900.cfg

But yeah, no disagreement there.  But today, the machine concept in QEMU 
is definitely not a specific hardware configuration.

Regards,

Anthony Liguori

> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 12:23, Anthony Liguori <anthony@codemonkey.ws> wrote:
> But something interacts with each processor and dispatches the I/O
> operations in the address space, no?  I can't believe there are 2^32 address
> lines coming off of every arm chip that each device connects.

Well, the AXI bus is kind of complicated and definitely not my
area of expertise, but as I understand it you have an interconnect
like a PL300 that effectively implements the "memory map" and
defines where the slaves (devices) appear. But unless you actually
want to be modelling bus transactions at a pretty low level this
isn't really a visible difference from "these devices appear at
this address in the memory map on this bus". (And there might
be a bridge down from AXI to AHB or APB between the core
and any particular device, but that's not programmer visible either.)

> This relationship of how I/O fans out through various devices is important
> because occasionally platforms do weird things during I/O fan out like
> implement an IOMMU.  If we don't model this I/O dispatch model within QEMU,
> then it's extremely difficult to implement things like IOMMUs.

Yes, but what does this have to do with chipsets and getting rid
of machines? Getting I/O fanout through devices is a matter of
modelling some sort of conceptual bus, and having the right APIs
so you can do it fast in the common case and still allow IOMMUs
and other interesting devices to intercept and change transactions.
Any particular board might have to wire up the bus so it goes through
an IOMMU, or it might not.

Whether you want to bundle up a collection of devices and bus wiring
and call it a "chipset" or not should be a matter of whether that makes
sense and is a usefully reusable conceptual unit for whatever board
you're modelling, I think. (For instance "an OMAP3" is an obvious
reusable unit which any OMAP3-based board model is going to want
to use.)

Some of the I/O fanout and bus wiring might be internal to
a qemu core model, for that matter -- for instance M profile
ARM cores have several output buses which deal with
different bits of the memory space (which are predefined
as being for devices, or memory, or whatever), and the
A9MP's internal timers and interrupt controller and so on ought
to all be inside the core (at the moment we rely on all A9MP
boards instantiating them as a separate device, which is ugly).

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Scott Wood]

On Thu, 10 Feb 2011 08:16:15 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > So very concretely, I'm suggesting we do the following to target-i386:
> 
> > 2) get rid of the entire concept of machines.  Creating a i440fx is
> > essentially equivalent to creating a bare machine.
> 
> Does that make any sense for anything other than target-i386?
> The concept of a machine model seems a pretty obvious one
> for ARM boards, for instance, and I'm not sure we'd gain much
> by having i386 be different to the other architectures...

It makes a lot of sense for us on powerpc.  Maybe it has to do with a
longer tradition of using device trees versus opaque machine IDs -- I don't
think the hardware itself makes any substantial difference.  Currently we
end up having everything pretend to be an mpc8544ds (with some differences
described by the guest device tree that the user feeds in), which is ugly.

-Scott

Re: [Qemu-devel] KVM call minutes for Feb 8

[Scott Wood]

On Thu, 10 Feb 2011 08:16:15 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > So very concretely, I'm suggesting we do the following to target-i386:
> 
> > 2) get rid of the entire concept of machines.  Creating a i440fx is
> > essentially equivalent to creating a bare machine.
> 
> Does that make any sense for anything other than target-i386?
> The concept of a machine model seems a pretty obvious one
> for ARM boards, for instance, and I'm not sure we'd gain much
> by having i386 be different to the other architectures...

It makes a lot of sense for us on powerpc.  Maybe it has to do with a
longer tradition of using device trees versus opaque machine IDs -- I don't
think the hardware itself makes any substantial difference.  Currently we
end up having everything pretend to be an mpc8544ds (with some differences
described by the guest device tree that the user feeds in), which is ugly.

-Scott

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 19:17, Scott Wood <scottwood@freescale.com> wrote:
> On Thu, 10 Feb 2011 08:16:15 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> > So very concretely, I'm suggesting we do the following to target-i386:
>>
>> > 2) get rid of the entire concept of machines.  Creating a i440fx is
>> > essentially equivalent to creating a bare machine.
>>
>> Does that make any sense for anything other than target-i386?

> It makes a lot of sense for us on powerpc.  Maybe it has to do with a
> longer tradition of using device trees versus opaque machine IDs -- I don't
> think the hardware itself makes any substantial difference.  Currently we
> end up having everything pretend to be an mpc8544ds (with some differences
> described by the guest device tree that the user feeds in), which is ugly.

Hmm. Device tree is coming to ARM, but just at the moment it's
generally one-kernel-one-machine still. (We've only just gained the
ability to compile one kernel for both UP and SMP...)

I kind of think you're still defining a "machine", you're just doing it
in your device tree blob rather than in C.

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 10 February 2011 19:17, Scott Wood <scottwood@freescale.com> wrote:
> On Thu, 10 Feb 2011 08:16:15 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> > So very concretely, I'm suggesting we do the following to target-i386:
>>
>> > 2) get rid of the entire concept of machines.  Creating a i440fx is
>> > essentially equivalent to creating a bare machine.
>>
>> Does that make any sense for anything other than target-i386?

> It makes a lot of sense for us on powerpc.  Maybe it has to do with a
> longer tradition of using device trees versus opaque machine IDs -- I don't
> think the hardware itself makes any substantial difference.  Currently we
> end up having everything pretend to be an mpc8544ds (with some differences
> described by the guest device tree that the user feeds in), which is ugly.

Hmm. Device tree is coming to ARM, but just at the moment it's
generally one-kernel-one-machine still. (We've only just gained the
ability to compile one kernel for both UP and SMP...)

I kind of think you're still defining a "machine", you're just doing it
in your device tree blob rather than in C.

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Scott Wood]

On Thu, 10 Feb 2011 19:22:38 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 10 February 2011 19:17, Scott Wood <scottwood@freescale.com> wrote:
> > On Thu, 10 Feb 2011 08:16:15 +0000
> > Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >> > So very concretely, I'm suggesting we do the following to target-i386:
> >>
> >> > 2) get rid of the entire concept of machines.  Creating a i440fx is
> >> > essentially equivalent to creating a bare machine.
> >>
> >> Does that make any sense for anything other than target-i386?
> 
> > It makes a lot of sense for us on powerpc.  Maybe it has to do with a
> > longer tradition of using device trees versus opaque machine IDs -- I don't
> > think the hardware itself makes any substantial difference.  Currently we
> > end up having everything pretend to be an mpc8544ds (with some differences
> > described by the guest device tree that the user feeds in), which is ugly.
> 
> Hmm. Device tree is coming to ARM, but just at the moment it's
> generally one-kernel-one-machine still. (We've only just gained the
> ability to compile one kernel for both UP and SMP...)
> 
> I kind of think you're still defining a "machine", you're just doing it
> in your device tree blob rather than in C.

Right, that's the point -- the definition is just a definition, it's not
tied up with implementation.  This reduces the amount of duplication in
implementation (or inappropriate sharing, as in the "use mpc8544ds for
all 85xx" case).

-Scott

Re: [Qemu-devel] KVM call minutes for Feb 8

[Scott Wood]

On Thu, 10 Feb 2011 19:22:38 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 10 February 2011 19:17, Scott Wood <scottwood@freescale.com> wrote:
> > On Thu, 10 Feb 2011 08:16:15 +0000
> > Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On 10 February 2011 07:47, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >> > So very concretely, I'm suggesting we do the following to target-i386:
> >>
> >> > 2) get rid of the entire concept of machines.  Creating a i440fx is
> >> > essentially equivalent to creating a bare machine.
> >>
> >> Does that make any sense for anything other than target-i386?
> 
> > It makes a lot of sense for us on powerpc.  Maybe it has to do with a
> > longer tradition of using device trees versus opaque machine IDs -- I don't
> > think the hardware itself makes any substantial difference.  Currently we
> > end up having everything pretend to be an mpc8544ds (with some differences
> > described by the guest device tree that the user feeds in), which is ugly.
> 
> Hmm. Device tree is coming to ARM, but just at the moment it's
> generally one-kernel-one-machine still. (We've only just gained the
> ability to compile one kernel for both UP and SMP...)
> 
> I kind of think you're still defining a "machine", you're just doing it
> in your device tree blob rather than in C.

Right, that's the point -- the definition is just a definition, it's not
tied up with implementation.  This reduces the amount of duplication in
implementation (or inappropriate sharing, as in the "use mpc8544ds for
all 85xx" case).

-Scott

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >>>>ISASerialState dev;
> >>>>
> >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >>>>
> >>>Do you mean that there should be a generic way of doing that, like
> >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >>>hide qdev property setup?
> >>>
> >>>I still think that FDT should be used in the future. That would
> >>>require that the properties can be set up mechanically, and I don't
> >>>see how your proposal would help that.
> >>>
> >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >>why we're having so many problems with qdev.
> >>
> >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >>not all valid device trees correspond to interface and/or useful hardware
> >>hierarchies.
> >User creates a non-working machine and so gets to fix the problems?
> >How is that a problem for us?
> 
> It's not about creating a non-working machine.  It's about what
> user-level abstraction we need to provide.
> 
> It's a whole lot easier to implement an i440fx device with a fixed
> set of parameters than it is to make every possible subdevice have a
> proper factory interface along with mechanisms to hook everything
> together.
> 
So what if it is easier, it doesn't mean it is correct thing to do. What
you are proposing is just a huge step backwards. May be we shouldn't
support hooking everything together in completely arbitrary ways, but we
shouldn't force isa/pci devices upon our users just because they are
non-removable on real chip.

> Basically, we're making things much harder for ourselves than we should.
> 
> >>We want to have an interface to create large chunks of hardware (like an
> >>i440fx) which then results in a significant portion of a device tree.
> >But how would this affect interface to devices? I don't see how that
> >would be any different with current model and the function call model.
> 
> If all composition is done through a factory interface, it doesn't.
> But my main argument here is that we shouldn't try to make all
> composition done through a factory interface--only where it makes
> sense.
> 
> So very concretely, I'm suggesting we do the following to target-i386:
> 
> 1) make the i440fx device have an embedded ide controller, piix3,
> and usb controller that get initialized automatically.  The piix3
> embeds the PCI-to-ISA bridge along with all of the default ISA
> devices (rtc, serial, etc.).
This may be a problem even from security point of view. What if usb code
(ide, serial, parallel) has guest exploitable bug? Currently I can happily
continue running guests if they do not need affected subsystem. If we'll
get it your way I will no longer be able to do so.

> 
> 2) get rid of the entire concept of machines.  Creating a i440fx is
> essentially equivalent to creating a bare machine.
> 
> 3) just use the existing -device infrastructure to support all of
> this.  A very simple device config corresponds to a very complex
> device tree but that's the desired effect.
> 
> 4) model the CPUs as devices that take a pointer to a host
> controller, for x86, the normal case would be giving it a pointer to
> i440fx.
> 
> Regards,
> 
> Anthony Liguori
> 
> --
> 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

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> So what if it is easier, it doesn't mean it is correct thing to do.

If we spend the next 10 years trying to do the "correct thing" for some 
arbitrary definition of correct, that's not terribly useful.

It's really simple actually.  Let's do the least clever thing and model 
how hardware actual works.  Once we have that, we can try to be better 
than real hardware (if it's possible).

>
>> If all composition is done through a factory interface, it doesn't.
>> But my main argument here is that we shouldn't try to make all
>> composition done through a factory interface--only where it makes
>> sense.
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3,
>> and usb controller that get initialized automatically.  The piix3
>> embeds the PCI-to-ISA bridge along with all of the default ISA
>> devices (rtc, serial, etc.).
>>      
> This may be a problem even from security point of view. What if usb code
> (ide, serial, parallel) has guest exploitable bug? Currently I can happily
> continue running guests if they do not need affected subsystem. If we'll
> get it your way I will no longer be able to do so.
>    

qemu -device i440fx,ide=off

If you really care to do this.  But this desire to remove devices is 
silly IMHO.  Concerns about security are misplaced.  If you have to 
change the way a guest is invoked in order to eliminate security 
problems, then there's something seriously wrong.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
> On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> >So what if it is easier, it doesn't mean it is correct thing to do.
> 
> If we spend the next 10 years trying to do the "correct thing" for
> some arbitrary definition of correct, that's not terribly useful.
Changing direction by 180 every 2 years even less useful.

> 
> It's really simple actually.  Let's do the least clever thing and
> model how hardware actual works.  Once we have that, we can try to
> be better than real hardware (if it's possible).
I think out understanding on how HW actually works is very different.
You are placing to much value on were device resides physically, for me
it is completely unimportant detail. Not worth even mentioning.

> 
> >
> >>If all composition is done through a factory interface, it doesn't.
> >>But my main argument here is that we shouldn't try to make all
> >>composition done through a factory interface--only where it makes
> >>sense.
> >>
> >>So very concretely, I'm suggesting we do the following to target-i386:
> >>
> >>1) make the i440fx device have an embedded ide controller, piix3,
> >>and usb controller that get initialized automatically.  The piix3
> >>embeds the PCI-to-ISA bridge along with all of the default ISA
> >>devices (rtc, serial, etc.).
> >This may be a problem even from security point of view. What if usb code
> >(ide, serial, parallel) has guest exploitable bug? Currently I can happily
> >continue running guests if they do not need affected subsystem. If we'll
> >get it your way I will no longer be able to do so.
> 
> qemu -device i440fx,ide=off
> 
So you still need to support arbitrary composition. What's the
difference? So why do you like -device i440fx over what we have now?
In current speak you propose will be implement by using i440fx machine
type. Qdev will build it for you.

> If you really care to do this.  But this desire to remove devices is
> silly IMHO.  Concerns about security are misplaced.  If you have to
> change the way a guest is invoked in order to eliminate security
> problems, then there's something seriously wrong.
> 
No I do not.  I do not create guest with unneeded devices from the
beginning.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 11:10 AM, Gleb Natapov wrote:
> On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
>    
>> On 02/10/2011 10:07 AM, Gleb Natapov wrote:
>>      
>>> So what if it is easier, it doesn't mean it is correct thing to do.
>>>        
>> If we spend the next 10 years trying to do the "correct thing" for
>> some arbitrary definition of correct, that's not terribly useful.
>>      
> Changing direction by 180 every 2 years even less useful.
>    

If we think through what we are doing and have a coherent architecture 
before changing direction, then we won't have this problem.

>> It's really simple actually.  Let's do the least clever thing and
>> model how hardware actual works.  Once we have that, we can try to
>> be better than real hardware (if it's possible).
>>      
> I think out understanding on how HW actually works is very different.
> You are placing to much value on were device resides physically, for me
> it is completely unimportant detail. Not worth even mentioning.
>    

No, I place value on how things are modelled in the real world.

There simply aren't PC's out there that lack an RTC so I have no 
interest in jumping through hoops in QEMU to make it possible to do this 
without modifying QEMU code.  It might sound nice to a developer but 
it's of absolutely no use to users.

>>>> If all composition is done through a factory interface, it doesn't.
>>>> But my main argument here is that we shouldn't try to make all
>>>> composition done through a factory interface--only where it makes
>>>> sense.
>>>>
>>>> So very concretely, I'm suggesting we do the following to target-i386:
>>>>
>>>> 1) make the i440fx device have an embedded ide controller, piix3,
>>>> and usb controller that get initialized automatically.  The piix3
>>>> embeds the PCI-to-ISA bridge along with all of the default ISA
>>>> devices (rtc, serial, etc.).
>>>>          
>>> This may be a problem even from security point of view. What if usb code
>>> (ide, serial, parallel) has guest exploitable bug? Currently I can happily
>>> continue running guests if they do not need affected subsystem. If we'll
>>> get it your way I will no longer be able to do so.
>>>        
>> qemu -device i440fx,ide=off
>>
>>      
> So you still need to support arbitrary composition. What's the
> difference?

No, we don't.  It's possible to have an 'rtc=off' option but I'm 
tremendously opposed to doing this.  Arbitrary composition is not a 
useful goal IMHO.

>   So why do you like -device i440fx over what we have now?
>    

Because I don't think tools like libvirt should be doing device 
composition to create an i440fx-like chipset.  I think the current path 
we're on is pushing too much logic that belongs in QEMU into the 
management stack.

> In current speak you propose will be implement by using i440fx machine
> type. Qdev will build it for you.
>    

If you had an i440fx machine type, that had no non-optional components 
added, and you could specify options to the machine type, yes.  But I 
think you'll agree that there's no reason to not just treat the i440fx 
as a device.

>> If you really care to do this.  But this desire to remove devices is
>> silly IMHO.  Concerns about security are misplaced.  If you have to
>> change the way a guest is invoked in order to eliminate security
>> problems, then there's something seriously wrong.
>>
>>      
> No I do not.  I do not create guest with unneeded devices from the
> beginning.
>    

There is very little that isn't 'unneeded'.

Regards,

Anthony Liguori

> --
> 			Gleb.
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
> On 02/10/2011 11:10 AM, Gleb Natapov wrote:
> >On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
> >>On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> >>>So what if it is easier, it doesn't mean it is correct thing to do.
> >>If we spend the next 10 years trying to do the "correct thing" for
> >>some arbitrary definition of correct, that's not terribly useful.
> >Changing direction by 180 every 2 years even less useful.
> 
> If we think through what we are doing and have a coherent
> architecture before changing direction, then we won't have this
> problem.
> 
I'd like to believe this :)

> >>It's really simple actually.  Let's do the least clever thing and
> >>model how hardware actual works.  Once we have that, we can try to
> >>be better than real hardware (if it's possible).
> >I think out understanding on how HW actually works is very different.
> >You are placing to much value on were device resides physically, for me
> >it is completely unimportant detail. Not worth even mentioning.
> 
> No, I place value on how things are modelled in the real world.
Real world (physical HW) have consideration not relevant for our
software emulation. Such as cost, physical dimension, power consumption
and many other I am sure I missed.

> 
> There simply aren't PC's out there that lack an RTC so I have no
> interest in jumping through hoops in QEMU to make it possible to do
> this without modifying QEMU code.  It might sound nice to a
> developer but it's of absolutely no use to users.
> 
RTC is not good example. HPET suppose to replace it (and PIT too). AFAIC
there are PCs without RTC already. Good example would be PIC or IOAPIC
device and then I would agree with you that it is not worth it to make
it possible to create x86 machine without them from command line if it
means extra complexity. But how have you jumped from this to "lets make usb
mandatory"?

> >>>>If all composition is done through a factory interface, it doesn't.
> >>>>But my main argument here is that we shouldn't try to make all
> >>>>composition done through a factory interface--only where it makes
> >>>>sense.
> >>>>
> >>>>So very concretely, I'm suggesting we do the following to target-i386:
> >>>>
> >>>>1) make the i440fx device have an embedded ide controller, piix3,
> >>>>and usb controller that get initialized automatically.  The piix3
> >>>>embeds the PCI-to-ISA bridge along with all of the default ISA
> >>>>devices (rtc, serial, etc.).
> >>>This may be a problem even from security point of view. What if usb code
> >>>(ide, serial, parallel) has guest exploitable bug? Currently I can happily
> >>>continue running guests if they do not need affected subsystem. If we'll
> >>>get it your way I will no longer be able to do so.
> >>qemu -device i440fx,ide=off
> >>
> >So you still need to support arbitrary composition. What's the
> >difference?
> 
> No, we don't.  It's possible to have an 'rtc=off' option but I'm
> tremendously opposed to doing this.  Arbitrary composition is not a
> useful goal IMHO.
IMHO is different. We should support composition where it makes sense.
For PIC-less x86 it doesn't make it. For usb-less or even ide-less it
does.

> 
> >  So why do you like -device i440fx over what we have now?
> 
> Because I don't think tools like libvirt should be doing device
> composition to create an i440fx-like chipset.  I think the current
> path we're on is pushing too much logic that belongs in QEMU into
> the management stack.
I can agree with that. But from this it doesn't follow that we should
get rid of composition. We shouldn't push composition of common HW to
libvirt. Looking at libvirt command line I do not think we do it though.
Typical libvirt command line specifies disks, networks, usb, vga. How 
-device i440fx will simplified that? Well usb could be omitted (but not
-usbdevice table), disks are not property of i440fx so they will stay,
since user may want to use virtio controller (which is not part of
i440fx) this should stay too. Network obviously will have to be
specified by libvirt too, vga may go to i440fx, but since libvirt
supports qxl we will have to have a way to disable default vga and
enable qxl instead. So will we really simplify libvirt's life by
introducing -device i440fx?

> 
> >In current speak you propose will be implement by using i440fx machine
> >type. Qdev will build it for you.
> 
> If you had an i440fx machine type, that had no non-optional
> components added, and you could specify options to the machine type,
> yes.  But I think you'll agree that there's no reason to not just
> treat the i440fx as a device.
I do not agree. There is not such device as i440fx. This is just
packaging.

> 
> >>If you really care to do this.  But this desire to remove devices is
> >>silly IMHO.  Concerns about security are misplaced.  If you have to
> >>change the way a guest is invoked in order to eliminate security
> >>problems, then there's something seriously wrong.
> >>
> >No I do not.  I do not create guest with unneeded devices from the
> >beginning.
> 
> There is very little that isn't 'unneeded'.
> 
That depends on the guest. For guest that needs only disk and network
much can be omitted.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 11:49 AM, Gleb Natapov wrote:
> On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
>    
>> On 02/10/2011 11:10 AM, Gleb Natapov wrote:
>>      
>>> On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
>>>        
>>>> On 02/10/2011 10:07 AM, Gleb Natapov wrote:
>>>>          
>>>>> So what if it is easier, it doesn't mean it is correct thing to do.
>>>>>            
>>>> If we spend the next 10 years trying to do the "correct thing" for
>>>> some arbitrary definition of correct, that's not terribly useful.
>>>>          
>>> Changing direction by 180 every 2 years even less useful.
>>>        
>> If we think through what we are doing and have a coherent
>> architecture before changing direction, then we won't have this
>> problem.
>>
>>      
> I'd like to believe this :)
>
>    
>>>> It's really simple actually.  Let's do the least clever thing and
>>>> model how hardware actual works.  Once we have that, we can try to
>>>> be better than real hardware (if it's possible).
>>>>          
>>> I think out understanding on how HW actually works is very different.
>>> You are placing to much value on were device resides physically, for me
>>> it is completely unimportant detail. Not worth even mentioning.
>>>        
>> No, I place value on how things are modelled in the real world.
>>      
> Real world (physical HW) have consideration not relevant for our
> software emulation. Such as cost, physical dimension, power consumption
> and many other I am sure I missed.
>
>    
>> There simply aren't PC's out there that lack an RTC so I have no
>> interest in jumping through hoops in QEMU to make it possible to do
>> this without modifying QEMU code.  It might sound nice to a
>> developer but it's of absolutely no use to users.
>>
>>      
> RTC is not good example. HPET suppose to replace it (and PIT too).

HPET's embed RTCs to provide support for legacy implementations.   This 
is extremely good example of where our modelling breaks down.  Take a 
close look at how the HPET and RTC emulations interact for an example of 
why we'd be much better off just implementing an RTC within an HPET.

>   AFAIC
> there are PCs without RTC already.

RTC also provides CMOS functionality and no PC can boot without CMOS.  
So no, there's nothing we'd consider a PC today that doesn't have an RTC.

>   Good example would be PIC or IOAPIC
> device and then I would agree with you that it is not worth it to make
> it possible to create x86 machine without them from command line if it
> means extra complexity. But how have you jumped from this to "lets make usb
> mandatory"?
>    

USB is mandatory in the PIIX3 but the only significant difference 
between the piix2 and piix3 is the addition of USB.  Consequentially, 
the main difference between an i440fx and i440bx is the use of a piix2 
vs. a piix3.  So if you really want to create the same PC we have today 
w/o USB, the right way to do it would be to have:

-device i440,model=fx   // with USB
-device i440,model=bx  // w/o USB


>> No, we don't. It's possible to have an 'rtc=off' option but I'm
>> tremendously opposed to doing this.  Arbitrary composition is not a
>> useful goal IMHO.
>>      
> IMHO is different. We should support composition where it makes sense.
> For PIC-less x86 it doesn't make it. For usb-less or even ide-less it
> does.
>    

The right way to do a USB-less PC is to have an option to create an i440bx.

An IDE-less PC is a bit more difficult because IDE is really baked into 
the concept of a PC.  Chances are, there are more than a few guests out 
there that would have issues from there being no IDE bus present.

>>      
>>>   So why do you like -device i440fx over what we have now?
>>>        
>> Because I don't think tools like libvirt should be doing device
>> composition to create an i440fx-like chipset.  I think the current
>> path we're on is pushing too much logic that belongs in QEMU into
>> the management stack.
>>      
> I can agree with that. But from this it doesn't follow that we should
> get rid of composition. We shouldn't push composition of common HW to
> libvirt. Looking at libvirt command line I do not think we do it though.
> Typical libvirt command line specifies disks, networks, usb, vga. How
> -device i440fx will simplified that? Well usb could be omitted (but not
> -usbdevice table), disks are not property of i440fx so they will stay,
> since user may want to use virtio controller (which is not part of
> i440fx) this should stay too. Network obviously will have to be
> specified by libvirt too, vga may go to i440fx, but since libvirt
> supports qxl we will have to have a way to disable default vga and
> enable qxl instead. So will we really simplify libvirt's life by
> introducing -device i440fx?
>    

libvirt also uses -no-defaults which prevents much of the PC's machine 
init from creating anything but stuff that really belongs in the main 
chipset.

But I bet if you asked 5 different QEMU developers what belongs in 
machine init and what the role of -no-defaults is, you'd get different 
answers.

OTOH, skipping any notion of machine and explicitly creating a chipset 
provides a very consistent architecture.

>>      
>>> In current speak you propose will be implement by using i440fx machine
>>> type. Qdev will build it for you.
>>>        
>> If you had an i440fx machine type, that had no non-optional
>> components added, and you could specify options to the machine type,
>> yes.  But I think you'll agree that there's no reason to not just
>> treat the i440fx as a device.
>>      
> I do not agree. There is not such device as i440fx. This is just
> packaging.
>    

Nope, that's definitely not true.  There's quite a bit of logic that is 
in the silicon that is not part of PIIX3.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 01:47:06PM +0100, Anthony Liguori wrote:
> On 02/10/2011 11:49 AM, Gleb Natapov wrote:
> >On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote:
> >>On 02/10/2011 11:10 AM, Gleb Natapov wrote:
> >>>On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote:
> >>>>On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> >>>>>So what if it is easier, it doesn't mean it is correct thing to do.
> >>>>If we spend the next 10 years trying to do the "correct thing" for
> >>>>some arbitrary definition of correct, that's not terribly useful.
> >>>Changing direction by 180 every 2 years even less useful.
> >>If we think through what we are doing and have a coherent
> >>architecture before changing direction, then we won't have this
> >>problem.
> >>
> >I'd like to believe this :)
> >
> >>>>It's really simple actually.  Let's do the least clever thing and
> >>>>model how hardware actual works.  Once we have that, we can try to
> >>>>be better than real hardware (if it's possible).
> >>>I think out understanding on how HW actually works is very different.
> >>>You are placing to much value on were device resides physically, for me
> >>>it is completely unimportant detail. Not worth even mentioning.
> >>No, I place value on how things are modelled in the real world.
> >Real world (physical HW) have consideration not relevant for our
> >software emulation. Such as cost, physical dimension, power consumption
> >and many other I am sure I missed.
> >
> >>There simply aren't PC's out there that lack an RTC so I have no
> >>interest in jumping through hoops in QEMU to make it possible to do
> >>this without modifying QEMU code.  It might sound nice to a
> >>developer but it's of absolutely no use to users.
> >>
> >RTC is not good example. HPET suppose to replace it (and PIT too).
> 
> HPET's embed RTCs to provide support for legacy implementations.
> This is extremely good example of where our modelling breaks down.
> Take a close look at how the HPET and RTC emulations interact for an
> example of why we'd be much better off just implementing an RTC
> within an HPET.
> 
Yes HPET can provide legacy RTC timer functionality. No I do not see why
we should implement RTC withing HPET. In your model we should remove
HPET code completely since HPET is not present in chipset emulated by
QEMU.

> >  AFAIC
> >there are PCs without RTC already.
> 
> RTC also provides CMOS functionality and no PC can boot without
> CMOS.  So no, there's nothing we'd consider a PC today that doesn't
> have an RTC.
CMOS may be present even if RTC functionality is absent. Does EFI base
machine still need CMOS though?

> 
> >  Good example would be PIC or IOAPIC
> >device and then I would agree with you that it is not worth it to make
> >it possible to create x86 machine without them from command line if it
> >means extra complexity. But how have you jumped from this to "lets make usb
> >mandatory"?
> 
> USB is mandatory in the PIIX3 but the only significant difference
> between the piix2 and piix3 is the addition of USB.
> Consequentially, the main difference between an i440fx and i440bx is
> the use of a piix2 vs. a piix3.  So if you really want to create the
> same PC we have today w/o USB, the right way to do it would be to
> have:
> 
> -device i440,model=fx   // with USB
> -device i440,model=bx  // w/o USB

Why not qemu -config piix2.cfg or qemu -config piix3.cfg? No need to
make data into code.

> 
> 
> >>No, we don't. It's possible to have an 'rtc=off' option but I'm
> >>tremendously opposed to doing this.  Arbitrary composition is not a
> >>useful goal IMHO.
> >IMHO is different. We should support composition where it makes sense.
> >For PIC-less x86 it doesn't make it. For usb-less or even ide-less it
> >does.
> 
> The right way to do a USB-less PC is to have an option to create an i440bx.
Why is this the right way?

> 
> An IDE-less PC is a bit more difficult because IDE is really baked
> into the concept of a PC.  Chances are, there are more than a few
> guests out there that would have issues from there being no IDE bus
> present.
> 
Non of my modern PCs have IDE. Many high end PC had SCSI instead of IDE
in the past. If guest can't run without IDE you do not run it without
IDE.

> >>>  So why do you like -device i440fx over what we have now?
> >>Because I don't think tools like libvirt should be doing device
> >>composition to create an i440fx-like chipset.  I think the current
> >>path we're on is pushing too much logic that belongs in QEMU into
> >>the management stack.
> >I can agree with that. But from this it doesn't follow that we should
> >get rid of composition. We shouldn't push composition of common HW to
> >libvirt. Looking at libvirt command line I do not think we do it though.
> >Typical libvirt command line specifies disks, networks, usb, vga. How
> >-device i440fx will simplified that? Well usb could be omitted (but not
> >-usbdevice table), disks are not property of i440fx so they will stay,
> >since user may want to use virtio controller (which is not part of
> >i440fx) this should stay too. Network obviously will have to be
> >specified by libvirt too, vga may go to i440fx, but since libvirt
> >supports qxl we will have to have a way to disable default vga and
> >enable qxl instead. So will we really simplify libvirt's life by
> >introducing -device i440fx?
> 
> libvirt also uses -no-defaults which prevents much of the PC's
> machine init from creating anything but stuff that really belongs in
> the main chipset.
> 
> But I bet if you asked 5 different QEMU developers what belongs in
> machine init and what the role of -no-defaults is, you'd get
> different answers.
> 
IIRC -no-defaults was created because the flexibility of creating
different HW configuration was needed, not just because someone had
to much time on its hands. Removing flexibility does not solve original
problem.

> OTOH, skipping any notion of machine and explicitly creating a
> chipset provides a very consistent architecture.
Just hard code everything and supporting only one HW configuration
provides even better consistency. Is this the right thing to do?

> 
> >>>In current speak you propose will be implement by using i440fx machine
> >>>type. Qdev will build it for you.
> >>If you had an i440fx machine type, that had no non-optional
> >>components added, and you could specify options to the machine type,
> >>yes.  But I think you'll agree that there's no reason to not just
> >>treat the i440fx as a device.
> >I do not agree. There is not such device as i440fx. This is just
> >packaging.
> 
> Nope, that's definitely not true.  There's quite a bit of logic that
> is in the silicon that is not part of PIIX3.
> 
What logic exactly? Where this logic described?

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/10/2011 11:07 AM, Gleb Natapov wrote:
> On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> >  On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >  >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
> >  >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >  >>>>ISASerialState dev;
> >  >>>>
> >  >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >  >>>>
> >  >>>Do you mean that there should be a generic way of doing that, like
> >  >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >  >>>hide qdev property setup?
> >  >>>
> >  >>>I still think that FDT should be used in the future. That would
> >  >>>require that the properties can be set up mechanically, and I don't
> >  >>>see how your proposal would help that.
> >  >>>
> >  >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >  >>why we're having so many problems with qdev.
> >  >>
> >  >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >  >>not all valid device trees correspond to interface and/or useful hardware
> >  >>hierarchies.
> >  >User creates a non-working machine and so gets to fix the problems?
> >  >How is that a problem for us?
> >
> >  It's not about creating a non-working machine.  It's about what
> >  user-level abstraction we need to provide.
> >
> >  It's a whole lot easier to implement an i440fx device with a fixed
> >  set of parameters than it is to make every possible subdevice have a
> >  proper factory interface along with mechanisms to hook everything
> >  together.
> >
> So what if it is easier, it doesn't mean it is correct thing to do. What
> you are proposing is just a huge step backwards. May be we shouldn't
> support hooking everything together in completely arbitrary ways, but we
> shouldn't force isa/pci devices upon our users just because they are
> non-removable on real chip.

I disagree.  We don't want to deviate from the spec any more than we 
already do.

The reason for wanting flexibility is because the code for the PIC or 
RTC, for example, can be used in other Super-IO chipsets or even 
standalone.  If qemu only supported the 440FX chipset, we'd have no 
reason to make things flexible.

> >
> >  So very concretely, I'm suggesting we do the following to target-i386:
> >
> >  1) make the i440fx device have an embedded ide controller, piix3,
> >  and usb controller that get initialized automatically.  The piix3
> >  embeds the PCI-to-ISA bridge along with all of the default ISA
> >  devices (rtc, serial, etc.).
> This may be a problem even from security point of view. What if usb code
> (ide, serial, parallel) has guest exploitable bug? Currently I can happily
> continue running guests if they do not need affected subsystem. If we'll
> get it your way I will no longer be able to do so.

You can't just remove a device from a guest.  You have to shut it down.  
When you power it back up, you may end up with different IRQ assignments 
or expose some guest bug.

If you have a security issue in code that is exposed to the guest, you 
have to fix it.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/10/2011 11:07 AM, Gleb Natapov wrote:
> On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> >  On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >  >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
> >  >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >  >>>>ISASerialState dev;
> >  >>>>
> >  >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >  >>>>
> >  >>>Do you mean that there should be a generic way of doing that, like
> >  >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >  >>>hide qdev property setup?
> >  >>>
> >  >>>I still think that FDT should be used in the future. That would
> >  >>>require that the properties can be set up mechanically, and I don't
> >  >>>see how your proposal would help that.
> >  >>>
> >  >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >  >>why we're having so many problems with qdev.
> >  >>
> >  >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >  >>not all valid device trees correspond to interface and/or useful hardware
> >  >>hierarchies.
> >  >User creates a non-working machine and so gets to fix the problems?
> >  >How is that a problem for us?
> >
> >  It's not about creating a non-working machine.  It's about what
> >  user-level abstraction we need to provide.
> >
> >  It's a whole lot easier to implement an i440fx device with a fixed
> >  set of parameters than it is to make every possible subdevice have a
> >  proper factory interface along with mechanisms to hook everything
> >  together.
> >
> So what if it is easier, it doesn't mean it is correct thing to do. What
> you are proposing is just a huge step backwards. May be we shouldn't
> support hooking everything together in completely arbitrary ways, but we
> shouldn't force isa/pci devices upon our users just because they are
> non-removable on real chip.

I disagree.  We don't want to deviate from the spec any more than we 
already do.

The reason for wanting flexibility is because the code for the PIC or 
RTC, for example, can be used in other Super-IO chipsets or even 
standalone.  If qemu only supported the 440FX chipset, we'd have no 
reason to make things flexible.

> >
> >  So very concretely, I'm suggesting we do the following to target-i386:
> >
> >  1) make the i440fx device have an embedded ide controller, piix3,
> >  and usb controller that get initialized automatically.  The piix3
> >  embeds the PCI-to-ISA bridge along with all of the default ISA
> >  devices (rtc, serial, etc.).
> This may be a problem even from security point of view. What if usb code
> (ide, serial, parallel) has guest exploitable bug? Currently I can happily
> continue running guests if they do not need affected subsystem. If we'll
> get it your way I will no longer be able to do so.

You can't just remove a device from a guest.  You have to shut it down.  
When you power it back up, you may end up with different IRQ assignments 
or expose some guest bug.

If you have a security issue in code that is exposed to the guest, you 
have to fix it.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 12:25:38PM +0200, Avi Kivity wrote:
> On 02/10/2011 11:07 AM, Gleb Natapov wrote:
> >On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> >>  On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >>  >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
> >>  >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >>  >>>>ISASerialState dev;
> >>  >>>>
> >>  >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >>  >>>>
> >>  >>>Do you mean that there should be a generic way of doing that, like
> >>  >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >>  >>>hide qdev property setup?
> >>  >>>
> >>  >>>I still think that FDT should be used in the future. That would
> >>  >>>require that the properties can be set up mechanically, and I don't
> >>  >>>see how your proposal would help that.
> >>  >>>
> >>  >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >>  >>why we're having so many problems with qdev.
> >>  >>
> >>  >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >>  >>not all valid device trees correspond to interface and/or useful hardware
> >>  >>hierarchies.
> >>  >User creates a non-working machine and so gets to fix the problems?
> >>  >How is that a problem for us?
> >>
> >>  It's not about creating a non-working machine.  It's about what
> >>  user-level abstraction we need to provide.
> >>
> >>  It's a whole lot easier to implement an i440fx device with a fixed
> >>  set of parameters than it is to make every possible subdevice have a
> >>  proper factory interface along with mechanisms to hook everything
> >>  together.
> >>
> >So what if it is easier, it doesn't mean it is correct thing to do. What
> >you are proposing is just a huge step backwards. May be we shouldn't
> >support hooking everything together in completely arbitrary ways, but we
> >shouldn't force isa/pci devices upon our users just because they are
> >non-removable on real chip.
> 
> I disagree.  We don't want to deviate from the spec any more than we
> already do.
> 
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset. It is memory controller/pci host bridge.
PIIX3/4 is the chipset which is just an arbitrary combination of devices
put on the same chip. We do not deviate from spec when we implement
those devices.

> The reason for wanting flexibility is because the code for the PIC
> or RTC, for example, can be used in other Super-IO chipsets or even
> standalone.  If qemu only supported the 440FX chipset, we'd have no
> reason to make things flexible.
Again you probably mean PIIX3. Even then removing unused ide will free
one more PCI slot for my cool virtio disk array. The things is, from
code point of view, it does not cost you extra to allow composition of
ide since it is just a regular PCI device and we need to support composing
those anyway.

> 
> >>
> >>  So very concretely, I'm suggesting we do the following to target-i386:
> >>
> >>  1) make the i440fx device have an embedded ide controller, piix3,
> >>  and usb controller that get initialized automatically.  The piix3
> >>  embeds the PCI-to-ISA bridge along with all of the default ISA
> >>  devices (rtc, serial, etc.).
> >This may be a problem even from security point of view. What if usb code
> >(ide, serial, parallel) has guest exploitable bug? Currently I can happily
> >continue running guests if they do not need affected subsystem. If we'll
> >get it your way I will no longer be able to do so.
> 
> You can't just remove a device from a guest.  You have to shut it
> down.  When you power it back up, you may end up with different IRQ
> assignments or expose some guest bug.
As I answered to Anthony already I am not talking about changing HW
configuration after guest is created rather about creating minimal HW
setup for the task from the start. This means no soundcard or usb for
Windows exchange server for instance.

> 
> If you have a security issue in code that is exposed to the guest,
> you have to fix it.
> 
Of course. That is why it is a good idea to expose as little code to
guest as possible. Don't you think so?

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 12:25:38PM +0200, Avi Kivity wrote:
> On 02/10/2011 11:07 AM, Gleb Natapov wrote:
> >On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote:
> >>  On 02/09/2011 09:15 PM, Blue Swirl wrote:
> >>  >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>   wrote:
> >>  >>On 02/09/2011 06:48 PM, Blue Swirl wrote:
> >>  >>>>ISASerialState dev;
> >>  >>>>
> >>  >>>>isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
> >>  >>>>
> >>  >>>Do you mean that there should be a generic way of doing that, like
> >>  >>>sysbus_create_varargs() for qdev, or just add inline functions which
> >>  >>>hide qdev property setup?
> >>  >>>
> >>  >>>I still think that FDT should be used in the future. That would
> >>  >>>require that the properties can be set up mechanically, and I don't
> >>  >>>see how your proposal would help that.
> >>  >>>
> >>  >>Yeah, I don't think that is a good idea anymore.  I think this is part of
> >>  >>why we're having so many problems with qdev.
> >>  >>
> >>  >>While (most?) hardware hierarchies can be represented by device tree syntax,
> >>  >>not all valid device trees correspond to interface and/or useful hardware
> >>  >>hierarchies.
> >>  >User creates a non-working machine and so gets to fix the problems?
> >>  >How is that a problem for us?
> >>
> >>  It's not about creating a non-working machine.  It's about what
> >>  user-level abstraction we need to provide.
> >>
> >>  It's a whole lot easier to implement an i440fx device with a fixed
> >>  set of parameters than it is to make every possible subdevice have a
> >>  proper factory interface along with mechanisms to hook everything
> >>  together.
> >>
> >So what if it is easier, it doesn't mean it is correct thing to do. What
> >you are proposing is just a huge step backwards. May be we shouldn't
> >support hooking everything together in completely arbitrary ways, but we
> >shouldn't force isa/pci devices upon our users just because they are
> >non-removable on real chip.
> 
> I disagree.  We don't want to deviate from the spec any more than we
> already do.
> 
Which spec? Even in this discussion we completely mixed different
things. 440FX is not a chipset. It is memory controller/pci host bridge.
PIIX3/4 is the chipset which is just an arbitrary combination of devices
put on the same chip. We do not deviate from spec when we implement
those devices.

> The reason for wanting flexibility is because the code for the PIC
> or RTC, for example, can be used in other Super-IO chipsets or even
> standalone.  If qemu only supported the 440FX chipset, we'd have no
> reason to make things flexible.
Again you probably mean PIIX3. Even then removing unused ide will free
one more PCI slot for my cool virtio disk array. The things is, from
code point of view, it does not cost you extra to allow composition of
ide since it is just a regular PCI device and we need to support composing
those anyway.

> 
> >>
> >>  So very concretely, I'm suggesting we do the following to target-i386:
> >>
> >>  1) make the i440fx device have an embedded ide controller, piix3,
> >>  and usb controller that get initialized automatically.  The piix3
> >>  embeds the PCI-to-ISA bridge along with all of the default ISA
> >>  devices (rtc, serial, etc.).
> >This may be a problem even from security point of view. What if usb code
> >(ide, serial, parallel) has guest exploitable bug? Currently I can happily
> >continue running guests if they do not need affected subsystem. If we'll
> >get it your way I will no longer be able to do so.
> 
> You can't just remove a device from a guest.  You have to shut it
> down.  When you power it back up, you may end up with different IRQ
> assignments or expose some guest bug.
As I answered to Anthony already I am not talking about changing HW
configuration after guest is created rather about creating minimal HW
setup for the task from the start. This means no soundcard or usb for
Windows exchange server for instance.

> 
> If you have a security issue in code that is exposed to the guest,
> you have to fix it.
> 
Of course. That is why it is a good idea to expose as little code to
guest as possible. Don't you think so?

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>
> Which spec? Even in this discussion we completely mixed different
> things. 440FX is not a chipset.

Yes, it is.  It's a single silicon package with a defined pinout.  If 
you don't believe me, re-read the spec.

It's a MCM with the PIIX3 being internally connected.   The connection 
between the i440fx and PIIX3 happens to be PCI but that's not always the 
case.  Sometimes it's a proprietary bus.

> Again you probably mean PIIX3. Even then removing unused ide will free
> one more PCI slot for my cool virtio disk array. The things is, from
> code point of view, it does not cost you extra to allow composition of
> ide since it is just a regular PCI device and we need to support composing
> those anyway.
>    

If this is useful, and it doesn't break guests, you can always do 
-device i440fx,ide=off.  However, it's an exception where we're 
deviating from how hardware works.

And that's okay, but the base modelling ought to follow real hardware 
closely with deviations being the exception.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>
> Which spec? Even in this discussion we completely mixed different
> things. 440FX is not a chipset.

Yes, it is.  It's a single silicon package with a defined pinout.  If 
you don't believe me, re-read the spec.

It's a MCM with the PIIX3 being internally connected.   The connection 
between the i440fx and PIIX3 happens to be PCI but that's not always the 
case.  Sometimes it's a proprietary bus.

> Again you probably mean PIIX3. Even then removing unused ide will free
> one more PCI slot for my cool virtio disk array. The things is, from
> code point of view, it does not cost you extra to allow composition of
> ide since it is just a regular PCI device and we need to support composing
> those anyway.
>    

If this is useful, and it doesn't break guests, you can always do 
-device i440fx,ide=off.  However, it's an exception where we're 
deviating from how hardware works.

And that's okay, but the base modelling ought to follow real hardware 
closely with deviations being the exception.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/10/2011 02:51 PM, Anthony Liguori wrote:
> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>
>> Which spec? Even in this discussion we completely mixed different
>> things. 440FX is not a chipset.
>
> Yes, it is.  It's a single silicon package with a defined pinout.  If 
> you don't believe me, re-read the spec.
>
> It's a MCM with the PIIX3 being internally connected.   The connection 
> between the i440fx and PIIX3 happens to be PCI but that's not always 
> the case.  Sometimes it's a proprietary bus.

Aren't they two distinct chips, together comprising the chip-set?

One (the northbridge) converts the system bus to PCI + some extra wires, 
the other (southbridge) bridges PCI to ISA and contains some embedded 
ISA devices.  IIRC there are some wires between them that are not PCI.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/10/2011 02:51 PM, Anthony Liguori wrote:
> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>
>> Which spec? Even in this discussion we completely mixed different
>> things. 440FX is not a chipset.
>
> Yes, it is.  It's a single silicon package with a defined pinout.  If 
> you don't believe me, re-read the spec.
>
> It's a MCM with the PIIX3 being internally connected.   The connection 
> between the i440fx and PIIX3 happens to be PCI but that's not always 
> the case.  Sometimes it's a proprietary bus.

Aren't they two distinct chips, together comprising the chip-set?

One (the northbridge) converts the system bus to PCI + some extra wires, 
the other (southbridge) bridges PCI to ISA and contains some embedded 
ISA devices.  IIRC there are some wires between them that are not PCI.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 03:00:05PM +0200, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
> >On 02/10/2011 12:13 PM, Gleb Natapov wrote:
> >>
> >>Which spec? Even in this discussion we completely mixed different
> >>things. 440FX is not a chipset.
> >
> >Yes, it is.  It's a single silicon package with a defined pinout.
> >If you don't believe me, re-read the spec.
> >
> >It's a MCM with the PIIX3 being internally connected.   The
> >connection between the i440fx and PIIX3 happens to be PCI but
> >that's not always the case.  Sometimes it's a proprietary bus.
> 
> Aren't they two distinct chips, together comprising the chip-set?
> 
> One (the northbridge) converts the system bus to PCI + some extra
> wires, the other (southbridge) bridges PCI to ISA and contains some
> embedded ISA devices.  IIRC there are some wires between them that
> are not PCI.
> 
Yeah, 440fx is probably northbridge and PIIX3 southbridge.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 03:00:05PM +0200, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
> >On 02/10/2011 12:13 PM, Gleb Natapov wrote:
> >>
> >>Which spec? Even in this discussion we completely mixed different
> >>things. 440FX is not a chipset.
> >
> >Yes, it is.  It's a single silicon package with a defined pinout.
> >If you don't believe me, re-read the spec.
> >
> >It's a MCM with the PIIX3 being internally connected.   The
> >connection between the i440fx and PIIX3 happens to be PCI but
> >that's not always the case.  Sometimes it's a proprietary bus.
> 
> Aren't they two distinct chips, together comprising the chip-set?
> 
> One (the northbridge) converts the system bus to PCI + some extra
> wires, the other (southbridge) bridges PCI to ISA and contains some
> embedded ISA devices.  IIRC there are some wires between them that
> are not PCI.
> 
Yeah, 440fx is probably northbridge and PIIX3 southbridge.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 02:00 PM, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
>> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>>
>>> Which spec? Even in this discussion we completely mixed different
>>> things. 440FX is not a chipset.
>>
>> Yes, it is.  It's a single silicon package with a defined pinout.  If 
>> you don't believe me, re-read the spec.
>>
>> It's a MCM with the PIIX3 being internally connected.   The 
>> connection between the i440fx and PIIX3 happens to be PCI but that's 
>> not always the case.  Sometimes it's a proprietary bus.
>
> Aren't they two distinct chips, together comprising the chip-set?
>
> One (the northbridge) converts the system bus to PCI + some extra 
> wires, the other (southbridge) bridges PCI to ISA and contains some 
> embedded ISA devices.  IIRC there are some wires between them that are 
> not PCI.

Yes, you are correct.  So I can understand an argument for:

   -device i440fx,id=pmc -device piix3,chipset=pmc

Or something like that.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 02:00 PM, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
>> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>>
>>> Which spec? Even in this discussion we completely mixed different
>>> things. 440FX is not a chipset.
>>
>> Yes, it is.  It's a single silicon package with a defined pinout.  If 
>> you don't believe me, re-read the spec.
>>
>> It's a MCM with the PIIX3 being internally connected.   The 
>> connection between the i440fx and PIIX3 happens to be PCI but that's 
>> not always the case.  Sometimes it's a proprietary bus.
>
> Aren't they two distinct chips, together comprising the chip-set?
>
> One (the northbridge) converts the system bus to PCI + some extra 
> wires, the other (southbridge) bridges PCI to ISA and contains some 
> embedded ISA devices.  IIRC there are some wires between them that are 
> not PCI.

Yes, you are correct.  So I can understand an argument for:

   -device i440fx,id=pmc -device piix3,chipset=pmc

Or something like that.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 01:51:14PM +0100, Anthony Liguori wrote:
> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
> >
> >Which spec? Even in this discussion we completely mixed different
> >things. 440FX is not a chipset.
> 
> Yes, it is.  It's a single silicon package with a defined pinout.
> If you don't believe me, re-read the spec.
> 
> It's a MCM with the PIIX3 being internally connected.   The
> connection between the i440fx and PIIX3 happens to be PCI but that's
> not always the case.  Sometimes it's a proprietary bus.
> 
Which one? 29054901.pdf describes memory controller and PCI host bridge only.
 
> >Again you probably mean PIIX3. Even then removing unused ide will free
> >one more PCI slot for my cool virtio disk array. The things is, from
> >code point of view, it does not cost you extra to allow composition of
> >ide since it is just a regular PCI device and we need to support composing
> >those anyway.
> 
> If this is useful, and it doesn't break guests, you can always do
> -device i440fx,ide=off.  However, it's an exception where we're
> deviating from how hardware works.
> 
I don't care how command line will look like, but I do not see how you
will support ide=off without device composition unless you put ad-hoc
ifs all over your i440fx device code.

And I don't understand what do you mean by saying that this is not how
hardware works. Presence or absence of PCI device does not change how
hardware works.

> And that's okay, but the base modelling ought to follow real
> hardware closely with deviations being the exception.
> 
You keep saying this without explaining why. But with device composition
you will have exactly that, you will compose real chipsets using config
files, not code.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 01:51:14PM +0100, Anthony Liguori wrote:
> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
> >
> >Which spec? Even in this discussion we completely mixed different
> >things. 440FX is not a chipset.
> 
> Yes, it is.  It's a single silicon package with a defined pinout.
> If you don't believe me, re-read the spec.
> 
> It's a MCM with the PIIX3 being internally connected.   The
> connection between the i440fx and PIIX3 happens to be PCI but that's
> not always the case.  Sometimes it's a proprietary bus.
> 
Which one? 29054901.pdf describes memory controller and PCI host bridge only.
 
> >Again you probably mean PIIX3. Even then removing unused ide will free
> >one more PCI slot for my cool virtio disk array. The things is, from
> >code point of view, it does not cost you extra to allow composition of
> >ide since it is just a regular PCI device and we need to support composing
> >those anyway.
> 
> If this is useful, and it doesn't break guests, you can always do
> -device i440fx,ide=off.  However, it's an exception where we're
> deviating from how hardware works.
> 
I don't care how command line will look like, but I do not see how you
will support ide=off without device composition unless you put ad-hoc
ifs all over your i440fx device code.

And I don't understand what do you mean by saying that this is not how
hardware works. Presence or absence of PCI device does not change how
hardware works.

> And that's okay, but the base modelling ought to follow real
> hardware closely with deviations being the exception.
> 
You keep saying this without explaining why. But with device composition
you will have exactly that, you will compose real chipsets using config
files, not code.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 02:27 PM, Gleb Natapov wrote:
> I don't care how command line will look like, but I do not see how you
> will support ide=off without device composition unless you put ad-hoc
> ifs all over your i440fx device code.
>    

Yes, in the piix3 device code, the ide property would trigger an if().

BTW, I'm extremely sceptical that you really do have machines w/o IDE at 
all.  Even the servers we ship with only SAS or SCSI support still have 
an integrated IDE controller.

Since most servers are built from the same chipset design that has IDE, 
I don't really see how you could build a modern system without IDE.

>> And that's okay, but the base modelling ought to follow rea
>> hardware closely with deviations being the exception.
>>
>>      
> You keep saying this without explaining why. But with device composition
> you will have exactly that, you will compose real chipsets using config
> files, not code.
>    

Yeah, that's been the direction we've been going in since qdev was 
introduced.  I'm now convinced that this is overly ambitious.  By simply 
reducing the scope of conversion, we get 99% of the benefit with 10% of 
the effort.  Seems like a no brainer to me.

Regards,

Anthony Liguori

> --
> 			Gleb.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Thu, Feb 10, 2011 at 03:04:28PM +0100, Anthony Liguori wrote:
> On 02/10/2011 02:27 PM, Gleb Natapov wrote:
> >I don't care how command line will look like, but I do not see how you
> >will support ide=off without device composition unless you put ad-hoc
> >ifs all over your i440fx device code.
> 
> Yes, in the piix3 device code, the ide property would trigger an if().
> 
> BTW, I'm extremely sceptical that you really do have machines w/o
> IDE at all.  Even the servers we ship with only SAS or SCSI support
> still have an integrated IDE controller.
> 
> Since most servers are built from the same chipset design that has
> IDE, I don't really see how you could build a modern system without
> IDE.
> 
Well, this may be true. But since I can't find IDE (or ATA) nor in lspci
neither in dmesg does it really matter that silicon that implement IDE
functionality is present somewhere inside the box?

> >>And that's okay, but the base modelling ought to follow rea
> >>hardware closely with deviations being the exception.
> >>
> >You keep saying this without explaining why. But with device composition
> >you will have exactly that, you will compose real chipsets using config
> >files, not code.
> 
> Yeah, that's been the direction we've been going in since qdev was
> introduced.  I'm now convinced that this is overly ambitious.  By
> simply reducing the scope of conversion, we get 99% of the benefit
> with 10% of the effort.  Seems like a no brainer to me.
> 
Jugging by how well all previous conversion went we will end up with one
more way of creating devices. One legacy, another qdev and your new one.
And what is the problem with qdev again (not that I am a big qdev fan)?
The fact that there is no enough interest to convert all devices to it?
How new way of doing things will solve this?

Just to be clear I do not have problem with not having ability to
compose x86 without pit or kbd controller. Basic things like RTC, pit,
pic, ioapic, dma, kbd should be created unconditionally as part of x86
pc machine. But IMHO you are trying to take things to other extreme.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 03:20 PM, Gleb Natapov wrote:
> Jugging by how well all previous conversion went we will end up with one
> more way of creating devices. One legacy, another qdev and your new one.
> And what is the problem with qdev again (not that I am a big qdev fan)?
>    

We've really been arguing about probably the most minor aspect of the 
problem with qdev.

All I'm really saying is that we shouldn't tie device construction to a 
factory interface as we do with qdev.

That simply means that we should be able to do:

RTC *rtc_create(arg1, arg2, arg2);

And that a separate piece of code decides which devices are exposed 
through -device or device_add.  Which devices are exposed is really a 
minor detail.

That said, qdev has a number of significant limitations in my mind.  The 
first is that the only relationship between devices is through the 
BusState interface.  I don't think we should even try to have a generic 
bus model.  When you look at how badly broken PCI hotplug is current in 
qdev, I think this is symptomatic of this.

There's also no way in qdev to really have polymorphism.  Interfaces 
really aren't meaningful in qdev so you have things like PCIDevice where 
some methods are stored in the object instead of the class dispatch 
table and you have overuse of static class members.

And it's all unrelated to VMState.

And this is just the basic mechanisms of qdev.  The actual 
implementation is worse.  The use of qemu_irq as gpio in the base class 
and overuse of SystemBus is really quite insane.

And so far, the use of qdev has been entirely superficial.  Devices 
still don't make use of bus level interfaces to do I/O so we don't have 
any better componentization than we did before qdev.

> The fact that there is no enough interest to convert all devices to it?
>    

I don't think there is any device that has been improved by qdev.  
-device is a nice feature, but it could have been implemented without qdev.

Regards,

Anthony Liguori

> How new way of doing things will solve this?
>
> Just to be clear I do not have problem with not having ability to
> compose x86 without pit or kbd controller. Basic things like RTC, pit,
> pic, ioapic, dma, kbd should be created unconditionally as part of x86
> pc machine. But IMHO you are trying to take things to other extreme.
>
> --
> 			Gleb.
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>
>> Jugging by how well all previous conversion went we will end up with one
>> more way of creating devices. One legacy, another qdev and your new one.
>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>
>
> We've really been arguing about probably the most minor aspect of the
> problem with qdev.
>
> All I'm really saying is that we shouldn't tie device construction to a
> factory interface as we do with qdev.
>
> That simply means that we should be able to do:
>
> RTC *rtc_create(arg1, arg2, arg2);

I don't see how that would help at all. Throwing qdev away and just
calling various functions directly, with all states exposed would be
like QEMU 0.9.0.

> And that a separate piece of code decides which devices are exposed through
> -device or device_add.  Which devices are exposed is really a minor detail.
>
> That said, qdev has a number of significant limitations in my mind.  The
> first is that the only relationship between devices is through the BusState
> interface.

There's also qemu_irq for arbitrary signals.

>  I don't think we should even try to have a generic bus model.
>  When you look at how badly broken PCI hotplug is current in qdev, I think
> this is symptomatic of this.

And how should this be fixed? The API change would not help.

> There's also no way in qdev to really have polymorphism.  Interfaces really
> aren't meaningful in qdev so you have things like PCIDevice where some
> methods are stored in the object instead of the class dispatch table and you
> have overuse of static class members.

QEMU is developed in C, not C++.

> And it's all unrelated to VMState.

Right, but this has also the good side that not all device state is
automatically exported. If other devices would be allowed to muck with
a devices internal state freely, bad things could happen.

Device reset could also use standard register definitions, shared with VMState.

> And this is just the basic mechanisms of qdev.  The actual implementation is
> worse.  The use of qemu_irq as gpio in the base class and overuse of
> SystemBus is really quite insane.

Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
typedeffing pointers), otherwise it looks quite sane to me.

Could you point to examples of SystemBus overuse?

> And so far, the use of qdev has been entirely superficial.  Devices still
> don't make use of bus level interfaces to do I/O so we don't have any better
> componentization than we did before qdev.
>
>> The fact that there is no enough interest to convert all devices to it?
>>
>
> I don't think there is any device that has been improved by qdev.  -device
> is a nice feature, but it could have been implemented without qdev.

We have 'info qtree' which can't be implemented easily without a
generic device class. Avi (or who was it) sent patches to expose even
more device state.

With the patches I'm going to apply, if Redhat wants to disable
building various devices, it can be done without #ifdeffery. This is
not possible without a generic factory interface.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>
>> Jugging by how well all previous conversion went we will end up with one
>> more way of creating devices. One legacy, another qdev and your new one.
>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>
>
> We've really been arguing about probably the most minor aspect of the
> problem with qdev.
>
> All I'm really saying is that we shouldn't tie device construction to a
> factory interface as we do with qdev.
>
> That simply means that we should be able to do:
>
> RTC *rtc_create(arg1, arg2, arg2);

I don't see how that would help at all. Throwing qdev away and just
calling various functions directly, with all states exposed would be
like QEMU 0.9.0.

> And that a separate piece of code decides which devices are exposed through
> -device or device_add.  Which devices are exposed is really a minor detail.
>
> That said, qdev has a number of significant limitations in my mind.  The
> first is that the only relationship between devices is through the BusState
> interface.

There's also qemu_irq for arbitrary signals.

>  I don't think we should even try to have a generic bus model.
>  When you look at how badly broken PCI hotplug is current in qdev, I think
> this is symptomatic of this.

And how should this be fixed? The API change would not help.

> There's also no way in qdev to really have polymorphism.  Interfaces really
> aren't meaningful in qdev so you have things like PCIDevice where some
> methods are stored in the object instead of the class dispatch table and you
> have overuse of static class members.

QEMU is developed in C, not C++.

> And it's all unrelated to VMState.

Right, but this has also the good side that not all device state is
automatically exported. If other devices would be allowed to muck with
a devices internal state freely, bad things could happen.

Device reset could also use standard register definitions, shared with VMState.

> And this is just the basic mechanisms of qdev.  The actual implementation is
> worse.  The use of qemu_irq as gpio in the base class and overuse of
> SystemBus is really quite insane.

Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
typedeffing pointers), otherwise it looks quite sane to me.

Could you point to examples of SystemBus overuse?

> And so far, the use of qdev has been entirely superficial.  Devices still
> don't make use of bus level interfaces to do I/O so we don't have any better
> componentization than we did before qdev.
>
>> The fact that there is no enough interest to convert all devices to it?
>>
>
> I don't think there is any device that has been improved by qdev.  -device
> is a nice feature, but it could have been implemented without qdev.

We have 'info qtree' which can't be implemented easily without a
generic device class. Avi (or who was it) sent patches to expose even
more device state.

With the patches I'm going to apply, if Redhat wants to disable
building various devices, it can be done without #ifdeffery. This is
not possible without a generic factory interface.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote:
> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > On 02/10/2011 03:20 PM, Gleb Natapov wrote:
> >>
> >> Jugging by how well all previous conversion went we will end up with one
> >> more way of creating devices. One legacy, another qdev and your new one.
> >> And what is the problem with qdev again (not that I am a big qdev fan)?
> >>
> >
> > We've really been arguing about probably the most minor aspect of the
> > problem with qdev.
Probably. But if this aspect affects the overall re-design of device tree it
is not so minor after all.

> >
> > All I'm really saying is that we shouldn't tie device construction to a
> > factory interface as we do with qdev.
> >
> > That simply means that we should be able to do:
> >
> > RTC *rtc_create(arg1, arg2, arg2);
> 
> I don't see how that would help at all. Throwing qdev away and just
> calling various functions directly, with all states exposed would be
> like QEMU 0.9.0.
> 
That is my sentiment exactly. This is what we had before. What was the
reason we wanted device tree (let alone specific implementation of it
that was committed without much external input)? Why do you no longer want
device tree abstraction? 
 
> > And that a separate piece of code decides which devices are exposed through
> > -device or device_add.  Which devices are exposed is really a minor detail.
> >
> > That said, qdev has a number of significant limitations in my mind.  The
> > first is that the only relationship between devices is through the BusState
> > interface.
> 
> There's also qemu_irq for arbitrary signals.
> 
> >  I don't think we should even try to have a generic bus model.
> >  When you look at how badly broken PCI hotplug is current in qdev, I think
> > this is symptomatic of this.
> 
> And how should this be fixed? The API change would not help.
> 
> > There's also no way in qdev to really have polymorphism.  Interfaces really
> > aren't meaningful in qdev so you have things like PCIDevice where some
> > methods are stored in the object instead of the class dispatch table and you
> > have overuse of static class members.
> 
> QEMU is developed in C, not C++.
> 
> > And it's all unrelated to VMState.
> 
> Right, but this has also the good side that not all device state is
> automatically exported. If other devices would be allowed to muck with
> a devices internal state freely, bad things could happen.
> 
> Device reset could also use standard register definitions, shared with VMState.
> 
> > And this is just the basic mechanisms of qdev.  The actual implementation is
> > worse.  The use of qemu_irq as gpio in the base class and overuse of
> > SystemBus is really quite insane.
> 
> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
> typedeffing pointers), otherwise it looks quite sane to me.
> 
> Could you point to examples of SystemBus overuse?
> 
> > And so far, the use of qdev has been entirely superficial.  Devices still
> > don't make use of bus level interfaces to do I/O so we don't have any better
> > componentization than we did before qdev.
> >
> >> The fact that there is no enough interest to convert all devices to it?
> >>
> >
> > I don't think there is any device that has been improved by qdev.  -device
> > is a nice feature, but it could have been implemented without qdev.
> 
> We have 'info qtree' which can't be implemented easily without a
> generic device class. Avi (or who was it) sent patches to expose even
> more device state.
> 
> With the patches I'm going to apply, if Redhat wants to disable
> building various devices, it can be done without #ifdeffery. This is
> not possible without a generic factory interface.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote:
> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > On 02/10/2011 03:20 PM, Gleb Natapov wrote:
> >>
> >> Jugging by how well all previous conversion went we will end up with one
> >> more way of creating devices. One legacy, another qdev and your new one.
> >> And what is the problem with qdev again (not that I am a big qdev fan)?
> >>
> >
> > We've really been arguing about probably the most minor aspect of the
> > problem with qdev.
Probably. But if this aspect affects the overall re-design of device tree it
is not so minor after all.

> >
> > All I'm really saying is that we shouldn't tie device construction to a
> > factory interface as we do with qdev.
> >
> > That simply means that we should be able to do:
> >
> > RTC *rtc_create(arg1, arg2, arg2);
> 
> I don't see how that would help at all. Throwing qdev away and just
> calling various functions directly, with all states exposed would be
> like QEMU 0.9.0.
> 
That is my sentiment exactly. This is what we had before. What was the
reason we wanted device tree (let alone specific implementation of it
that was committed without much external input)? Why do you no longer want
device tree abstraction? 
 
> > And that a separate piece of code decides which devices are exposed through
> > -device or device_add.  Which devices are exposed is really a minor detail.
> >
> > That said, qdev has a number of significant limitations in my mind.  The
> > first is that the only relationship between devices is through the BusState
> > interface.
> 
> There's also qemu_irq for arbitrary signals.
> 
> >  I don't think we should even try to have a generic bus model.
> >  When you look at how badly broken PCI hotplug is current in qdev, I think
> > this is symptomatic of this.
> 
> And how should this be fixed? The API change would not help.
> 
> > There's also no way in qdev to really have polymorphism.  Interfaces really
> > aren't meaningful in qdev so you have things like PCIDevice where some
> > methods are stored in the object instead of the class dispatch table and you
> > have overuse of static class members.
> 
> QEMU is developed in C, not C++.
> 
> > And it's all unrelated to VMState.
> 
> Right, but this has also the good side that not all device state is
> automatically exported. If other devices would be allowed to muck with
> a devices internal state freely, bad things could happen.
> 
> Device reset could also use standard register definitions, shared with VMState.
> 
> > And this is just the basic mechanisms of qdev.  The actual implementation is
> > worse.  The use of qemu_irq as gpio in the base class and overuse of
> > SystemBus is really quite insane.
> 
> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
> typedeffing pointers), otherwise it looks quite sane to me.
> 
> Could you point to examples of SystemBus overuse?
> 
> > And so far, the use of qdev has been entirely superficial.  Devices still
> > don't make use of bus level interfaces to do I/O so we don't have any better
> > componentization than we did before qdev.
> >
> >> The fact that there is no enough interest to convert all devices to it?
> >>
> >
> > I don't think there is any device that has been improved by qdev.  -device
> > is a nice feature, but it could have been implemented without qdev.
> 
> We have 'info qtree' which can't be implemented easily without a
> generic device class. Avi (or who was it) sent patches to expose even
> more device state.
> 
> With the patches I'm going to apply, if Redhat wants to disable
> building various devices, it can be done without #ifdeffery. This is
> not possible without a generic factory interface.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/11/2011 12:14 PM, Blue Swirl wrote:
> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>      
>>> Jugging by how well all previous conversion went we will end up with one
>>> more way of creating devices. One legacy, another qdev and your new one.
>>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>>
>>>        
>> We've really been arguing about probably the most minor aspect of the
>> problem with qdev.
>>
>> All I'm really saying is that we shouldn't tie device construction to a
>> factory interface as we do with qdev.
>>
>> That simply means that we should be able to do:
>>
>> RTC *rtc_create(arg1, arg2, arg2);
>>      
> I don't see how that would help at all. Throwing qdev away and just
> calling various functions directly, with all states exposed would be
> like QEMU 0.9.0.
>    

qdev doesn't expose any state today.  qdev properties are 
construction-only properties that happen to be stored in each device state.

What we really need is a full property framework that includes 
properties with hookable getters and setters along with the ability to 
mark properties as construct-only, read-only, or read-write.

But I think it's reasonable to expose construct-only properties as just 
an initfn argument.

>> And that a separate piece of code decides which devices are exposed through
>> -device or device_add.  Which devices are exposed is really a minor detail.
>>
>> That said, qdev has a number of significant limitations in my mind.  The
>> first is that the only relationship between devices is through the BusState
>> interface.
>>      
> There's also qemu_irq for arbitrary signals.
>    

Yes, but qemu_irq is very restricted as it only models a signal bit of 
information and doesn't really have a mechanism to attach/detach in any 
generic way.

>>   I don't think we should even try to have a generic bus model.
>>   When you look at how badly broken PCI hotplug is current in qdev, I think
>> this is symptomatic of this.
>>      
> And how should this be fixed? The API change would not help.
>    

Just as we have bus level creation functions, we should have bus level 
hotplug interfaces.

>> There's also no way in qdev to really have polymorphism.  Interfaces really
>> aren't meaningful in qdev so you have things like PCIDevice where some
>> methods are stored in the object instead of the class dispatch table and you
>> have overuse of static class members.
>>      
> QEMU is developed in C, not C++.
>    

But we're trying to do object oriented programming in C so as long as 
we're doing that, we ought to do it right.

>> And it's all unrelated to VMState.
>>      
> Right, but this has also the good side that not all device state is
> automatically exported. If other devices would be allowed to muck with
> a devices internal state freely, bad things could happen.
>
> Device reset could also use standard register definitions, shared with VMState.
>    

There's a way to have formally verifiable serialization/deserialization 
if we can satisfy two conditions 1) the devices rely on no global state 
(i.e. static variables) and 2) every field asssociated with a device is 
marshalled during serialization/deserialization.

When we define a device, right now we say that certain state is writable 
during construction.  It's not a stretch to want to have some properties 
writable during runtime.  If we also had a mechanism to mark certain 
properties as read-only, but still were able to introspect them, we 
could implement serialization without having to have a second VMState 
definition.

Compatibility will always require manipulating state, but once you have 
the state stored in a data structure, you can describe those 
transformations in a pretty high level fashion.

>> And this is just the basic mechanisms of qdev.  The actual implementation is
>> worse.  The use of qemu_irq as gpio in the base class and overuse of
>> SystemBus is really quite insane.
>>      
> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
> typedeffing pointers), otherwise it looks quite sane to me.
>    

Any interfaces of a base class should make sense even for derived classes.

That means if the base class is going to expose essentially a pin-out 
interface, that if I have a PCIDevice and cast it to Device, I should be 
able to interact with the GPIO interface to interact with the PCI 
device.  Presumably, that means interfacing at the PCI signalling 
level.  That's insane to model in QEMU :-)

In reality, GPIO only makes sense for a small class of simple devices 
where modelling the pin-out interface makes sense (like a 7-segment 
LCD).  That suggests that GPIO should not be in the DeviceState 
interface but instead should be in a SimpleDevice subclass or something 
like that.

> Could you point to examples of SystemBus overuse?
>    

anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56

SystemBus has become a catch-all for shallow qdev conversions.  We've 
got Northbridges, RAM, and network devices sitting on the same bus...

>> I don't think there is any device that has been improved by qdev. 
>>  -device
>> is a nice feature, but it could have been implemented without qdev.
>>      
> We have 'info qtree' which can't be implemented easily without a
> generic device class. Avi (or who was it) sent patches to expose even
> more device state.
>
> With the patches I'm going to apply, if Redhat wants to disable
> building various devices, it can be done without #ifdeffery. This is
> not possible without a generic factory interface.
>    

I'm not arguing against a generic factory interface, I'm arguing that it 
should be separate.

IOW:

SerialState *serial_create(int iobase, int irq, ...);

static DeviceState *qdev_serial_create(QemuOpts *opts);

static void serial_init(void)
{
      qdev_register("serial", qdev_serial_create);
}

The key point is that when we create devices internally, we should have 
a C-friendly, type-safe interface to interact with.  This will encourage 
composition and a richer device model than what we have today.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/11/2011 12:14 PM, Blue Swirl wrote:
> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>      
>>> Jugging by how well all previous conversion went we will end up with one
>>> more way of creating devices. One legacy, another qdev and your new one.
>>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>>
>>>        
>> We've really been arguing about probably the most minor aspect of the
>> problem with qdev.
>>
>> All I'm really saying is that we shouldn't tie device construction to a
>> factory interface as we do with qdev.
>>
>> That simply means that we should be able to do:
>>
>> RTC *rtc_create(arg1, arg2, arg2);
>>      
> I don't see how that would help at all. Throwing qdev away and just
> calling various functions directly, with all states exposed would be
> like QEMU 0.9.0.
>    

qdev doesn't expose any state today.  qdev properties are 
construction-only properties that happen to be stored in each device state.

What we really need is a full property framework that includes 
properties with hookable getters and setters along with the ability to 
mark properties as construct-only, read-only, or read-write.

But I think it's reasonable to expose construct-only properties as just 
an initfn argument.

>> And that a separate piece of code decides which devices are exposed through
>> -device or device_add.  Which devices are exposed is really a minor detail.
>>
>> That said, qdev has a number of significant limitations in my mind.  The
>> first is that the only relationship between devices is through the BusState
>> interface.
>>      
> There's also qemu_irq for arbitrary signals.
>    

Yes, but qemu_irq is very restricted as it only models a signal bit of 
information and doesn't really have a mechanism to attach/detach in any 
generic way.

>>   I don't think we should even try to have a generic bus model.
>>   When you look at how badly broken PCI hotplug is current in qdev, I think
>> this is symptomatic of this.
>>      
> And how should this be fixed? The API change would not help.
>    

Just as we have bus level creation functions, we should have bus level 
hotplug interfaces.

>> There's also no way in qdev to really have polymorphism.  Interfaces really
>> aren't meaningful in qdev so you have things like PCIDevice where some
>> methods are stored in the object instead of the class dispatch table and you
>> have overuse of static class members.
>>      
> QEMU is developed in C, not C++.
>    

But we're trying to do object oriented programming in C so as long as 
we're doing that, we ought to do it right.

>> And it's all unrelated to VMState.
>>      
> Right, but this has also the good side that not all device state is
> automatically exported. If other devices would be allowed to muck with
> a devices internal state freely, bad things could happen.
>
> Device reset could also use standard register definitions, shared with VMState.
>    

There's a way to have formally verifiable serialization/deserialization 
if we can satisfy two conditions 1) the devices rely on no global state 
(i.e. static variables) and 2) every field asssociated with a device is 
marshalled during serialization/deserialization.

When we define a device, right now we say that certain state is writable 
during construction.  It's not a stretch to want to have some properties 
writable during runtime.  If we also had a mechanism to mark certain 
properties as read-only, but still were able to introspect them, we 
could implement serialization without having to have a second VMState 
definition.

Compatibility will always require manipulating state, but once you have 
the state stored in a data structure, you can describe those 
transformations in a pretty high level fashion.

>> And this is just the basic mechanisms of qdev.  The actual implementation is
>> worse.  The use of qemu_irq as gpio in the base class and overuse of
>> SystemBus is really quite insane.
>>      
> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
> typedeffing pointers), otherwise it looks quite sane to me.
>    

Any interfaces of a base class should make sense even for derived classes.

That means if the base class is going to expose essentially a pin-out 
interface, that if I have a PCIDevice and cast it to Device, I should be 
able to interact with the GPIO interface to interact with the PCI 
device.  Presumably, that means interfacing at the PCI signalling 
level.  That's insane to model in QEMU :-)

In reality, GPIO only makes sense for a small class of simple devices 
where modelling the pin-out interface makes sense (like a 7-segment 
LCD).  That suggests that GPIO should not be in the DeviceState 
interface but instead should be in a SimpleDevice subclass or something 
like that.

> Could you point to examples of SystemBus overuse?
>    

anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56

SystemBus has become a catch-all for shallow qdev conversions.  We've 
got Northbridges, RAM, and network devices sitting on the same bus...

>> I don't think there is any device that has been improved by qdev. 
>>  -device
>> is a nice feature, but it could have been implemented without qdev.
>>      
> We have 'info qtree' which can't be implemented easily without a
> generic device class. Avi (or who was it) sent patches to expose even
> more device state.
>
> With the patches I'm going to apply, if Redhat wants to disable
> building various devices, it can be done without #ifdeffery. This is
> not possible without a generic factory interface.
>    

I'm not arguing against a generic factory interface, I'm arguing that it 
should be separate.

IOW:

SerialState *serial_create(int iobase, int irq, ...);

static DeviceState *qdev_serial_create(QemuOpts *opts);

static void serial_init(void)
{
      qdev_register("serial", qdev_serial_create);
}

The key point is that when we create devices internally, we should have 
a C-friendly, type-safe interface to interact with.  This will encourage 
composition and a richer device model than what we have today.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/11/2011 12:14 PM, Blue Swirl wrote:
>>
>> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>>
>>>>
>>>> Jugging by how well all previous conversion went we will end up with one
>>>> more way of creating devices. One legacy, another qdev and your new one.
>>>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>>>
>>>>
>>>
>>> We've really been arguing about probably the most minor aspect of the
>>> problem with qdev.
>>>
>>> All I'm really saying is that we shouldn't tie device construction to a
>>> factory interface as we do with qdev.
>>>
>>> That simply means that we should be able to do:
>>>
>>> RTC *rtc_create(arg1, arg2, arg2);
>>>
>>
>> I don't see how that would help at all. Throwing qdev away and just
>> calling various functions directly, with all states exposed would be
>> like QEMU 0.9.0.
>>
>
> qdev doesn't expose any state today.  qdev properties are construction-only
> properties that happen to be stored in each device state.
>
> What we really need is a full property framework that includes properties
> with hookable getters and setters along with the ability to mark properties
> as construct-only, read-only, or read-write.
>
> But I think it's reasonable to expose construct-only properties as just an
> initfn argument.

Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.

>>> And that a separate piece of code decides which devices are exposed
>>> through
>>> -device or device_add.  Which devices are exposed is really a minor
>>> detail.
>>>
>>> That said, qdev has a number of significant limitations in my mind.  The
>>> first is that the only relationship between devices is through the
>>> BusState
>>> interface.
>>>
>>
>> There's also qemu_irq for arbitrary signals.
>>
>
> Yes, but qemu_irq is very restricted as it only models a signal bit of
> information and doesn't really have a mechanism to attach/detach in any
> generic way.

Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)

In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.

>>>  I don't think we should even try to have a generic bus model.
>>>  When you look at how badly broken PCI hotplug is current in qdev, I
>>> think
>>> this is symptomatic of this.
>>>
>>
>> And how should this be fixed? The API change would not help.
>>
>
> Just as we have bus level creation functions, we should have bus level
> hotplug interfaces.
>
>>> There's also no way in qdev to really have polymorphism.  Interfaces
>>> really
>>> aren't meaningful in qdev so you have things like PCIDevice where some
>>> methods are stored in the object instead of the class dispatch table and
>>> you
>>> have overuse of static class members.
>>>
>>
>> QEMU is developed in C, not C++.
>>
>
> But we're trying to do object oriented programming in C so as long as we're
> doing that, we ought to do it right.
>
>>> And it's all unrelated to VMState.
>>>
>>
>> Right, but this has also the good side that not all device state is
>> automatically exported. If other devices would be allowed to muck with
>> a devices internal state freely, bad things could happen.
>>
>> Device reset could also use standard register definitions, shared with
>> VMState.
>>
>
> There's a way to have formally verifiable serialization/deserialization if
> we can satisfy two conditions 1) the devices rely on no global state (i.e.
> static variables) and 2) every field asssociated with a device is marshalled
> during serialization/deserialization.
>
> When we define a device, right now we say that certain state is writable
> during construction.  It's not a stretch to want to have some properties
> writable during runtime.  If we also had a mechanism to mark certain
> properties as read-only, but still were able to introspect them, we could
> implement serialization without having to have a second VMState definition.
>
> Compatibility will always require manipulating state, but once you have the
> state stored in a data structure, you can describe those transformations in
> a pretty high level fashion.
>
>>> And this is just the basic mechanisms of qdev.  The actual implementation
>>> is
>>> worse.  The use of qemu_irq as gpio in the base class and overuse of
>>> SystemBus is really quite insane.
>>>
>>
>> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
>> typedeffing pointers), otherwise it looks quite sane to me.
>>
>
> Any interfaces of a base class should make sense even for derived classes.
>
> That means if the base class is going to expose essentially a pin-out
> interface, that if I have a PCIDevice and cast it to Device, I should be
> able to interact with the GPIO interface to interact with the PCI device.
>  Presumably, that means interfacing at the PCI signalling level.  That's
> insane to model in QEMU :-)

This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.

> In reality, GPIO only makes sense for a small class of simple devices where
> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
> suggests that GPIO should not be in the DeviceState interface but instead
> should be in a SimpleDevice subclass or something like that.
>
>> Could you point to examples of SystemBus overuse?
>>
>
> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
> 73
> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
> 56
>
> SystemBus has become a catch-all for shallow qdev conversions.  We've got
> Northbridges, RAM, and network devices sitting on the same bus...

On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.

The only other bus (MBus) would exist between CPU, IOMMU and memory.

But SysBus fitted the need until recently.

>>> I don't think there is any device that has been improved by qdev.
>>>  -device
>>> is a nice feature, but it could have been implemented without qdev.
>>>
>>
>> We have 'info qtree' which can't be implemented easily without a
>> generic device class. Avi (or who was it) sent patches to expose even
>> more device state.
>>
>> With the patches I'm going to apply, if Redhat wants to disable
>> building various devices, it can be done without #ifdeffery. This is
>> not possible without a generic factory interface.
>>
>
> I'm not arguing against a generic factory interface, I'm arguing that it
> should be separate.
>
> IOW:
>
> SerialState *serial_create(int iobase, int irq, ...);
>
> static DeviceState *qdev_serial_create(QemuOpts *opts);
>
> static void serial_init(void)
> {
>     qdev_register("serial", qdev_serial_create);
> }
>
> The key point is that when we create devices internally, we should have a
> C-friendly, type-safe interface to interact with.  This will encourage
> composition and a richer device model than what we have today.

Isn't this what we have now in most cases?

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/11/2011 12:14 PM, Blue Swirl wrote:
>>
>> On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 02/10/2011 03:20 PM, Gleb Natapov wrote:
>>>
>>>>
>>>> Jugging by how well all previous conversion went we will end up with one
>>>> more way of creating devices. One legacy, another qdev and your new one.
>>>> And what is the problem with qdev again (not that I am a big qdev fan)?
>>>>
>>>>
>>>
>>> We've really been arguing about probably the most minor aspect of the
>>> problem with qdev.
>>>
>>> All I'm really saying is that we shouldn't tie device construction to a
>>> factory interface as we do with qdev.
>>>
>>> That simply means that we should be able to do:
>>>
>>> RTC *rtc_create(arg1, arg2, arg2);
>>>
>>
>> I don't see how that would help at all. Throwing qdev away and just
>> calling various functions directly, with all states exposed would be
>> like QEMU 0.9.0.
>>
>
> qdev doesn't expose any state today.  qdev properties are construction-only
> properties that happen to be stored in each device state.
>
> What we really need is a full property framework that includes properties
> with hookable getters and setters along with the ability to mark properties
> as construct-only, read-only, or read-write.
>
> But I think it's reasonable to expose construct-only properties as just an
> initfn argument.

Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.

>>> And that a separate piece of code decides which devices are exposed
>>> through
>>> -device or device_add.  Which devices are exposed is really a minor
>>> detail.
>>>
>>> That said, qdev has a number of significant limitations in my mind.  The
>>> first is that the only relationship between devices is through the
>>> BusState
>>> interface.
>>>
>>
>> There's also qemu_irq for arbitrary signals.
>>
>
> Yes, but qemu_irq is very restricted as it only models a signal bit of
> information and doesn't really have a mechanism to attach/detach in any
> generic way.

Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)

In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.

>>>  I don't think we should even try to have a generic bus model.
>>>  When you look at how badly broken PCI hotplug is current in qdev, I
>>> think
>>> this is symptomatic of this.
>>>
>>
>> And how should this be fixed? The API change would not help.
>>
>
> Just as we have bus level creation functions, we should have bus level
> hotplug interfaces.
>
>>> There's also no way in qdev to really have polymorphism.  Interfaces
>>> really
>>> aren't meaningful in qdev so you have things like PCIDevice where some
>>> methods are stored in the object instead of the class dispatch table and
>>> you
>>> have overuse of static class members.
>>>
>>
>> QEMU is developed in C, not C++.
>>
>
> But we're trying to do object oriented programming in C so as long as we're
> doing that, we ought to do it right.
>
>>> And it's all unrelated to VMState.
>>>
>>
>> Right, but this has also the good side that not all device state is
>> automatically exported. If other devices would be allowed to muck with
>> a devices internal state freely, bad things could happen.
>>
>> Device reset could also use standard register definitions, shared with
>> VMState.
>>
>
> There's a way to have formally verifiable serialization/deserialization if
> we can satisfy two conditions 1) the devices rely on no global state (i.e.
> static variables) and 2) every field asssociated with a device is marshalled
> during serialization/deserialization.
>
> When we define a device, right now we say that certain state is writable
> during construction.  It's not a stretch to want to have some properties
> writable during runtime.  If we also had a mechanism to mark certain
> properties as read-only, but still were able to introspect them, we could
> implement serialization without having to have a second VMState definition.
>
> Compatibility will always require manipulating state, but once you have the
> state stored in a data structure, you can describe those transformations in
> a pretty high level fashion.
>
>>> And this is just the basic mechanisms of qdev.  The actual implementation
>>> is
>>> worse.  The use of qemu_irq as gpio in the base class and overuse of
>>> SystemBus is really quite insane.
>>>
>>
>> Maybe qemu_irq should be renamed to QEMUSignal (and I don't like
>> typedeffing pointers), otherwise it looks quite sane to me.
>>
>
> Any interfaces of a base class should make sense even for derived classes.
>
> That means if the base class is going to expose essentially a pin-out
> interface, that if I have a PCIDevice and cast it to Device, I should be
> able to interact with the GPIO interface to interact with the PCI device.
>  Presumably, that means interfacing at the PCI signalling level.  That's
> insane to model in QEMU :-)

This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.

> In reality, GPIO only makes sense for a small class of simple devices where
> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
> suggests that GPIO should not be in the DeviceState interface but instead
> should be in a SimpleDevice subclass or something like that.
>
>> Could you point to examples of SystemBus overuse?
>>
>
> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
> 73
> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
> 56
>
> SystemBus has become a catch-all for shallow qdev conversions.  We've got
> Northbridges, RAM, and network devices sitting on the same bus...

On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.

The only other bus (MBus) would exist between CPU, IOMMU and memory.

But SysBus fitted the need until recently.

>>> I don't think there is any device that has been improved by qdev.
>>>  -device
>>> is a nice feature, but it could have been implemented without qdev.
>>>
>>
>> We have 'info qtree' which can't be implemented easily without a
>> generic device class. Avi (or who was it) sent patches to expose even
>> more device state.
>>
>> With the patches I'm going to apply, if Redhat wants to disable
>> building various devices, it can be done without #ifdeffery. This is
>> not possible without a generic factory interface.
>>
>
> I'm not arguing against a generic factory interface, I'm arguing that it
> should be separate.
>
> IOW:
>
> SerialState *serial_create(int iobase, int irq, ...);
>
> static DeviceState *qdev_serial_create(QemuOpts *opts);
>
> static void serial_init(void)
> {
>     qdev_register("serial", qdev_serial_create);
> }
>
> The key point is that when we create devices internally, we should have a
> C-friendly, type-safe interface to interact with.  This will encourage
> composition and a richer device model than what we have today.

Isn't this what we have now in most cases?

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 01:37 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>>
>> qdev doesn't expose any state today.  qdev properties are construction-only
>> properties that happen to be stored in each device state.
>>
>> What we really need is a full property framework that includes properties
>> with hookable getters and setters along with the ability to mark properties
>> as construct-only, read-only, or read-write.
>>
>> But I think it's reasonable to expose construct-only properties as just an
>> initfn argument.
>>      
> Sounds OK. About read-write properties, what happens if we one day
> have extensive threading, and locks are pushed to device level? I can
> imagine a deadlock involving one thread running in IO thread for a
> device and another trying to access that device's properties. Maybe
> that is not different from function call version.
>    

You need hookable setters/getters that can acquire a lock and do the 
right thing.  It shouldn't be able to dead lock if the locking is 
designed right.


>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>> information and doesn't really have a mechanism to attach/detach in any
>> generic way.
>>      
> Basic signals are already very useful for many purposes, since they
> match digital logic signals in real HW. In theory, whole machines
> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>    

It's not just in theory.  In the C++ port of QEMU that I wrote, I 
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder 
by just using a device config file.

If done correctly, using referencing can be extremely powerful.  A full 
adder is a good example.  The gates really don't have any concept of bus 
and the relationship between gates is definitely not a tree.

> In the message passing IRQ discussion earlier, it was IIRC decided
> that the one bit version would not be changed but a separate message
> passing version would be created if ever needed.
>    

C already has a message passing interface that supports type safety 
called function pointers :-)

An object that implements multiple interfaces where the interface 
becomes the "message passing interface" is exactly what I've been saying 
we need.  It's flexible and the compiler helps us enforce typing.

>>
>> Any interfaces of a base class should make sense even for derived classes.
>>
>> That means if the base class is going to expose essentially a pin-out
>> interface, that if I have a PCIDevice and cast it to Device, I should be
>> able to interact with the GPIO interface to interact with the PCI device.
>>   Presumably, that means interfacing at the PCI signalling level.  That's
>> insane to model in QEMU :-)
>>      
> This would be doable, if we built buses from a bunch of signals, like
> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
> the undecoded address pins would be ignored. I don't think it would be
> useful, but a separate interface could be added for connecting to
> PCIBus with just qemu_irqs.
>    

Yeah, it's possible, but I don't want to spend my time doing this.

>> In reality, GPIO only makes sense for a small class of simple devices where
>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>> suggests that GPIO should not be in the DeviceState interface but instead
>> should be in a SimpleDevice subclass or something like that.
>>
>>      
>>> Could you point to examples of SystemBus overuse?
>>>
>>>        
>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>> 73
>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>> 56
>>
>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>> Northbridges, RAM, and network devices sitting on the same bus...
>>      
> On Sparc32 I have not bothered to create a SBus bus. Now it would be
> useful to get bootindex corrected. Most devices (even on-board IO)
> should use SBus.
>
> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>
> But SysBus fitted the need until recently.
>    

A good way to judge where a device is using a bus interface correct: 
does all of it's interactions with any other part of the guest state 
involve method calls to the bus?

Right now, the answer is no for just about every device in QEMU.  This 
is the problem that qdev really was meant to solve and we're not really 
any further along solving it unfortunately.

>> I'm not arguing against a generic factory interface, I'm arguing that it
>> should be separate.
>>
>> IOW:
>>
>> SerialState *serial_create(int iobase, int irq, ...);
>>
>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>
>> static void serial_init(void)
>> {
>>      qdev_register("serial", qdev_serial_create);
>> }
>>
>> The key point is that when we create devices internally, we should have a
>> C-friendly, type-safe interface to interact with.  This will encourage
>> composition and a richer device model than what we have today.
>>      
> Isn't this what we have now in most cases?
>    

No.  The common pattern of shallow conversion is:

struct SerialState
{
     // device state
};

struct ISASerialState
{
    ISADeviceState parent;
    SerialState serial;
};

void serial_init(SerialState *s);

void isa_serial_init(ISADevice *dev)
{
     ISASerialState *s = DO_UPCAST(dev);
     serial_init(&s->serial);
}

The problem with this is that you cannot use serial_init() if you want 
to have the device be reflected in the device tree.

GObject takes a different approach than I'm suggesting that is equally 
valid.  It supports a vararg constructor form and then provides 
C-friendly interfaces that use the vararg form.  For instance:

SerialState *serial_init(int iobase, int irq, ...)
{
      return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ..., 
NULL);
}

This is not a bad solution but what I was trying to avoid in my 
suggestion is a lot of the ugliness of supporting a factory 
initializer.  It may be a better approach in the long run though.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 01:37 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>>
>> qdev doesn't expose any state today.  qdev properties are construction-only
>> properties that happen to be stored in each device state.
>>
>> What we really need is a full property framework that includes properties
>> with hookable getters and setters along with the ability to mark properties
>> as construct-only, read-only, or read-write.
>>
>> But I think it's reasonable to expose construct-only properties as just an
>> initfn argument.
>>      
> Sounds OK. About read-write properties, what happens if we one day
> have extensive threading, and locks are pushed to device level? I can
> imagine a deadlock involving one thread running in IO thread for a
> device and another trying to access that device's properties. Maybe
> that is not different from function call version.
>    

You need hookable setters/getters that can acquire a lock and do the 
right thing.  It shouldn't be able to dead lock if the locking is 
designed right.


>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>> information and doesn't really have a mechanism to attach/detach in any
>> generic way.
>>      
> Basic signals are already very useful for many purposes, since they
> match digital logic signals in real HW. In theory, whole machines
> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>    

It's not just in theory.  In the C++ port of QEMU that I wrote, I 
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder 
by just using a device config file.

If done correctly, using referencing can be extremely powerful.  A full 
adder is a good example.  The gates really don't have any concept of bus 
and the relationship between gates is definitely not a tree.

> In the message passing IRQ discussion earlier, it was IIRC decided
> that the one bit version would not be changed but a separate message
> passing version would be created if ever needed.
>    

C already has a message passing interface that supports type safety 
called function pointers :-)

An object that implements multiple interfaces where the interface 
becomes the "message passing interface" is exactly what I've been saying 
we need.  It's flexible and the compiler helps us enforce typing.

>>
>> Any interfaces of a base class should make sense even for derived classes.
>>
>> That means if the base class is going to expose essentially a pin-out
>> interface, that if I have a PCIDevice and cast it to Device, I should be
>> able to interact with the GPIO interface to interact with the PCI device.
>>   Presumably, that means interfacing at the PCI signalling level.  That's
>> insane to model in QEMU :-)
>>      
> This would be doable, if we built buses from a bunch of signals, like
> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
> the undecoded address pins would be ignored. I don't think it would be
> useful, but a separate interface could be added for connecting to
> PCIBus with just qemu_irqs.
>    

Yeah, it's possible, but I don't want to spend my time doing this.

>> In reality, GPIO only makes sense for a small class of simple devices where
>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>> suggests that GPIO should not be in the DeviceState interface but instead
>> should be in a SimpleDevice subclass or something like that.
>>
>>      
>>> Could you point to examples of SystemBus overuse?
>>>
>>>        
>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>> 73
>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>> 56
>>
>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>> Northbridges, RAM, and network devices sitting on the same bus...
>>      
> On Sparc32 I have not bothered to create a SBus bus. Now it would be
> useful to get bootindex corrected. Most devices (even on-board IO)
> should use SBus.
>
> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>
> But SysBus fitted the need until recently.
>    

A good way to judge where a device is using a bus interface correct: 
does all of it's interactions with any other part of the guest state 
involve method calls to the bus?

Right now, the answer is no for just about every device in QEMU.  This 
is the problem that qdev really was meant to solve and we're not really 
any further along solving it unfortunately.

>> I'm not arguing against a generic factory interface, I'm arguing that it
>> should be separate.
>>
>> IOW:
>>
>> SerialState *serial_create(int iobase, int irq, ...);
>>
>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>
>> static void serial_init(void)
>> {
>>      qdev_register("serial", qdev_serial_create);
>> }
>>
>> The key point is that when we create devices internally, we should have a
>> C-friendly, type-safe interface to interact with.  This will encourage
>> composition and a richer device model than what we have today.
>>      
> Isn't this what we have now in most cases?
>    

No.  The common pattern of shallow conversion is:

struct SerialState
{
     // device state
};

struct ISASerialState
{
    ISADeviceState parent;
    SerialState serial;
};

void serial_init(SerialState *s);

void isa_serial_init(ISADevice *dev)
{
     ISASerialState *s = DO_UPCAST(dev);
     serial_init(&s->serial);
}

The problem with this is that you cannot use serial_init() if you want 
to have the device be reflected in the device tree.

GObject takes a different approach than I'm suggesting that is equally 
valid.  It supports a vararg constructor form and then provides 
C-friendly interfaces that use the vararg form.  For instance:

SerialState *serial_init(int iobase, int irq, ...)
{
      return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ..., 
NULL);
}

This is not a bad solution but what I was trying to avoid in my 
suggestion is a lot of the ugliness of supporting a factory 
initializer.  It may be a better approach in the long run though.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> qdev doesn't expose any state today.  qdev properties are
>>> construction-only
>>> properties that happen to be stored in each device state.
>>>
>>> What we really need is a full property framework that includes properties
>>> with hookable getters and setters along with the ability to mark
>>> properties
>>> as construct-only, read-only, or read-write.
>>>
>>> But I think it's reasonable to expose construct-only properties as just
>>> an
>>> initfn argument.
>>>
>>
>> Sounds OK. About read-write properties, what happens if we one day
>> have extensive threading, and locks are pushed to device level? I can
>> imagine a deadlock involving one thread running in IO thread for a
>> device and another trying to access that device's properties. Maybe
>> that is not different from function call version.
>>
>
> You need hookable setters/getters that can acquire a lock and do the right
> thing.  It shouldn't be able to dead lock if the locking is designed right.
>
>
>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>> information and doesn't really have a mechanism to attach/detach in any
>>> generic way.
>>>
>>
>> Basic signals are already very useful for many purposes, since they
>> match digital logic signals in real HW. In theory, whole machines
>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>
>
> It's not just in theory.  In the C++ port of QEMU that I wrote, I
> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
> just using a device config file.
>
> If done correctly, using referencing can be extremely powerful.  A full
> adder is a good example.  The gates really don't have any concept of bus and
> the relationship between gates is definitely not a tree.
>
>> In the message passing IRQ discussion earlier, it was IIRC decided
>> that the one bit version would not be changed but a separate message
>> passing version would be created if ever needed.
>>
>
> C already has a message passing interface that supports type safety called
> function pointers :-)
>
> An object that implements multiple interfaces where the interface becomes
> the "message passing interface" is exactly what I've been saying we need.
>  It's flexible and the compiler helps us enforce typing.
>
>>>
>>> Any interfaces of a base class should make sense even for derived
>>> classes.
>>>
>>> That means if the base class is going to expose essentially a pin-out
>>> interface, that if I have a PCIDevice and cast it to Device, I should be
>>> able to interact with the GPIO interface to interact with the PCI device.
>>>  Presumably, that means interfacing at the PCI signalling level.  That's
>>> insane to model in QEMU :-)
>>>
>>
>> This would be doable, if we built buses from a bunch of signals, like
>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>> the undecoded address pins would be ignored. I don't think it would be
>> useful, but a separate interface could be added for connecting to
>> PCIBus with just qemu_irqs.
>>
>
> Yeah, it's possible, but I don't want to spend my time doing this.
>
>>> In reality, GPIO only makes sense for a small class of simple devices
>>> where
>>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>>> suggests that GPIO should not be in the DeviceState interface but instead
>>> should be in a SimpleDevice subclass or something like that.
>>>
>>>
>>>>
>>>> Could you point to examples of SystemBus overuse?
>>>>
>>>>
>>>
>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>> 73
>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>> 56
>>>
>>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>
>>
>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>> useful to get bootindex corrected. Most devices (even on-board IO)
>> should use SBus.
>>
>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>
>> But SysBus fitted the need until recently.
>>
>
> A good way to judge where a device is using a bus interface correct: does
> all of it's interactions with any other part of the guest state involve
> method calls to the bus?
>
> Right now, the answer is no for just about every device in QEMU.  This is
> the problem that qdev really was meant to solve and we're not really any
> further along solving it unfortunately.
>
>>> I'm not arguing against a generic factory interface, I'm arguing that it
>>> should be separate.
>>>
>>> IOW:
>>>
>>> SerialState *serial_create(int iobase, int irq, ...);
>>>
>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>
>>> static void serial_init(void)
>>> {
>>>     qdev_register("serial", qdev_serial_create);
>>> }
>>>
>>> The key point is that when we create devices internally, we should have a
>>> C-friendly, type-safe interface to interact with.  This will encourage
>>> composition and a richer device model than what we have today.
>>>
>>
>> Isn't this what we have now in most cases?
>>
>
> No.  The common pattern of shallow conversion is:
>
> struct SerialState
> {
>    // device state
> };
>
> struct ISASerialState
> {
>   ISADeviceState parent;
>   SerialState serial;
> };
>
> void serial_init(SerialState *s);
>
> void isa_serial_init(ISADevice *dev)
> {
>    ISASerialState *s = DO_UPCAST(dev);
>    serial_init(&s->serial);
> }
>
> The problem with this is that you cannot use serial_init() if you want to
> have the device be reflected in the device tree.

But why would serial_init() be used anymore since isa_serial_init() is as good?

> GObject takes a different approach than I'm suggesting that is equally
> valid.  It supports a vararg constructor form and then provides C-friendly
> interfaces that use the vararg form.  For instance:
>
> SerialState *serial_init(int iobase, int irq, ...)
> {
>     return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
> NULL);
> }
>
> This is not a bad solution but what I was trying to avoid in my suggestion
> is a lot of the ugliness of supporting a factory initializer.  It may be a
> better approach in the long run though.

Producing varargs lists may get messy if the list is filled
differently based on some conditions. It's also not easy to do things
in between:
dev = isa_create();
qdev_prop_set_uint32(dev);
if (flag1) {
  qdev_prop_set_uint32(dev);
}
if (flag2) {
  int f = func();
  qdev_prop_set_uint32(dev, f);
}
qdev_prop_set_uint32(dev);
qdev_init_nofail(dev);

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> qdev doesn't expose any state today.  qdev properties are
>>> construction-only
>>> properties that happen to be stored in each device state.
>>>
>>> What we really need is a full property framework that includes properties
>>> with hookable getters and setters along with the ability to mark
>>> properties
>>> as construct-only, read-only, or read-write.
>>>
>>> But I think it's reasonable to expose construct-only properties as just
>>> an
>>> initfn argument.
>>>
>>
>> Sounds OK. About read-write properties, what happens if we one day
>> have extensive threading, and locks are pushed to device level? I can
>> imagine a deadlock involving one thread running in IO thread for a
>> device and another trying to access that device's properties. Maybe
>> that is not different from function call version.
>>
>
> You need hookable setters/getters that can acquire a lock and do the right
> thing.  It shouldn't be able to dead lock if the locking is designed right.
>
>
>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>> information and doesn't really have a mechanism to attach/detach in any
>>> generic way.
>>>
>>
>> Basic signals are already very useful for many purposes, since they
>> match digital logic signals in real HW. In theory, whole machines
>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>
>
> It's not just in theory.  In the C++ port of QEMU that I wrote, I
> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
> just using a device config file.
>
> If done correctly, using referencing can be extremely powerful.  A full
> adder is a good example.  The gates really don't have any concept of bus and
> the relationship between gates is definitely not a tree.
>
>> In the message passing IRQ discussion earlier, it was IIRC decided
>> that the one bit version would not be changed but a separate message
>> passing version would be created if ever needed.
>>
>
> C already has a message passing interface that supports type safety called
> function pointers :-)
>
> An object that implements multiple interfaces where the interface becomes
> the "message passing interface" is exactly what I've been saying we need.
>  It's flexible and the compiler helps us enforce typing.
>
>>>
>>> Any interfaces of a base class should make sense even for derived
>>> classes.
>>>
>>> That means if the base class is going to expose essentially a pin-out
>>> interface, that if I have a PCIDevice and cast it to Device, I should be
>>> able to interact with the GPIO interface to interact with the PCI device.
>>>  Presumably, that means interfacing at the PCI signalling level.  That's
>>> insane to model in QEMU :-)
>>>
>>
>> This would be doable, if we built buses from a bunch of signals, like
>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>> the undecoded address pins would be ignored. I don't think it would be
>> useful, but a separate interface could be added for connecting to
>> PCIBus with just qemu_irqs.
>>
>
> Yeah, it's possible, but I don't want to spend my time doing this.
>
>>> In reality, GPIO only makes sense for a small class of simple devices
>>> where
>>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>>> suggests that GPIO should not be in the DeviceState interface but instead
>>> should be in a SimpleDevice subclass or something like that.
>>>
>>>
>>>>
>>>> Could you point to examples of SystemBus overuse?
>>>>
>>>>
>>>
>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>> 73
>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>> 56
>>>
>>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>
>>
>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>> useful to get bootindex corrected. Most devices (even on-board IO)
>> should use SBus.
>>
>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>
>> But SysBus fitted the need until recently.
>>
>
> A good way to judge where a device is using a bus interface correct: does
> all of it's interactions with any other part of the guest state involve
> method calls to the bus?
>
> Right now, the answer is no for just about every device in QEMU.  This is
> the problem that qdev really was meant to solve and we're not really any
> further along solving it unfortunately.
>
>>> I'm not arguing against a generic factory interface, I'm arguing that it
>>> should be separate.
>>>
>>> IOW:
>>>
>>> SerialState *serial_create(int iobase, int irq, ...);
>>>
>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>
>>> static void serial_init(void)
>>> {
>>>     qdev_register("serial", qdev_serial_create);
>>> }
>>>
>>> The key point is that when we create devices internally, we should have a
>>> C-friendly, type-safe interface to interact with.  This will encourage
>>> composition and a richer device model than what we have today.
>>>
>>
>> Isn't this what we have now in most cases?
>>
>
> No.  The common pattern of shallow conversion is:
>
> struct SerialState
> {
>    // device state
> };
>
> struct ISASerialState
> {
>   ISADeviceState parent;
>   SerialState serial;
> };
>
> void serial_init(SerialState *s);
>
> void isa_serial_init(ISADevice *dev)
> {
>    ISASerialState *s = DO_UPCAST(dev);
>    serial_init(&s->serial);
> }
>
> The problem with this is that you cannot use serial_init() if you want to
> have the device be reflected in the device tree.

But why would serial_init() be used anymore since isa_serial_init() is as good?

> GObject takes a different approach than I'm suggesting that is equally
> valid.  It supports a vararg constructor form and then provides C-friendly
> interfaces that use the vararg form.  For instance:
>
> SerialState *serial_init(int iobase, int irq, ...)
> {
>     return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
> NULL);
> }
>
> This is not a bad solution but what I was trying to avoid in my suggestion
> is a lot of the ugliness of supporting a factory initializer.  It may be a
> better approach in the long run though.

Producing varargs lists may get messy if the list is filled
differently based on some conditions. It's also not easy to do things
in between:
dev = isa_create();
qdev_prop_set_uint32(dev);
if (flag1) {
  qdev_prop_set_uint32(dev);
}
if (flag2) {
  int f = func();
  qdev_prop_set_uint32(dev, f);
}
qdev_prop_set_uint32(dev);
qdev_init_nofail(dev);

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 03:00 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>      
>>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>   wrote:
>>>
>>>        
>>>> qdev doesn't expose any state today.  qdev properties are
>>>> construction-only
>>>> properties that happen to be stored in each device state.
>>>>
>>>> What we really need is a full property framework that includes properties
>>>> with hookable getters and setters along with the ability to mark
>>>> properties
>>>> as construct-only, read-only, or read-write.
>>>>
>>>> But I think it's reasonable to expose construct-only properties as just
>>>> an
>>>> initfn argument.
>>>>
>>>>          
>>> Sounds OK. About read-write properties, what happens if we one day
>>> have extensive threading, and locks are pushed to device level? I can
>>> imagine a deadlock involving one thread running in IO thread for a
>>> device and another trying to access that device's properties. Maybe
>>> that is not different from function call version.
>>>
>>>        
>> You need hookable setters/getters that can acquire a lock and do the right
>> thing.  It shouldn't be able to dead lock if the locking is designed right.
>>
>>
>>      
>>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>>> information and doesn't really have a mechanism to attach/detach in any
>>>> generic way.
>>>>
>>>>          
>>> Basic signals are already very useful for many purposes, since they
>>> match digital logic signals in real HW. In theory, whole machines
>>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>>
>>>        
>> It's not just in theory.  In the C++ port of QEMU that I wrote, I
>> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
>> just using a device config file.
>>
>> If done correctly, using referencing can be extremely powerful.  A full
>> adder is a good example.  The gates really don't have any concept of bus and
>> the relationship between gates is definitely not a tree.
>>
>>      
>>> In the message passing IRQ discussion earlier, it was IIRC decided
>>> that the one bit version would not be changed but a separate message
>>> passing version would be created if ever needed.
>>>
>>>        
>> C already has a message passing interface that supports type safety called
>> function pointers :-)
>>
>> An object that implements multiple interfaces where the interface becomes
>> the "message passing interface" is exactly what I've been saying we need.
>>   It's flexible and the compiler helps us enforce typing.
>>
>>      
>>>> Any interfaces of a base class should make sense even for derived
>>>> classes.
>>>>
>>>> That means if the base class is going to expose essentially a pin-out
>>>> interface, that if I have a PCIDevice and cast it to Device, I should be
>>>> able to interact with the GPIO interface to interact with the PCI device.
>>>>   Presumably, that means interfacing at the PCI signalling level.  That's
>>>> insane to model in QEMU :-)
>>>>
>>>>          
>>> This would be doable, if we built buses from a bunch of signals, like
>>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>>> the undecoded address pins would be ignored. I don't think it would be
>>> useful, but a separate interface could be added for connecting to
>>> PCIBus with just qemu_irqs.
>>>
>>>        
>> Yeah, it's possible, but I don't want to spend my time doing this.
>>
>>      
>>>> In reality, GPIO only makes sense for a small class of simple devices
>>>> where
>>>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>>>> suggests that GPIO should not be in the DeviceState interface but instead
>>>> should be in a SimpleDevice subclass or something like that.
>>>>
>>>>
>>>>          
>>>>> Could you point to examples of SystemBus overuse?
>>>>>
>>>>>
>>>>>            
>>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>>> 73
>>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>>> 56
>>>>
>>>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>>
>>>>          
>>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>>> useful to get bootindex corrected. Most devices (even on-board IO)
>>> should use SBus.
>>>
>>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>>
>>> But SysBus fitted the need until recently.
>>>
>>>        
>> A good way to judge where a device is using a bus interface correct: does
>> all of it's interactions with any other part of the guest state involve
>> method calls to the bus?
>>
>> Right now, the answer is no for just about every device in QEMU.  This is
>> the problem that qdev really was meant to solve and we're not really any
>> further along solving it unfortunately.
>>
>>      
>>>> I'm not arguing against a generic factory interface, I'm arguing that it
>>>> should be separate.
>>>>
>>>> IOW:
>>>>
>>>> SerialState *serial_create(int iobase, int irq, ...);
>>>>
>>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>>
>>>> static void serial_init(void)
>>>> {
>>>>      qdev_register("serial", qdev_serial_create);
>>>> }
>>>>
>>>> The key point is that when we create devices internally, we should have a
>>>> C-friendly, type-safe interface to interact with.  This will encourage
>>>> composition and a richer device model than what we have today.
>>>>
>>>>          
>>> Isn't this what we have now in most cases?
>>>
>>>        
>> No.  The common pattern of shallow conversion is:
>>
>> struct SerialState
>> {
>>     // device state
>> };
>>
>> struct ISASerialState
>> {
>>    ISADeviceState parent;
>>    SerialState serial;
>> };
>>
>> void serial_init(SerialState *s);
>>
>> void isa_serial_init(ISADevice *dev)
>> {
>>     ISASerialState *s = DO_UPCAST(dev);
>>     serial_init(&s->serial);
>> }
>>
>> The problem with this is that you cannot use serial_init() if you want to
>> have the device be reflected in the device tree.
>>      
> But why would serial_init() be used anymore since isa_serial_init() is as good?
>    

The point is that it's not.

Instead of doing error checking in one call, you've gotta do error 
checking in a half dozen calls because each of the set calls can fail.

>> GObject takes a different approach than I'm suggesting that is equally
>> valid.  It supports a vararg constructor form and then provides C-friendly
>> interfaces that use the vararg form.  For instance:
>>
>> SerialState *serial_init(int iobase, int irq, ...)
>> {
>>      return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
>> NULL);
>> }
>>
>> This is not a bad solution but what I was trying to avoid in my suggestion
>> is a lot of the ugliness of supporting a factory initializer.  It may be a
>> better approach in the long run though.
>>      
> Producing varargs lists may get messy if the list is filled
> differently based on some conditions. It's also not easy to do things
> in between:
> dev = isa_create();
> qdev_prop_set_uint32(dev);
> if (flag1) {
>    qdev_prop_set_uint32(dev);
> }
> if (flag2) {
>    int f = func();
>    qdev_prop_set_uint32(dev, f);
> }
> qdev_prop_set_uint32(dev);
> qdev_init_nofail(dev);
>    

Vararg is designed for direct invocation.  You can still build a list of 
construction properties if you're so inclined.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 03:00 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>      
>>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>   wrote:
>>>
>>>        
>>>> qdev doesn't expose any state today.  qdev properties are
>>>> construction-only
>>>> properties that happen to be stored in each device state.
>>>>
>>>> What we really need is a full property framework that includes properties
>>>> with hookable getters and setters along with the ability to mark
>>>> properties
>>>> as construct-only, read-only, or read-write.
>>>>
>>>> But I think it's reasonable to expose construct-only properties as just
>>>> an
>>>> initfn argument.
>>>>
>>>>          
>>> Sounds OK. About read-write properties, what happens if we one day
>>> have extensive threading, and locks are pushed to device level? I can
>>> imagine a deadlock involving one thread running in IO thread for a
>>> device and another trying to access that device's properties. Maybe
>>> that is not different from function call version.
>>>
>>>        
>> You need hookable setters/getters that can acquire a lock and do the right
>> thing.  It shouldn't be able to dead lock if the locking is designed right.
>>
>>
>>      
>>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>>> information and doesn't really have a mechanism to attach/detach in any
>>>> generic way.
>>>>
>>>>          
>>> Basic signals are already very useful for many purposes, since they
>>> match digital logic signals in real HW. In theory, whole machines
>>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>>
>>>        
>> It's not just in theory.  In the C++ port of QEMU that I wrote, I
>> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
>> just using a device config file.
>>
>> If done correctly, using referencing can be extremely powerful.  A full
>> adder is a good example.  The gates really don't have any concept of bus and
>> the relationship between gates is definitely not a tree.
>>
>>      
>>> In the message passing IRQ discussion earlier, it was IIRC decided
>>> that the one bit version would not be changed but a separate message
>>> passing version would be created if ever needed.
>>>
>>>        
>> C already has a message passing interface that supports type safety called
>> function pointers :-)
>>
>> An object that implements multiple interfaces where the interface becomes
>> the "message passing interface" is exactly what I've been saying we need.
>>   It's flexible and the compiler helps us enforce typing.
>>
>>      
>>>> Any interfaces of a base class should make sense even for derived
>>>> classes.
>>>>
>>>> That means if the base class is going to expose essentially a pin-out
>>>> interface, that if I have a PCIDevice and cast it to Device, I should be
>>>> able to interact with the GPIO interface to interact with the PCI device.
>>>>   Presumably, that means interfacing at the PCI signalling level.  That's
>>>> insane to model in QEMU :-)
>>>>
>>>>          
>>> This would be doable, if we built buses from a bunch of signals, like
>>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>>> the undecoded address pins would be ignored. I don't think it would be
>>> useful, but a separate interface could be added for connecting to
>>> PCIBus with just qemu_irqs.
>>>
>>>        
>> Yeah, it's possible, but I don't want to spend my time doing this.
>>
>>      
>>>> In reality, GPIO only makes sense for a small class of simple devices
>>>> where
>>>> modelling the pin-out interface makes sense (like a 7-segment LCD).  That
>>>> suggests that GPIO should not be in the DeviceState interface but instead
>>>> should be in a SimpleDevice subclass or something like that.
>>>>
>>>>
>>>>          
>>>>> Could you point to examples of SystemBus overuse?
>>>>>
>>>>>
>>>>>            
>>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>>> 73
>>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>>> 56
>>>>
>>>> SystemBus has become a catch-all for shallow qdev conversions.  We've got
>>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>>
>>>>          
>>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>>> useful to get bootindex corrected. Most devices (even on-board IO)
>>> should use SBus.
>>>
>>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>>
>>> But SysBus fitted the need until recently.
>>>
>>>        
>> A good way to judge where a device is using a bus interface correct: does
>> all of it's interactions with any other part of the guest state involve
>> method calls to the bus?
>>
>> Right now, the answer is no for just about every device in QEMU.  This is
>> the problem that qdev really was meant to solve and we're not really any
>> further along solving it unfortunately.
>>
>>      
>>>> I'm not arguing against a generic factory interface, I'm arguing that it
>>>> should be separate.
>>>>
>>>> IOW:
>>>>
>>>> SerialState *serial_create(int iobase, int irq, ...);
>>>>
>>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>>
>>>> static void serial_init(void)
>>>> {
>>>>      qdev_register("serial", qdev_serial_create);
>>>> }
>>>>
>>>> The key point is that when we create devices internally, we should have a
>>>> C-friendly, type-safe interface to interact with.  This will encourage
>>>> composition and a richer device model than what we have today.
>>>>
>>>>          
>>> Isn't this what we have now in most cases?
>>>
>>>        
>> No.  The common pattern of shallow conversion is:
>>
>> struct SerialState
>> {
>>     // device state
>> };
>>
>> struct ISASerialState
>> {
>>    ISADeviceState parent;
>>    SerialState serial;
>> };
>>
>> void serial_init(SerialState *s);
>>
>> void isa_serial_init(ISADevice *dev)
>> {
>>     ISASerialState *s = DO_UPCAST(dev);
>>     serial_init(&s->serial);
>> }
>>
>> The problem with this is that you cannot use serial_init() if you want to
>> have the device be reflected in the device tree.
>>      
> But why would serial_init() be used anymore since isa_serial_init() is as good?
>    

The point is that it's not.

Instead of doing error checking in one call, you've gotta do error 
checking in a half dozen calls because each of the set calls can fail.

>> GObject takes a different approach than I'm suggesting that is equally
>> valid.  It supports a vararg constructor form and then provides C-friendly
>> interfaces that use the vararg form.  For instance:
>>
>> SerialState *serial_init(int iobase, int irq, ...)
>> {
>>      return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
>> NULL);
>> }
>>
>> This is not a bad solution but what I was trying to avoid in my suggestion
>> is a lot of the ugliness of supporting a factory initializer.  It may be a
>> better approach in the long run though.
>>      
> Producing varargs lists may get messy if the list is filled
> differently based on some conditions. It's also not easy to do things
> in between:
> dev = isa_create();
> qdev_prop_set_uint32(dev);
> if (flag1) {
>    qdev_prop_set_uint32(dev);
> }
> if (flag2) {
>    int f = func();
>    qdev_prop_set_uint32(dev, f);
> }
> qdev_prop_set_uint32(dev);
> qdev_init_nofail(dev);
>    

Vararg is designed for direct invocation.  You can still build a list of 
construction properties if you're so inclined.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 12:42 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/13/2011 03:00 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>>
>>>>
>>>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> qdev doesn't expose any state today.  qdev properties are
>>>>> construction-only
>>>>> properties that happen to be stored in each device state.
>>>>>
>>>>> What we really need is a full property framework that includes
>>>>> properties
>>>>> with hookable getters and setters along with the ability to mark
>>>>> properties
>>>>> as construct-only, read-only, or read-write.
>>>>>
>>>>> But I think it's reasonable to expose construct-only properties as just
>>>>> an
>>>>> initfn argument.
>>>>>
>>>>>
>>>>
>>>> Sounds OK. About read-write properties, what happens if we one day
>>>> have extensive threading, and locks are pushed to device level? I can
>>>> imagine a deadlock involving one thread running in IO thread for a
>>>> device and another trying to access that device's properties. Maybe
>>>> that is not different from function call version.
>>>>
>>>>
>>>
>>> You need hookable setters/getters that can acquire a lock and do the
>>> right
>>> thing.  It shouldn't be able to dead lock if the locking is designed
>>> right.
>>>
>>>
>>>
>>>>>
>>>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>>>> information and doesn't really have a mechanism to attach/detach in any
>>>>> generic way.
>>>>>
>>>>>
>>>>
>>>> Basic signals are already very useful for many purposes, since they
>>>> match digital logic signals in real HW. In theory, whole machines
>>>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>>>
>>>>
>>>
>>> It's not just in theory.  In the C++ port of QEMU that I wrote, I
>>> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder
>>> by
>>> just using a device config file.
>>>
>>> If done correctly, using referencing can be extremely powerful.  A full
>>> adder is a good example.  The gates really don't have any concept of bus
>>> and
>>> the relationship between gates is definitely not a tree.
>>>
>>>
>>>>
>>>> In the message passing IRQ discussion earlier, it was IIRC decided
>>>> that the one bit version would not be changed but a separate message
>>>> passing version would be created if ever needed.
>>>>
>>>>
>>>
>>> C already has a message passing interface that supports type safety
>>> called
>>> function pointers :-)
>>>
>>> An object that implements multiple interfaces where the interface becomes
>>> the "message passing interface" is exactly what I've been saying we need.
>>>  It's flexible and the compiler helps us enforce typing.
>>>
>>>
>>>>>
>>>>> Any interfaces of a base class should make sense even for derived
>>>>> classes.
>>>>>
>>>>> That means if the base class is going to expose essentially a pin-out
>>>>> interface, that if I have a PCIDevice and cast it to Device, I should
>>>>> be
>>>>> able to interact with the GPIO interface to interact with the PCI
>>>>> device.
>>>>>  Presumably, that means interfacing at the PCI signalling level.
>>>>>  That's
>>>>> insane to model in QEMU :-)
>>>>>
>>>>>
>>>>
>>>> This would be doable, if we built buses from a bunch of signals, like
>>>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>>>> the undecoded address pins would be ignored. I don't think it would be
>>>> useful, but a separate interface could be added for connecting to
>>>> PCIBus with just qemu_irqs.
>>>>
>>>>
>>>
>>> Yeah, it's possible, but I don't want to spend my time doing this.
>>>
>>>
>>>>>
>>>>> In reality, GPIO only makes sense for a small class of simple devices
>>>>> where
>>>>> modelling the pin-out interface makes sense (like a 7-segment LCD).
>>>>>  That
>>>>> suggests that GPIO should not be in the DeviceState interface but
>>>>> instead
>>>>> should be in a SimpleDevice subclass or something like that.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Could you point to examples of SystemBus overuse?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>>>> 73
>>>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>>>> 56
>>>>>
>>>>> SystemBus has become a catch-all for shallow qdev conversions.  We've
>>>>> got
>>>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>>>
>>>>>
>>>>
>>>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>>>> useful to get bootindex corrected. Most devices (even on-board IO)
>>>> should use SBus.
>>>>
>>>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>>>
>>>> But SysBus fitted the need until recently.
>>>>
>>>>
>>>
>>> A good way to judge where a device is using a bus interface correct: does
>>> all of it's interactions with any other part of the guest state involve
>>> method calls to the bus?
>>>
>>> Right now, the answer is no for just about every device in QEMU.  This is
>>> the problem that qdev really was meant to solve and we're not really any
>>> further along solving it unfortunately.
>>>
>>>
>>>>>
>>>>> I'm not arguing against a generic factory interface, I'm arguing that
>>>>> it
>>>>> should be separate.
>>>>>
>>>>> IOW:
>>>>>
>>>>> SerialState *serial_create(int iobase, int irq, ...);
>>>>>
>>>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>>>
>>>>> static void serial_init(void)
>>>>> {
>>>>>     qdev_register("serial", qdev_serial_create);
>>>>> }
>>>>>
>>>>> The key point is that when we create devices internally, we should have
>>>>> a
>>>>> C-friendly, type-safe interface to interact with.  This will encourage
>>>>> composition and a richer device model than what we have today.
>>>>>
>>>>>
>>>>
>>>> Isn't this what we have now in most cases?
>>>>
>>>>
>>>
>>> No.  The common pattern of shallow conversion is:
>>>
>>> struct SerialState
>>> {
>>>    // device state
>>> };
>>>
>>> struct ISASerialState
>>> {
>>>   ISADeviceState parent;
>>>   SerialState serial;
>>> };
>>>
>>> void serial_init(SerialState *s);
>>>
>>> void isa_serial_init(ISADevice *dev)
>>> {
>>>    ISASerialState *s = DO_UPCAST(dev);
>>>    serial_init(&s->serial);
>>> }
>>>
>>> The problem with this is that you cannot use serial_init() if you want to
>>> have the device be reflected in the device tree.
>>>
>>
>> But why would serial_init() be used anymore since isa_serial_init() is as
>> good?
>>
>
> The point is that it's not.
>
> Instead of doing error checking in one call, you've gotta do error checking
> in a half dozen calls because each of the set calls can fail.

I don't understand. The caller just does
if (isa_serial_init()) {
  error();
}
or
if (serial_init()) {
  error();
}

If you mean inside isa_serial_init() vs. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the to
the caller both should be identical.

>>> GObject takes a different approach than I'm suggesting that is equally
>>> valid.  It supports a vararg constructor form and then provides
>>> C-friendly
>>> interfaces that use the vararg form.  For instance:
>>>
>>> SerialState *serial_init(int iobase, int irq, ...)
>>> {
>>>     return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
>>> NULL);
>>> }
>>>
>>> This is not a bad solution but what I was trying to avoid in my
>>> suggestion
>>> is a lot of the ugliness of supporting a factory initializer.  It may be
>>> a
>>> better approach in the long run though.
>>>
>>
>> Producing varargs lists may get messy if the list is filled
>> differently based on some conditions. It's also not easy to do things
>> in between:
>> dev = isa_create();
>> qdev_prop_set_uint32(dev);
>> if (flag1) {
>>   qdev_prop_set_uint32(dev);
>> }
>> if (flag2) {
>>   int f = func();
>>   qdev_prop_set_uint32(dev, f);
>> }
>> qdev_prop_set_uint32(dev);
>> qdev_init_nofail(dev);
>>
>
> Vararg is designed for direct invocation.  You can still build a list of
> construction properties if you're so inclined.
>
> Regards,
>
> Anthony Liguori
>
>
>

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 12:42 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/13/2011 03:00 PM, Blue Swirl wrote:
>>
>> On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 02/13/2011 01:37 PM, Blue Swirl wrote:
>>>
>>>>
>>>> On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> qdev doesn't expose any state today.  qdev properties are
>>>>> construction-only
>>>>> properties that happen to be stored in each device state.
>>>>>
>>>>> What we really need is a full property framework that includes
>>>>> properties
>>>>> with hookable getters and setters along with the ability to mark
>>>>> properties
>>>>> as construct-only, read-only, or read-write.
>>>>>
>>>>> But I think it's reasonable to expose construct-only properties as just
>>>>> an
>>>>> initfn argument.
>>>>>
>>>>>
>>>>
>>>> Sounds OK. About read-write properties, what happens if we one day
>>>> have extensive threading, and locks are pushed to device level? I can
>>>> imagine a deadlock involving one thread running in IO thread for a
>>>> device and another trying to access that device's properties. Maybe
>>>> that is not different from function call version.
>>>>
>>>>
>>>
>>> You need hookable setters/getters that can acquire a lock and do the
>>> right
>>> thing.  It shouldn't be able to dead lock if the locking is designed
>>> right.
>>>
>>>
>>>
>>>>>
>>>>> Yes, but qemu_irq is very restricted as it only models a signal bit of
>>>>> information and doesn't really have a mechanism to attach/detach in any
>>>>> generic way.
>>>>>
>>>>>
>>>>
>>>> Basic signals are already very useful for many purposes, since they
>>>> match digital logic signals in real HW. In theory, whole machines
>>>> could be constructed with just qemu_irq and NAND gate emulator. ;-)
>>>>
>>>>
>>>
>>> It's not just in theory.  In the C++ port of QEMU that I wrote, I
>>> implemented an AND, OR, and XOR gate and implemented a full 32-bit adder
>>> by
>>> just using a device config file.
>>>
>>> If done correctly, using referencing can be extremely powerful.  A full
>>> adder is a good example.  The gates really don't have any concept of bus
>>> and
>>> the relationship between gates is definitely not a tree.
>>>
>>>
>>>>
>>>> In the message passing IRQ discussion earlier, it was IIRC decided
>>>> that the one bit version would not be changed but a separate message
>>>> passing version would be created if ever needed.
>>>>
>>>>
>>>
>>> C already has a message passing interface that supports type safety
>>> called
>>> function pointers :-)
>>>
>>> An object that implements multiple interfaces where the interface becomes
>>> the "message passing interface" is exactly what I've been saying we need.
>>>  It's flexible and the compiler helps us enforce typing.
>>>
>>>
>>>>>
>>>>> Any interfaces of a base class should make sense even for derived
>>>>> classes.
>>>>>
>>>>> That means if the base class is going to expose essentially a pin-out
>>>>> interface, that if I have a PCIDevice and cast it to Device, I should
>>>>> be
>>>>> able to interact with the GPIO interface to interact with the PCI
>>>>> device.
>>>>>  Presumably, that means interfacing at the PCI signalling level.
>>>>>  That's
>>>>> insane to model in QEMU :-)
>>>>>
>>>>>
>>>>
>>>> This would be doable, if we built buses from a bunch of signals, like
>>>> in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
>>>> the undecoded address pins would be ignored. I don't think it would be
>>>> useful, but a separate interface could be added for connecting to
>>>> PCIBus with just qemu_irqs.
>>>>
>>>>
>>>
>>> Yeah, it's possible, but I don't want to spend my time doing this.
>>>
>>>
>>>>>
>>>>> In reality, GPIO only makes sense for a small class of simple devices
>>>>> where
>>>>> modelling the pin-out interface makes sense (like a 7-segment LCD).
>>>>>  That
>>>>> suggests that GPIO should not be in the DeviceState interface but
>>>>> instead
>>>>> should be in a SimpleDevice subclass or something like that.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Could you point to examples of SystemBus overuse?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
>>>>> 73
>>>>> anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
>>>>> 56
>>>>>
>>>>> SystemBus has become a catch-all for shallow qdev conversions.  We've
>>>>> got
>>>>> Northbridges, RAM, and network devices sitting on the same bus...
>>>>>
>>>>>
>>>>
>>>> On Sparc32 I have not bothered to create a SBus bus. Now it would be
>>>> useful to get bootindex corrected. Most devices (even on-board IO)
>>>> should use SBus.
>>>>
>>>> The only other bus (MBus) would exist between CPU, IOMMU and memory.
>>>>
>>>> But SysBus fitted the need until recently.
>>>>
>>>>
>>>
>>> A good way to judge where a device is using a bus interface correct: does
>>> all of it's interactions with any other part of the guest state involve
>>> method calls to the bus?
>>>
>>> Right now, the answer is no for just about every device in QEMU.  This is
>>> the problem that qdev really was meant to solve and we're not really any
>>> further along solving it unfortunately.
>>>
>>>
>>>>>
>>>>> I'm not arguing against a generic factory interface, I'm arguing that
>>>>> it
>>>>> should be separate.
>>>>>
>>>>> IOW:
>>>>>
>>>>> SerialState *serial_create(int iobase, int irq, ...);
>>>>>
>>>>> static DeviceState *qdev_serial_create(QemuOpts *opts);
>>>>>
>>>>> static void serial_init(void)
>>>>> {
>>>>>     qdev_register("serial", qdev_serial_create);
>>>>> }
>>>>>
>>>>> The key point is that when we create devices internally, we should have
>>>>> a
>>>>> C-friendly, type-safe interface to interact with.  This will encourage
>>>>> composition and a richer device model than what we have today.
>>>>>
>>>>>
>>>>
>>>> Isn't this what we have now in most cases?
>>>>
>>>>
>>>
>>> No.  The common pattern of shallow conversion is:
>>>
>>> struct SerialState
>>> {
>>>    // device state
>>> };
>>>
>>> struct ISASerialState
>>> {
>>>   ISADeviceState parent;
>>>   SerialState serial;
>>> };
>>>
>>> void serial_init(SerialState *s);
>>>
>>> void isa_serial_init(ISADevice *dev)
>>> {
>>>    ISASerialState *s = DO_UPCAST(dev);
>>>    serial_init(&s->serial);
>>> }
>>>
>>> The problem with this is that you cannot use serial_init() if you want to
>>> have the device be reflected in the device tree.
>>>
>>
>> But why would serial_init() be used anymore since isa_serial_init() is as
>> good?
>>
>
> The point is that it's not.
>
> Instead of doing error checking in one call, you've gotta do error checking
> in a half dozen calls because each of the set calls can fail.

I don't understand. The caller just does
if (isa_serial_init()) {
  error();
}
or
if (serial_init()) {
  error();
}

If you mean inside isa_serial_init() vs. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the to
the caller both should be identical.

>>> GObject takes a different approach than I'm suggesting that is equally
>>> valid.  It supports a vararg constructor form and then provides
>>> C-friendly
>>> interfaces that use the vararg form.  For instance:
>>>
>>> SerialState *serial_init(int iobase, int irq, ...)
>>> {
>>>     return gobject_new(QEMU_SERIAL, "iobase", iobase, "irq", irq, ...,
>>> NULL);
>>> }
>>>
>>> This is not a bad solution but what I was trying to avoid in my
>>> suggestion
>>> is a lot of the ugliness of supporting a factory initializer.  It may be
>>> a
>>> better approach in the long run though.
>>>
>>
>> Producing varargs lists may get messy if the list is filled
>> differently based on some conditions. It's also not easy to do things
>> in between:
>> dev = isa_create();
>> qdev_prop_set_uint32(dev);
>> if (flag1) {
>>   qdev_prop_set_uint32(dev);
>> }
>> if (flag2) {
>>   int f = func();
>>   qdev_prop_set_uint32(dev, f);
>> }
>> qdev_prop_set_uint32(dev);
>> qdev_init_nofail(dev);
>>
>
> Vararg is designed for direct invocation.  You can still build a list of
> construction properties if you're so inclined.
>
> Regards,
>
> Anthony Liguori
>
>
>

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/14/2011 11:31 AM, Blue Swirl wrote:
> I don't understand. The caller just does
> if (isa_serial_init()) {
>    error();
> }
> or
> if (serial_init()) {
>    error();
> }
>
> If you mean inside isa_serial_init() vs. serial_init(), that may be
> true since isa_serial_init has to check for qdev failures, but the to
> the caller both should be identical.
>    

The problem with qdev is there's too much boiler plate code which makes 
it hard to give examples :-)  Here's precisely what I'm talking about:

static int serial_isa_initfn(ISADevice *dev)
{
     static int index;
     ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
     SerialState *s = &isa->state;

     if (isa->index == -1)
         isa->index = index;
     if (isa->index >= MAX_SERIAL_PORTS)
         return -1;
     if (isa->iobase == -1)
         isa->iobase = isa_serial_io[isa->index];
     if (isa->isairq == -1)
         isa->isairq = isa_serial_irq[isa->index];
     index++;

     s->baudbase = 115200;
     isa_init_irq(dev, &s->irq, isa->isairq);
     serial_init_core(s);
     qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);

     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
     isa_init_ioport_range(dev, isa->iobase, 8);
     return 0;
}

SerialState *serial_init(int base, qemu_irq irq, int baudbase,
                          CharDriverState *chr)
{
     SerialState *s;

     s = qemu_mallocz(sizeof(SerialState));

     s->irq = irq;
     s->baudbase = baudbase;
     s->chr = chr;
     serial_init_core(s);

     vmstate_register(NULL, base, &vmstate_serial, s);

     register_ioport_write(base, 8, 1, serial_ioport_write, s);
     register_ioport_read(base, 8, 1, serial_ioport_read, s);
     return s;
}

static ISADeviceInfo serial_isa_info = {
     .qdev.name  = "isa-serial",
     .qdev.size  = sizeof(ISASerialState),
     .qdev.vmsd  = &vmstate_isa_serial,
     .init       = serial_isa_initfn,
     .qdev.props = (Property[]) {
         DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
         DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
         DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
         DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
         DEFINE_PROP_END_OF_LIST(),
     },
};

static void serial_register_devices(void)
{
     isa_qdev_register(&serial_isa_info);
}

device_init(serial_register_devices)


To create a device, I need to do:

{
      ISADevice *dev;

      dev = isa_create("isa-serial");
      if (dev == NULL) {
           return error;
      }
      if (qdev_set_uint32(&dev->qdev, "index", index)) {
           goto err;
      }
      if (qdev_set_uint32(&dev->qdev, "iobase", iobase)) {
           goto err;
      }
      if (qdev_set_uint32(&dev->qdev, "irq", irq)) {
          goto err;
      }
      if (qdev_set_chr(&dev->qdev, "chardev", chr)) {
          goto err;
      }
      if (qdev_init(&dev->qdev)) {
          goto err;
      }
      return 0;
err:
      qdev_destroy(&dev->qdev);
      return -1;
}

This is simply not a reasonable API to use to create devices.  There are 
two ways we can make this more managable.  The first is gobject-style 
vararg constructor coupled with a type safe wrapper.  So...

ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase, 
uint32_t irq, CharDriverState *chr)
{
       return isa_device_create_va("isa-seral", "index", index, 
"iobase", iobase, "irq", irq, "chardev", chr, NULL);
}

Now this can be used in a reasonable fashion.  However, we can do even 
better if we change the way qdev is done.   Consider the following:

SerialState *serial_init(int base, qemu_irq irq, int baudbase,
                          CharDriverState *chr)
{
     SerialState *s;

     s = qemu_mallocz(sizeof(SerialState));

     s->irq = irq;
     s->baudbase = baudbase;
     s->chr = chr;
     serial_init_core(s);

     vmstate_register(NULL, base, &vmstate_serial, s);

     register_ioport_write(base, 8, 1, serial_ioport_write, s);
     register_ioport_read(base, 8, 1, serial_ioport_read, s);
     return s;
}

ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase, 
uint32_t irq, CharDriverState *chr)
{
     static int index;
     ISADevice *dev = isa_create("isa-serial");
     ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
     SerialState *s = &isa->state;

     if (index == -1)
         index = index;
     if (index >= MAX_SERIAL_PORTS)
         return NULL;
     if (iobase == -1)
         iobase = isa_serial_io[index];
     if (isairq == -1)
         isairq = isa_serial_irq[index];
     index++;

     s->baudbase = 115200;
     isa_init_irq(dev, &s->irq, isairq);
     serial_init_core(s);
     qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);

     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
     isa_init_ioport_range(dev, isa->iobase, 8);
     return isa;
}

static ISADevice *isa_seral_init_qdev(QemuOpts *opts)
{
       uint32_t index = qemu_opt_get_uint32(opts, "index", -1);
       uint32_t irq = qemu_opt_get_uint32(opts, "irq", -1);
       uint32_t iobase = qemu_opt_get_uint32(opts, "iobase", -1);
       CharDriverState *chr = qemu_opt_get_chr(opts, "chardev");

       return isa_serial_new(index, irq, iobase, chr);
}

static void serial_register_devices(void)
{
     isa_qdev_register("isa-serial", isa_serial_init_qdev);
}

device_init(serial_register_devices)

The advantage of this model is that we can totally ignore the factory 
interface for devices that we don't care about exposing to the user.  So 
the isa_seral_init_qdev part is totally optional.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/14/2011 11:31 AM, Blue Swirl wrote:
> I don't understand. The caller just does
> if (isa_serial_init()) {
>    error();
> }
> or
> if (serial_init()) {
>    error();
> }
>
> If you mean inside isa_serial_init() vs. serial_init(), that may be
> true since isa_serial_init has to check for qdev failures, but the to
> the caller both should be identical.
>    

The problem with qdev is there's too much boiler plate code which makes 
it hard to give examples :-)  Here's precisely what I'm talking about:

static int serial_isa_initfn(ISADevice *dev)
{
     static int index;
     ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
     SerialState *s = &isa->state;

     if (isa->index == -1)
         isa->index = index;
     if (isa->index >= MAX_SERIAL_PORTS)
         return -1;
     if (isa->iobase == -1)
         isa->iobase = isa_serial_io[isa->index];
     if (isa->isairq == -1)
         isa->isairq = isa_serial_irq[isa->index];
     index++;

     s->baudbase = 115200;
     isa_init_irq(dev, &s->irq, isa->isairq);
     serial_init_core(s);
     qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);

     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
     isa_init_ioport_range(dev, isa->iobase, 8);
     return 0;
}

SerialState *serial_init(int base, qemu_irq irq, int baudbase,
                          CharDriverState *chr)
{
     SerialState *s;

     s = qemu_mallocz(sizeof(SerialState));

     s->irq = irq;
     s->baudbase = baudbase;
     s->chr = chr;
     serial_init_core(s);

     vmstate_register(NULL, base, &vmstate_serial, s);

     register_ioport_write(base, 8, 1, serial_ioport_write, s);
     register_ioport_read(base, 8, 1, serial_ioport_read, s);
     return s;
}

static ISADeviceInfo serial_isa_info = {
     .qdev.name  = "isa-serial",
     .qdev.size  = sizeof(ISASerialState),
     .qdev.vmsd  = &vmstate_isa_serial,
     .init       = serial_isa_initfn,
     .qdev.props = (Property[]) {
         DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
         DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
         DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
         DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
         DEFINE_PROP_END_OF_LIST(),
     },
};

static void serial_register_devices(void)
{
     isa_qdev_register(&serial_isa_info);
}

device_init(serial_register_devices)


To create a device, I need to do:

{
      ISADevice *dev;

      dev = isa_create("isa-serial");
      if (dev == NULL) {
           return error;
      }
      if (qdev_set_uint32(&dev->qdev, "index", index)) {
           goto err;
      }
      if (qdev_set_uint32(&dev->qdev, "iobase", iobase)) {
           goto err;
      }
      if (qdev_set_uint32(&dev->qdev, "irq", irq)) {
          goto err;
      }
      if (qdev_set_chr(&dev->qdev, "chardev", chr)) {
          goto err;
      }
      if (qdev_init(&dev->qdev)) {
          goto err;
      }
      return 0;
err:
      qdev_destroy(&dev->qdev);
      return -1;
}

This is simply not a reasonable API to use to create devices.  There are 
two ways we can make this more managable.  The first is gobject-style 
vararg constructor coupled with a type safe wrapper.  So...

ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase, 
uint32_t irq, CharDriverState *chr)
{
       return isa_device_create_va("isa-seral", "index", index, 
"iobase", iobase, "irq", irq, "chardev", chr, NULL);
}

Now this can be used in a reasonable fashion.  However, we can do even 
better if we change the way qdev is done.   Consider the following:

SerialState *serial_init(int base, qemu_irq irq, int baudbase,
                          CharDriverState *chr)
{
     SerialState *s;

     s = qemu_mallocz(sizeof(SerialState));

     s->irq = irq;
     s->baudbase = baudbase;
     s->chr = chr;
     serial_init_core(s);

     vmstate_register(NULL, base, &vmstate_serial, s);

     register_ioport_write(base, 8, 1, serial_ioport_write, s);
     register_ioport_read(base, 8, 1, serial_ioport_read, s);
     return s;
}

ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase, 
uint32_t irq, CharDriverState *chr)
{
     static int index;
     ISADevice *dev = isa_create("isa-serial");
     ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
     SerialState *s = &isa->state;

     if (index == -1)
         index = index;
     if (index >= MAX_SERIAL_PORTS)
         return NULL;
     if (iobase == -1)
         iobase = isa_serial_io[index];
     if (isairq == -1)
         isairq = isa_serial_irq[index];
     index++;

     s->baudbase = 115200;
     isa_init_irq(dev, &s->irq, isairq);
     serial_init_core(s);
     qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);

     register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
     register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
     isa_init_ioport_range(dev, isa->iobase, 8);
     return isa;
}

static ISADevice *isa_seral_init_qdev(QemuOpts *opts)
{
       uint32_t index = qemu_opt_get_uint32(opts, "index", -1);
       uint32_t irq = qemu_opt_get_uint32(opts, "irq", -1);
       uint32_t iobase = qemu_opt_get_uint32(opts, "iobase", -1);
       CharDriverState *chr = qemu_opt_get_chr(opts, "chardev");

       return isa_serial_new(index, irq, iobase, chr);
}

static void serial_register_devices(void)
{
     isa_qdev_register("isa-serial", isa_serial_init_qdev);
}

device_init(serial_register_devices)

The advantage of this model is that we can totally ignore the factory 
interface for devices that we don't care about exposing to the user.  So 
the isa_seral_init_qdev part is totally optional.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 10:53 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/14/2011 11:31 AM, Blue Swirl wrote:
>>
>> I don't understand. The caller just does
>> if (isa_serial_init()) {
>>   error();
>> }
>> or
>> if (serial_init()) {
>>   error();
>> }
>>
>> If you mean inside isa_serial_init() vs. serial_init(), that may be
>> true since isa_serial_init has to check for qdev failures, but the to
>> the caller both should be identical.
>>
>
> The problem with qdev is there's too much boiler plate code which makes it
> hard to give examples :-)  Here's precisely what I'm talking about:
>
> static int serial_isa_initfn(ISADevice *dev)
> {
>    static int index;
>    ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
>    SerialState *s = &isa->state;
>
>    if (isa->index == -1)
>        isa->index = index;
>    if (isa->index >= MAX_SERIAL_PORTS)
>        return -1;
>    if (isa->iobase == -1)
>        isa->iobase = isa_serial_io[isa->index];
>    if (isa->isairq == -1)
>        isa->isairq = isa_serial_irq[isa->index];
>    index++;
>
>    s->baudbase = 115200;
>    isa_init_irq(dev, &s->irq, isa->isairq);
>    serial_init_core(s);
>    qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);
>
>    register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
>    register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
>    isa_init_ioport_range(dev, isa->iobase, 8);
>    return 0;
> }
>
> SerialState *serial_init(int base, qemu_irq irq, int baudbase,
>                         CharDriverState *chr)
> {
>    SerialState *s;
>
>    s = qemu_mallocz(sizeof(SerialState));
>
>    s->irq = irq;
>    s->baudbase = baudbase;
>    s->chr = chr;
>    serial_init_core(s);
>
>    vmstate_register(NULL, base, &vmstate_serial, s);
>
>    register_ioport_write(base, 8, 1, serial_ioport_write, s);
>    register_ioport_read(base, 8, 1, serial_ioport_read, s);
>    return s;
> }
>
> static ISADeviceInfo serial_isa_info = {
>    .qdev.name  = "isa-serial",
>    .qdev.size  = sizeof(ISASerialState),
>    .qdev.vmsd  = &vmstate_isa_serial,
>    .init       = serial_isa_initfn,
>    .qdev.props = (Property[]) {
>        DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
>        DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
>        DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
>        DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
>        DEFINE_PROP_END_OF_LIST(),
>    },
> };
>
> static void serial_register_devices(void)
> {
>    isa_qdev_register(&serial_isa_info);
> }
>
> device_init(serial_register_devices)
>
>
> To create a device, I need to do:
>
> {
>     ISADevice *dev;
>
>     dev = isa_create("isa-serial");
>     if (dev == NULL) {
>          return error;
>     }
>     if (qdev_set_uint32(&dev->qdev, "index", index)) {
>          goto err;
>     }
>     if (qdev_set_uint32(&dev->qdev, "iobase", iobase)) {
>          goto err;
>     }
>     if (qdev_set_uint32(&dev->qdev, "irq", irq)) {
>         goto err;
>     }
>     if (qdev_set_chr(&dev->qdev, "chardev", chr)) {
>         goto err;
>     }
>     if (qdev_init(&dev->qdev)) {
>         goto err;
>     }
>     return 0;
> err:
>     qdev_destroy(&dev->qdev);
>     return -1;
> }
>
> This is simply not a reasonable API to use to create devices.

This can be wrapped in a static inline function, with similar
signature to what you propose:

static inline ISADevice *serial_init(int base, qemu_irq irq, int
baudbase, CharDriverState *chr);

>  There are two
> ways we can make this more managable.  The first is gobject-style vararg
> constructor coupled with a type safe wrapper.  So...
>
> ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase,
> uint32_t irq, CharDriverState *chr)
> {
>      return isa_device_create_va("isa-seral", "index", index, "iobase",
> iobase, "irq", irq, "chardev", chr, NULL);
> }
>
> Now this can be used in a reasonable fashion.  However, we can do even
> better if we change the way qdev is done.   Consider the following:
>
> SerialState *serial_init(int base, qemu_irq irq, int baudbase,
>                         CharDriverState *chr)
> {
>    SerialState *s;
>
>    s = qemu_mallocz(sizeof(SerialState));
>
>    s->irq = irq;
>    s->baudbase = baudbase;
>    s->chr = chr;
>    serial_init_core(s);
>
>    vmstate_register(NULL, base, &vmstate_serial, s);
>
>    register_ioport_write(base, 8, 1, serial_ioport_write, s);
>    register_ioport_read(base, 8, 1, serial_ioport_read, s);
>    return s;
> }
>
> ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase, uint32_t
> irq, CharDriverState *chr)
> {
>    static int index;
>    ISADevice *dev = isa_create("isa-serial");
>    ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
>    SerialState *s = &isa->state;
>
>    if (index == -1)
>        index = index;
>    if (index >= MAX_SERIAL_PORTS)
>        return NULL;
>    if (iobase == -1)
>        iobase = isa_serial_io[index];
>    if (isairq == -1)
>        isairq = isa_serial_irq[index];
>    index++;
>
>    s->baudbase = 115200;
>    isa_init_irq(dev, &s->irq, isairq);
>    serial_init_core(s);
>    qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);
>
>    register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
>    register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
>    isa_init_ioport_range(dev, isa->iobase, 8);
>    return isa;
> }
>
> static ISADevice *isa_seral_init_qdev(QemuOpts *opts)
> {
>      uint32_t index = qemu_opt_get_uint32(opts, "index", -1);
>      uint32_t irq = qemu_opt_get_uint32(opts, "irq", -1);
>      uint32_t iobase = qemu_opt_get_uint32(opts, "iobase", -1);
>      CharDriverState *chr = qemu_opt_get_chr(opts, "chardev");
>
>      return isa_serial_new(index, irq, iobase, chr);
> }
>
> static void serial_register_devices(void)
> {
>    isa_qdev_register("isa-serial", isa_serial_init_qdev);
> }
>
> device_init(serial_register_devices)
>
> The advantage of this model is that we can totally ignore the factory
> interface for devices that we don't care about exposing to the user.  So the
> isa_seral_init_qdev part is totally optional.

I'd still like to have the inline wrapper over the factory interface,
probably with similar signature to isa_serial_new. Then there would be
two functions, one going through qdev and the other bypassing it. I
don't see how that would be useful.

The callers of the direct interface would force linkage between them
and so it would be impossible to build QEMU with that device. We don't
need that flexibility for every device though, but I don't see any
advantages for using the direct interface either.

Why shouldn't we want all devices to be exposed to the user? For
example, there are still devices which don't show up in 'info qtree',
which is a shame.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 10:53 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/14/2011 11:31 AM, Blue Swirl wrote:
>>
>> I don't understand. The caller just does
>> if (isa_serial_init()) {
>>   error();
>> }
>> or
>> if (serial_init()) {
>>   error();
>> }
>>
>> If you mean inside isa_serial_init() vs. serial_init(), that may be
>> true since isa_serial_init has to check for qdev failures, but the to
>> the caller both should be identical.
>>
>
> The problem with qdev is there's too much boiler plate code which makes it
> hard to give examples :-)  Here's precisely what I'm talking about:
>
> static int serial_isa_initfn(ISADevice *dev)
> {
>    static int index;
>    ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
>    SerialState *s = &isa->state;
>
>    if (isa->index == -1)
>        isa->index = index;
>    if (isa->index >= MAX_SERIAL_PORTS)
>        return -1;
>    if (isa->iobase == -1)
>        isa->iobase = isa_serial_io[isa->index];
>    if (isa->isairq == -1)
>        isa->isairq = isa_serial_irq[isa->index];
>    index++;
>
>    s->baudbase = 115200;
>    isa_init_irq(dev, &s->irq, isa->isairq);
>    serial_init_core(s);
>    qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);
>
>    register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
>    register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
>    isa_init_ioport_range(dev, isa->iobase, 8);
>    return 0;
> }
>
> SerialState *serial_init(int base, qemu_irq irq, int baudbase,
>                         CharDriverState *chr)
> {
>    SerialState *s;
>
>    s = qemu_mallocz(sizeof(SerialState));
>
>    s->irq = irq;
>    s->baudbase = baudbase;
>    s->chr = chr;
>    serial_init_core(s);
>
>    vmstate_register(NULL, base, &vmstate_serial, s);
>
>    register_ioport_write(base, 8, 1, serial_ioport_write, s);
>    register_ioport_read(base, 8, 1, serial_ioport_read, s);
>    return s;
> }
>
> static ISADeviceInfo serial_isa_info = {
>    .qdev.name  = "isa-serial",
>    .qdev.size  = sizeof(ISASerialState),
>    .qdev.vmsd  = &vmstate_isa_serial,
>    .init       = serial_isa_initfn,
>    .qdev.props = (Property[]) {
>        DEFINE_PROP_UINT32("index", ISASerialState, index,   -1),
>        DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
>        DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
>        DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
>        DEFINE_PROP_END_OF_LIST(),
>    },
> };
>
> static void serial_register_devices(void)
> {
>    isa_qdev_register(&serial_isa_info);
> }
>
> device_init(serial_register_devices)
>
>
> To create a device, I need to do:
>
> {
>     ISADevice *dev;
>
>     dev = isa_create("isa-serial");
>     if (dev == NULL) {
>          return error;
>     }
>     if (qdev_set_uint32(&dev->qdev, "index", index)) {
>          goto err;
>     }
>     if (qdev_set_uint32(&dev->qdev, "iobase", iobase)) {
>          goto err;
>     }
>     if (qdev_set_uint32(&dev->qdev, "irq", irq)) {
>         goto err;
>     }
>     if (qdev_set_chr(&dev->qdev, "chardev", chr)) {
>         goto err;
>     }
>     if (qdev_init(&dev->qdev)) {
>         goto err;
>     }
>     return 0;
> err:
>     qdev_destroy(&dev->qdev);
>     return -1;
> }
>
> This is simply not a reasonable API to use to create devices.

This can be wrapped in a static inline function, with similar
signature to what you propose:

static inline ISADevice *serial_init(int base, qemu_irq irq, int
baudbase, CharDriverState *chr);

>  There are two
> ways we can make this more managable.  The first is gobject-style vararg
> constructor coupled with a type safe wrapper.  So...
>
> ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase,
> uint32_t irq, CharDriverState *chr)
> {
>      return isa_device_create_va("isa-seral", "index", index, "iobase",
> iobase, "irq", irq, "chardev", chr, NULL);
> }
>
> Now this can be used in a reasonable fashion.  However, we can do even
> better if we change the way qdev is done.   Consider the following:
>
> SerialState *serial_init(int base, qemu_irq irq, int baudbase,
>                         CharDriverState *chr)
> {
>    SerialState *s;
>
>    s = qemu_mallocz(sizeof(SerialState));
>
>    s->irq = irq;
>    s->baudbase = baudbase;
>    s->chr = chr;
>    serial_init_core(s);
>
>    vmstate_register(NULL, base, &vmstate_serial, s);
>
>    register_ioport_write(base, 8, 1, serial_ioport_write, s);
>    register_ioport_read(base, 8, 1, serial_ioport_read, s);
>    return s;
> }
>
> ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase, uint32_t
> irq, CharDriverState *chr)
> {
>    static int index;
>    ISADevice *dev = isa_create("isa-serial");
>    ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
>    SerialState *s = &isa->state;
>
>    if (index == -1)
>        index = index;
>    if (index >= MAX_SERIAL_PORTS)
>        return NULL;
>    if (iobase == -1)
>        iobase = isa_serial_io[index];
>    if (isairq == -1)
>        isairq = isa_serial_irq[index];
>    index++;
>
>    s->baudbase = 115200;
>    isa_init_irq(dev, &s->irq, isairq);
>    serial_init_core(s);
>    qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);
>
>    register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
>    register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
>    isa_init_ioport_range(dev, isa->iobase, 8);
>    return isa;
> }
>
> static ISADevice *isa_seral_init_qdev(QemuOpts *opts)
> {
>      uint32_t index = qemu_opt_get_uint32(opts, "index", -1);
>      uint32_t irq = qemu_opt_get_uint32(opts, "irq", -1);
>      uint32_t iobase = qemu_opt_get_uint32(opts, "iobase", -1);
>      CharDriverState *chr = qemu_opt_get_chr(opts, "chardev");
>
>      return isa_serial_new(index, irq, iobase, chr);
> }
>
> static void serial_register_devices(void)
> {
>    isa_qdev_register("isa-serial", isa_serial_init_qdev);
> }
>
> device_init(serial_register_devices)
>
> The advantage of this model is that we can totally ignore the factory
> interface for devices that we don't care about exposing to the user.  So the
> isa_seral_init_qdev part is totally optional.

I'd still like to have the inline wrapper over the factory interface,
probably with similar signature to isa_serial_new. Then there would be
two functions, one going through qdev and the other bypassing it. I
don't see how that would be useful.

The callers of the direct interface would force linkage between them
and so it would be impossible to build QEMU with that device. We don't
need that flexibility for every device though, but I don't see any
advantages for using the direct interface either.

Why shouldn't we want all devices to be exposed to the user? For
example, there are still devices which don't show up in 'info qtree',
which is a shame.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/14/2011 03:25 PM, Blue Swirl wrote:
> I'd still like to have the inline wrapper over the factory interface,
> probably with similar signature to isa_serial_new. Then there would be
> two functions, one going through qdev and the other bypassing it. I
> don't see how that would be useful.
>
> The callers of the direct interface would force linkage between them
> and so it would be impossible to build QEMU with that device. We don't
> need that flexibility for every device though, but I don't see any
> advantages for using the direct interface either.
>
> Why shouldn't we want all devices to be exposed to the user? For
> example, there are still devices which don't show up in 'info qtree',
> which is a shame.
>    

Showing up in info qtree is goodness, but I'm talking about allowing a 
user to directly instantiate a device.

Any device we expose to the user through -device needs to maintain a 
compatible interface forever.  For our own sanity, I think we should try 
to expose as little as possible.

A good example of a device that we should model through qdev but not 
expose via -device is actually SerialState.

Today, we have ISASerialState which embeds SerialState.  We can also 
create a MMIO version of SerialState although there's no direct 
structure that wraps that.

Ideally, SerialState would be a proper qdev device that is embedded in 
both ISASerialState and MMIOSerialState (or pick a better name).  info 
qtree should show a has-a relationship for these devices.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/14/2011 03:25 PM, Blue Swirl wrote:
> I'd still like to have the inline wrapper over the factory interface,
> probably with similar signature to isa_serial_new. Then there would be
> two functions, one going through qdev and the other bypassing it. I
> don't see how that would be useful.
>
> The callers of the direct interface would force linkage between them
> and so it would be impossible to build QEMU with that device. We don't
> need that flexibility for every device though, but I don't see any
> advantages for using the direct interface either.
>
> Why shouldn't we want all devices to be exposed to the user? For
> example, there are still devices which don't show up in 'info qtree',
> which is a shame.
>    

Showing up in info qtree is goodness, but I'm talking about allowing a 
user to directly instantiate a device.

Any device we expose to the user through -device needs to maintain a 
compatible interface forever.  For our own sanity, I think we should try 
to expose as little as possible.

A good example of a device that we should model through qdev but not 
expose via -device is actually SerialState.

Today, we have ISASerialState which embeds SerialState.  We can also 
create a MMIO version of SerialState although there's no direct 
structure that wraps that.

Ideally, SerialState would be a proper qdev device that is embedded in 
both ISASerialState and MMIOSerialState (or pick a better name).  info 
qtree should show a has-a relationship for these devices.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/14/2011 03:25 PM, Blue Swirl wrote:
>>
>> I'd still like to have the inline wrapper over the factory interface,
>> probably with similar signature to isa_serial_new. Then there would be
>> two functions, one going through qdev and the other bypassing it. I
>> don't see how that would be useful.
>>
>> The callers of the direct interface would force linkage between them
>> and so it would be impossible to build QEMU with that device. We don't
>> need that flexibility for every device though, but I don't see any
>> advantages for using the direct interface either.
>>
>> Why shouldn't we want all devices to be exposed to the user? For
>> example, there are still devices which don't show up in 'info qtree',
>> which is a shame.
>>
>
> Showing up in info qtree is goodness, but I'm talking about allowing a user
> to directly instantiate a device.
>
> Any device we expose to the user through -device needs to maintain a
> compatible interface forever.  For our own sanity, I think we should try to
> expose as little as possible.

Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?

> A good example of a device that we should model through qdev but not expose
> via -device is actually SerialState.

You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?

> Today, we have ISASerialState which embeds SerialState.  We can also create
> a MMIO version of SerialState although there's no direct structure that
> wraps that.
>
> Ideally, SerialState would be a proper qdev device that is embedded in both
> ISASerialState and MMIOSerialState (or pick a better name).  info qtree
> should show a has-a relationship for these devices.

I think the devices shown in qtree should always have some
relationship to real devices. If ICH10 contains all possible onboard
devices, including for example HPET, e1000 and SATA, that could use a
has-a relationship to show the composition but otherwise I fear this
would only increase complexity with no gain.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/14/2011 03:25 PM, Blue Swirl wrote:
>>
>> I'd still like to have the inline wrapper over the factory interface,
>> probably with similar signature to isa_serial_new. Then there would be
>> two functions, one going through qdev and the other bypassing it. I
>> don't see how that would be useful.
>>
>> The callers of the direct interface would force linkage between them
>> and so it would be impossible to build QEMU with that device. We don't
>> need that flexibility for every device though, but I don't see any
>> advantages for using the direct interface either.
>>
>> Why shouldn't we want all devices to be exposed to the user? For
>> example, there are still devices which don't show up in 'info qtree',
>> which is a shame.
>>
>
> Showing up in info qtree is goodness, but I'm talking about allowing a user
> to directly instantiate a device.
>
> Any device we expose to the user through -device needs to maintain a
> compatible interface forever.  For our own sanity, I think we should try to
> expose as little as possible.

Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?

> A good example of a device that we should model through qdev but not expose
> via -device is actually SerialState.

You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?

> Today, we have ISASerialState which embeds SerialState.  We can also create
> a MMIO version of SerialState although there's no direct structure that
> wraps that.
>
> Ideally, SerialState would be a proper qdev device that is embedded in both
> ISASerialState and MMIOSerialState (or pick a better name).  info qtree
> should show a has-a relationship for these devices.

I think the devices shown in qtree should always have some
relationship to real devices. If ICH10 contains all possible onboard
devices, including for example HPET, e1000 and SATA, that could use a
has-a relationship to show the composition but otherwise I fear this
would only increase complexity with no gain.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/15/2011 11:11 AM, Blue Swirl wrote:
> On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> Any device we expose to the user through -device needs to maintain a
>> compatible interface forever.  For our own sanity, I think we should try to
>> expose as little as possible.
>>      
> Restricting the users from adding arbitrary devices is a different
> issue. Dropping qdev support to prevent user from adding the device
> seems draconian, what's wrong with no_user flag?
>    

I think you're missing my point.

It should be possible to make a device "qdev" without exposing it via a 
factory interface.  Today it's all or nothing and that's the part I dislike.

no_user is a hack.  We can do better.

>> A good example of a device that we should model through qdev but not expose
>> via -device is actually SerialState.
>>      
> You wouldn't want users to add any serial ports? What should be do
> with serial ports then, always enable a full set of ports? How would
> the user use them?
>    

No, users should be able to create ISASerialDevice, MMIOSerialDevice, 
but not UART16650A.  Here's what I'm talking about:

class ISASerialDevice : public ISADevice
{
     UART16650A uart;
};

class MMIOSerialDevice : public PlatformDevice
{
     UART16650A uart;
};

There should be factory interfaces for ISASeriaDevice and 
MMIOSerialDevice but not UART16650A.

>> Today, we have ISASerialState which embeds SerialState.  We can also create
>> a MMIO version of SerialState although there's no direct structure that
>> wraps that.
>>
>> Ideally, SerialState would be a proper qdev device that is embedded in both
>> ISASerialState and MMIOSerialState (or pick a better name).  info qtree
>> should show a has-a relationship for these devices.
>>      
> I think the devices shown in qtree should always have some
> relationship to real devices. If ICH10 contains all possible onboard
> devices, including for example HPET, e1000 and SATA, that could use a
> has-a relationship to show the composition

Yeah, I'm not disagreeing at all.

Ignoring the fact that modern uarts are implemented in a super i/o chip, 
it's same chip whether it's soldered directly on a board with direct 
connections to a CPU bus or whether it's exposed on the ISA bus.

Regards,

Anthony Liguori

>   but otherwise I fear this
> would only increase complexity with no gain.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/15/2011 11:11 AM, Blue Swirl wrote:
> On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> Any device we expose to the user through -device needs to maintain a
>> compatible interface forever.  For our own sanity, I think we should try to
>> expose as little as possible.
>>      
> Restricting the users from adding arbitrary devices is a different
> issue. Dropping qdev support to prevent user from adding the device
> seems draconian, what's wrong with no_user flag?
>    

I think you're missing my point.

It should be possible to make a device "qdev" without exposing it via a 
factory interface.  Today it's all or nothing and that's the part I dislike.

no_user is a hack.  We can do better.

>> A good example of a device that we should model through qdev but not expose
>> via -device is actually SerialState.
>>      
> You wouldn't want users to add any serial ports? What should be do
> with serial ports then, always enable a full set of ports? How would
> the user use them?
>    

No, users should be able to create ISASerialDevice, MMIOSerialDevice, 
but not UART16650A.  Here's what I'm talking about:

class ISASerialDevice : public ISADevice
{
     UART16650A uart;
};

class MMIOSerialDevice : public PlatformDevice
{
     UART16650A uart;
};

There should be factory interfaces for ISASeriaDevice and 
MMIOSerialDevice but not UART16650A.

>> Today, we have ISASerialState which embeds SerialState.  We can also create
>> a MMIO version of SerialState although there's no direct structure that
>> wraps that.
>>
>> Ideally, SerialState would be a proper qdev device that is embedded in both
>> ISASerialState and MMIOSerialState (or pick a better name).  info qtree
>> should show a has-a relationship for these devices.
>>      
> I think the devices shown in qtree should always have some
> relationship to real devices. If ICH10 contains all possible onboard
> devices, including for example HPET, e1000 and SATA, that could use a
> has-a relationship to show the composition

Yeah, I'm not disagreeing at all.

Ignoring the fact that modern uarts are implemented in a super i/o chip, 
it's same chip whether it's soldered directly on a board with direct 
connections to a CPU bus or whether it's exposed on the ISA bus.

Regards,

Anthony Liguori

>   but otherwise I fear this
> would only increase complexity with no gain.
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
> On 02/15/2011 11:11 AM, Blue Swirl wrote:
> >On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >>Any device we expose to the user through -device needs to maintain a
> >>compatible interface forever.  For our own sanity, I think we should try to
> >>expose as little as possible.
> >Restricting the users from adding arbitrary devices is a different
> >issue. Dropping qdev support to prevent user from adding the device
> >seems draconian, what's wrong with no_user flag?
> 
> I think you're missing my point.
> 
> It should be possible to make a device "qdev" without exposing it
> via a factory interface.  Today it's all or nothing and that's the
> part I dislike.
> 
I think you are mixing too different thing here. The purpose of qdev (or
other device tree implementation) should be 1. to provide factory
interface. 2 to keep track on how devices are interconnected (or in
other words to keep track of device tree). But you are constantly
talking about how qdev should be object oriented way to build devices
themselves and I think this shouldn't be part of qdev at all.

> no_user is a hack.  We can do better.
> 
> >>A good example of a device that we should model through qdev but not expose
> >>via -device is actually SerialState.
> >You wouldn't want users to add any serial ports? What should be do
> >with serial ports then, always enable a full set of ports? How would
> >the user use them?
> 
> No, users should be able to create ISASerialDevice,
> MMIOSerialDevice, but not UART16650A.  Here's what I'm talking
> about:
> 
> class ISASerialDevice : public ISADevice
> {
>     UART16650A uart;
> };
> 
> class MMIOSerialDevice : public PlatformDevice
> {
>     UART16650A uart;
> };
> 
> There should be factory interfaces for ISASeriaDevice and
> MMIOSerialDevice but not UART16650A.
This is OK and I do not disagree with this, but this is not what qdev
should be about. Qdev should be about allowing user to specify how and
which classes (read devices) should be instantiated at how they should
be interconnected. Taking yous example above qdev should allow to say: I
want to instantiate ISASerialDevice on bus object isabus0 (which was
instantiated before). It should claim resources A, B and C from that
bus. I also what instantiate MMIOSerialDevice on bus object systembus
claiming resource Z.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
> On 02/15/2011 11:11 AM, Blue Swirl wrote:
> >On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >>Any device we expose to the user through -device needs to maintain a
> >>compatible interface forever.  For our own sanity, I think we should try to
> >>expose as little as possible.
> >Restricting the users from adding arbitrary devices is a different
> >issue. Dropping qdev support to prevent user from adding the device
> >seems draconian, what's wrong with no_user flag?
> 
> I think you're missing my point.
> 
> It should be possible to make a device "qdev" without exposing it
> via a factory interface.  Today it's all or nothing and that's the
> part I dislike.
> 
I think you are mixing too different thing here. The purpose of qdev (or
other device tree implementation) should be 1. to provide factory
interface. 2 to keep track on how devices are interconnected (or in
other words to keep track of device tree). But you are constantly
talking about how qdev should be object oriented way to build devices
themselves and I think this shouldn't be part of qdev at all.

> no_user is a hack.  We can do better.
> 
> >>A good example of a device that we should model through qdev but not expose
> >>via -device is actually SerialState.
> >You wouldn't want users to add any serial ports? What should be do
> >with serial ports then, always enable a full set of ports? How would
> >the user use them?
> 
> No, users should be able to create ISASerialDevice,
> MMIOSerialDevice, but not UART16650A.  Here's what I'm talking
> about:
> 
> class ISASerialDevice : public ISADevice
> {
>     UART16650A uart;
> };
> 
> class MMIOSerialDevice : public PlatformDevice
> {
>     UART16650A uart;
> };
> 
> There should be factory interfaces for ISASeriaDevice and
> MMIOSerialDevice but not UART16650A.
This is OK and I do not disagree with this, but this is not what qdev
should be about. Qdev should be about allowing user to specify how and
which classes (read devices) should be instantiated at how they should
be interconnected. Taking yous example above qdev should allow to say: I
want to instantiate ISASerialDevice on bus object isabus0 (which was
instantiated before). It should claim resources A, B and C from that
bus. I also what instantiate MMIOSerialDevice on bus object systembus
claiming resource Z.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Paolo Bonzini]

On 02/13/2011 08:57 PM, Anthony Liguori wrote:
> It shouldn't be able to dead lock if the locking is designed right.

As an aside, one advantage of the qemuthread wrappers is that we can add 
lockdep mechanisms.  (It's true that these could be added to glib as 
well, but getting stuff into glib is a pain).

Paolo

Re: [Qemu-devel] KVM call minutes for Feb 8

[Paolo Bonzini]

On 02/13/2011 08:57 PM, Anthony Liguori wrote:
> It shouldn't be able to dead lock if the locking is designed right.

As an aside, one advantage of the qemuthread wrappers is that we can add 
lockdep mechanisms.  (It's true that these could be added to glib as 
well, but getting stuff into glib is a pain).

Paolo

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/10/2011 09:47 AM, Anthony Liguori wrote:
>
> So very concretely, I'm suggesting we do the following to target-i386:
>
> 1) make the i440fx device have an embedded ide controller, piix3, and 
> usb controller that get initialized automatically.  The piix3 embeds 
> the PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
> serial, etc.).

This I like.

>
> 2) get rid of the entire concept of machines.  Creating a i440fx is 
> essentially equivalent to creating a bare machine.

No, it's not.  The 440fx does not include an IOAPIC, for example.  There 
may be other optional components, or differences in wiring, that make 
two machines with i440fx not identical.

>
> 4) model the CPUs as devices that take a pointer to a host controller, 
> for x86, the normal case would be giving it a pointer to i440fx.
>

Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
there happens to be an 440fx north bridge at the end of it.  It could 
also be a Q35 or something else.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 04:29 AM, Avi Kivity wrote:
> On 02/10/2011 09:47 AM, Anthony Liguori wrote:
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3, and 
>> usb controller that get initialized automatically.  The piix3 embeds 
>> the PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
>> serial, etc.).
>
> This I like.
>
>>
>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>> essentially equivalent to creating a bare machine.
>
> No, it's not.  The 440fx does not include an IOAPIC, for example.  
> There may be other optional components, or differences in wiring, that 
> make two machines with i440fx not identical.

The IOAPIC is basically the only other component and I view it as part 
of the CPU interface to the chipset.

But still, if we're creating a machine from scratch:

qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb

Is not all that unreasonable and presents a fully functioning PC.

>>
>> 4) model the CPUs as devices that take a pointer to a host 
>> controller, for x86, the normal case would be giving it a pointer to 
>> i440fx.
>>
>
> Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
> there happens to be an 440fx north bridge at the end of it.  It could 
> also be a Q35 or something else.

I see being on a bus as really just taking a pointer to an interface.  
So yes, the i440fx would implement a PentiumCpuInterface or something 
like that and the CPU would take a pointer to a PentiumCpuInterface[1].

This is part of why having proper polymorphism is important.  We need it 
in order to be able to express concepts like interfaces.

[1] This is just a Random Bad Name.  Don't read anything into it.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 04:29 AM, Avi Kivity wrote:
> On 02/10/2011 09:47 AM, Anthony Liguori wrote:
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3, and 
>> usb controller that get initialized automatically.  The piix3 embeds 
>> the PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
>> serial, etc.).
>
> This I like.
>
>>
>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>> essentially equivalent to creating a bare machine.
>
> No, it's not.  The 440fx does not include an IOAPIC, for example.  
> There may be other optional components, or differences in wiring, that 
> make two machines with i440fx not identical.

The IOAPIC is basically the only other component and I view it as part 
of the CPU interface to the chipset.

But still, if we're creating a machine from scratch:

qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb

Is not all that unreasonable and presents a fully functioning PC.

>>
>> 4) model the CPUs as devices that take a pointer to a host 
>> controller, for x86, the normal case would be giving it a pointer to 
>> i440fx.
>>
>
> Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
> there happens to be an 440fx north bridge at the end of it.  It could 
> also be a Q35 or something else.

I see being on a bus as really just taking a pointer to an interface.  
So yes, the i440fx would implement a PentiumCpuInterface or something 
like that and the CPU would take a pointer to a PentiumCpuInterface[1].

This is part of why having proper polymorphism is important.  We need it 
in order to be able to express concepts like interfaces.

[1] This is just a Random Bad Name.  Don't read anything into it.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Avi Kivity]

On 02/13/2011 05:38 PM, Anthony Liguori wrote:
>>
>>>
>>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>>> essentially equivalent to creating a bare machine.
>>
>> No, it's not.  The 440fx does not include an IOAPIC, for example.  
>> There may be other optional components, or differences in wiring, 
>> that make two machines with i440fx not identical.
>
>
> The IOAPIC is basically the only other component and I view it as part 
> of the CPU interface to the chipset.

But it isn't.  The IOAPIC is not per-core or per-socket.  It's strictly 
board level.  It's a board interface to the cpu.

>
> But still, if we're creating a machine from scratch:
>
> qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
> ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb
>
> Is not all that unreasonable and presents a fully functioning PC.

Sure.  And -M blah is a shortcut.

>
>>>
>>> 4) model the CPUs as devices that take a pointer to a host 
>>> controller, for x86, the normal case would be giving it a pointer to 
>>> i440fx.
>>>
>>
>> Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
>> there happens to be an 440fx north bridge at the end of it.  It could 
>> also be a Q35 or something else.
>
> I see being on a bus as really just taking a pointer to an interface.  
> So yes, the i440fx would implement a PentiumCpuInterface or something 
> like that and the CPU would take a pointer to a PentiumCpuInterface[1].
>
> This is part of why having proper polymorphism is important.  We need 
> it in order to be able to express concepts like interfaces.

The CPUs and northbridge are peers on the system bus.  However, this 
isn't something good to model, since it keeps changing without any guest 
software impact.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 09:56 AM, Avi Kivity wrote:
> On 02/13/2011 05:38 PM, Anthony Liguori wrote:
>>>
>>>>
>>>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>>>> essentially equivalent to creating a bare machine.
>>>
>>> No, it's not.  The 440fx does not include an IOAPIC, for example.  
>>> There may be other optional components, or differences in wiring, 
>>> that make two machines with i440fx not identical.
>>
>>
>> The IOAPIC is basically the only other component and I view it as 
>> part of the CPU interface to the chipset.
>
> But it isn't.  The IOAPIC is not per-core or per-socket.

Yeah, I wasn't implying that it was.

>   It's strictly board level.  It's a board interface to the cpu.
>
>>
>> But still, if we're creating a machine from scratch:
>>
>> qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
>> ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb
>>
>> Is not all that unreasonable and presents a fully functioning PC.
>
> Sure.  And -M blah is a shortcut.

Exactly.  Or better yet, blah is a config file that contains

[device "nb"]
driver=i440fx

[device "sb"]
driver=piix3
chipset=nb

[device "ioapic"]
driver=ioapic
chipset=sb

[device "cpu"]
driver=cpu
ioapic=ioapic
northbridge=nb

>>
>>>>
>>>> 4) model the CPUs as devices that take a pointer to a host 
>>>> controller, for x86, the normal case would be giving it a pointer 
>>>> to i440fx.
>>>>
>>>
>>> Surely the connection is via a bus?  An x86 cpu talks to the bus, 
>>> and there happens to be an 440fx north bridge at the end of it.  It 
>>> could also be a Q35 or something else.
>>
>> I see being on a bus as really just taking a pointer to an 
>> interface.  So yes, the i440fx would implement a PentiumCpuInterface 
>> or something like that and the CPU would take a pointer to a 
>> PentiumCpuInterface[1].
>>
>> This is part of why having proper polymorphism is important.  We need 
>> it in order to be able to express concepts like interfaces.
>
> The CPUs and northbridge are peers on the system bus.  However, this 
> isn't something good to model, since it keeps changing without any 
> guest software impact.

If we can move away from Bus abstraction and to a simpler interface 
mechanism, then we can express peer relationships by just having 
bidirection references.  IOW:

-device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus

I don't think modelling each CPU makes sense.  We should probably just 
model all cpus in a single device for the sake of simplicity.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
> >>
> >>qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
> >>ioapic,id=ioapic,chipset=sb -device
> >>cpu,ioapic=ioapic,northbridge=nb
> >>
> >>Is not all that unreasonable and presents a fully functioning PC.
> >
> >Sure.  And -M blah is a shortcut.
> 
> Exactly.  Or better yet, blah is a config file that contains
> 
> [device "nb"]
> driver=i440fx
> 
You are trying to model how particular (very ancient) HW looked like,
instead of emulating guest visible functionality, but is dead end since
things are changing constantly. Northbridge functionality moves onto
cpu for instance. What CPU i440fx was designed for? Pentium?  What if
user runs QEMU with emulated CPU that in real life has internal memory
controller? Does you config have sense for such setup? Should we allow
to specify only Pentium CPU since this is how real HW worked?

> [device "sb"]
> driver=piix3
And piix3 refers to piix3.cfg which describe devices that present on the
chipset.

> chipset=nb
> 
> [device "ioapic"]
> driver=ioapic
> chipset=sb
Here, for instance, IOAPIC is included in a chipset for a long time
now. Why user should care that piix3 didn't have it. How this detail
changes qemu functionality? If it doesn't why should we expose it?

> 
> [device "cpu"]
> driver=cpu
> ioapic=ioapic
Why ioapic here? Doesn't cpu talks to ioapic via northbridge?

> northbridge=nb
> 

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
> >>
> >>qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
> >>ioapic,id=ioapic,chipset=sb -device
> >>cpu,ioapic=ioapic,northbridge=nb
> >>
> >>Is not all that unreasonable and presents a fully functioning PC.
> >
> >Sure.  And -M blah is a shortcut.
> 
> Exactly.  Or better yet, blah is a config file that contains
> 
> [device "nb"]
> driver=i440fx
> 
You are trying to model how particular (very ancient) HW looked like,
instead of emulating guest visible functionality, but is dead end since
things are changing constantly. Northbridge functionality moves onto
cpu for instance. What CPU i440fx was designed for? Pentium?  What if
user runs QEMU with emulated CPU that in real life has internal memory
controller? Does you config have sense for such setup? Should we allow
to specify only Pentium CPU since this is how real HW worked?

> [device "sb"]
> driver=piix3
And piix3 refers to piix3.cfg which describe devices that present on the
chipset.

> chipset=nb
> 
> [device "ioapic"]
> driver=ioapic
> chipset=sb
Here, for instance, IOAPIC is included in a chipset for a long time
now. Why user should care that piix3 didn't have it. How this detail
changes qemu functionality? If it doesn't why should we expose it?

> 
> [device "cpu"]
> driver=cpu
> ioapic=ioapic
Why ioapic here? Doesn't cpu talks to ioapic via northbridge?

> northbridge=nb
> 

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 12:08 PM, Gleb Natapov wrote:
> On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
>    
>>>> qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
>>>> ioapic,id=ioapic,chipset=sb -device
>>>> cpu,ioapic=ioapic,northbridge=nb
>>>>
>>>> Is not all that unreasonable and presents a fully functioning PC.
>>>>          
>>> Sure.  And -M blah is a shortcut.
>>>        
>> Exactly.  Or better yet, blah is a config file that contains
>>
>> [device "nb"]
>> driver=i440fx
>>
>>      
> You are trying to model how particular (very ancient) HW looked like,
> instead of emulating guest visible functionality, but is dead end since
> things are changing constantly. Northbridge functionality moves onto
> cpu for instance. What CPU i440fx was designed for? Pentium?  What if
> user runs QEMU with emulated CPU that in real life has internal memory
> controller? Does you config have sense for such setup? Should we allow
> to specify only Pentium CPU since this is how real HW worked?
>    

Yes, how we structure the device tree will change over time.  If users 
have to specify this stuff, we've already failed to start with.

The i440fx is definitely guest visible.  And yes, a guest could look at 
freak out that an i440fx is in use with a non-Pentium class CPU.  We 
cheat here, and it works just fine.

>> [device "sb"]
>> driver=piix3
>>      
> And piix3 refers to piix3.cfg which describe devices that present on the
> chipset.
>    

I disagree in this case that it's the best thing to do, but in general, 
yeah, we should provide a mechanism to have essentially device tree 
macros such that one high level device represents a larger tree of 
devices.  This would be a good mechanism to support the concept of machines.

But I don't think we should rely on having this tomorrow as doing this 
well is going to be challenging.

>> chipset=nb
>>
>> [device "ioapic"]
>> driver=ioapic
>> chipset=sb
>>      
> Here, for instance, IOAPIC is included in a chipset for a long time
> now. Why user should care that piix3 didn't have it. How this detail
> changes qemu functionality? If it doesn't why should we expose it?
>    

Yeah, I'd be inclined to push the ioapic into the chipset here except it 
may be useful to have multiple ioapics at some point down the road.

Yes, we're exposing gory details of the device model.  No, I don't have 
a problem with that.

>> [device "cpu"]
>> driver=cpu
>> ioapic=ioapic
>>      
> Why ioapic here? Doesn't cpu talks to ioapic via northbridge?
>    

The i440fx is the northbridge.  For the i440fx, the I/O apic is a 
separate chip.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Gleb Natapov]

On Sun, Feb 13, 2011 at 01:38:12PM -0600, Anthony Liguori wrote:
> On 02/13/2011 12:08 PM, Gleb Natapov wrote:
> >On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote:
> >>>>qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device
> >>>>ioapic,id=ioapic,chipset=sb -device
> >>>>cpu,ioapic=ioapic,northbridge=nb
> >>>>
> >>>>Is not all that unreasonable and presents a fully functioning PC.
> >>>Sure.  And -M blah is a shortcut.
> >>Exactly.  Or better yet, blah is a config file that contains
> >>
> >>[device "nb"]
> >>driver=i440fx
> >>
> >You are trying to model how particular (very ancient) HW looked like,
> >instead of emulating guest visible functionality, but is dead end since
> >things are changing constantly. Northbridge functionality moves onto
> >cpu for instance. What CPU i440fx was designed for? Pentium?  What if
> >user runs QEMU with emulated CPU that in real life has internal memory
> >controller? Does you config have sense for such setup? Should we allow
> >to specify only Pentium CPU since this is how real HW worked?
> 
> Yes, how we structure the device tree will change over time.  If
> users have to specify this stuff, we've already failed to start
> with.
> 
And nevertheless this is what you propose here.  User should be able to
specify what devices he wants in a stable format (FDT for instance) and
qemu should create the machine from it. How it is done internally is
different question, but if FDT cannot be reproduced from internal state
we are doing something wrong. The important thing is: we should model how
different parts of HW work together, not how chips are interconnected.
Look at FDTs of real machines. They may contain a lot of devices, but in
reality most of them are sitting in the same chip as CPU.

> The i440fx is definitely guest visible.  And yes, a guest could look
> at freak out that an i440fx is in use with a non-Pentium class CPU.
> We cheat here, and it works just fine.
And not modeling PIIX3 exactly as in real life (by dropping IDE or USB
or even adding ACPI from PIIX4) works just fine (we checked it here
too). And yes, a guest could look into details and freak out too. But
guests don't do that (otherwise they would have to support each chipset
in existence). The state that i440fx expose to a guest is of any interest
only to firmware and luckily we have our own firmware to take care of
the details. PIIX3 is not mush more visible to a guest. This is just
marketing name for collection of HW put in one chip. Remove USB and you
get PIIX2, add ACPI and you get PIIX4. Why would you want to govern qemu
design from such insignificant details?

> 
> >>[device "sb"]
> >>driver=piix3
> >And piix3 refers to piix3.cfg which describe devices that present on the
> >chipset.
> 
> I disagree in this case that it's the best thing to do, but in
> general, yeah, we should provide a mechanism to have essentially
> device tree macros such that one high level device represents a
> larger tree of devices.  This would be a good mechanism to support
> the concept of machines.
> 
> But I don't think we should rely on having this tomorrow as doing
> this well is going to be challenging.
> 
That is what we (almost) have now. If going your direction makes it
challenging we shouldn't go there.

> >>chipset=nb
> >>
> >>[device "ioapic"]
> >>driver=ioapic
> >>chipset=sb
> >Here, for instance, IOAPIC is included in a chipset for a long time
> >now. Why user should care that piix3 didn't have it. How this detail
> >changes qemu functionality? If it doesn't why should we expose it?
> 
> Yeah, I'd be inclined to push the ioapic into the chipset here
> except it may be useful to have multiple ioapics at some point down
> the road.
When machine has multiple ioapic I am almost sure all of them are present
on a chipset, not as stand alone chips. Since having multiple IOAPIC
affects also firmware I am not sure it is useful to support different
number of IOAPICs in qemu.

> 
> Yes, we're exposing gory details of the device model.  No, I don't
> have a problem with that.
> 
> >>[device "cpu"]
> >>driver=cpu
> >>ioapic=ioapic
> >Why ioapic here? Doesn't cpu talks to ioapic via northbridge?
> 
> The i440fx is the northbridge.  For the i440fx, the I/O apic is a
> separate chip.
>
But it is connected to i440fx, not CPU like in your theoretical config.
 
Northbridge, southbridge are just names that do not have any architectural
significance. Like other said in this thread on other architectures
there is no such naming at all. No wonder, since on most embedded archs
(that I know of) all functionality was included on the same chip as
CPU. On x86 PCs historically motherboard had three main chips (cpu, ram
+ pic controller, common hw), so they got those names.  Now in Intel
"Sandy Bridge" all of the functions of the northbridge reside on the
chip itself for instance and I am sure there will be Atoms with all HW
on the same chip.

--
			Gleb.

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 13 February 2011 16:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
> If we can move away from Bus abstraction and to a simpler interface
> mechanism, then we can express peer relationships by just having bidirection
> references.  IOW:
>
> -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus
>
> I don't think modelling each CPU makes sense.  We should probably just model
> all cpus in a single device for the sake of simplicity.

How would this work for systems with multiple CPUs which have different
views of the world? (ie their memory maps differ so that eg some RAM is
shared between them but some parts of the address space are different
RAM for the two cores, some devices one core only, some devices shared
between cores but the device can tell which core made an IO request)
With a bus-style abstraction this is straightforward: each core has its
own bus which is what defines its view of the world, some devices
and RAM are wired up to both buses. I'm not sure how the bidirectional
reference model would look for this?

(Real world examples would be if we ever had any need to actually
model any of the auxiliary cores in say an OMAP device, or the
M3 in a versatile-express. Yes, most systems won't look that odd
but it does come up, especially in testbench type designs, and our
interface abstraction should be able to handle it.)

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 13 February 2011 16:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
> If we can move away from Bus abstraction and to a simpler interface
> mechanism, then we can express peer relationships by just having bidirection
> references.  IOW:
>
> -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus
>
> I don't think modelling each CPU makes sense.  We should probably just model
> all cpus in a single device for the sake of simplicity.

How would this work for systems with multiple CPUs which have different
views of the world? (ie their memory maps differ so that eg some RAM is
shared between them but some parts of the address space are different
RAM for the two cores, some devices one core only, some devices shared
between cores but the device can tell which core made an IO request)
With a bus-style abstraction this is straightforward: each core has its
own bus which is what defines its view of the world, some devices
and RAM are wired up to both buses. I'm not sure how the bidirectional
reference model would look for this?

(Real world examples would be if we ever had any need to actually
model any of the auxiliary cores in say an OMAP device, or the
M3 in a versatile-express. Yes, most systems won't look that odd
but it does come up, especially in testbench type designs, and our
interface abstraction should be able to handle it.)

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 03:24 PM, Peter Maydell wrote:
> On 13 February 2011 16:56, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> If we can move away from Bus abstraction and to a simpler interface
>> mechanism, then we can express peer relationships by just having bidirection
>> references.  IOW:
>>
>> -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus
>>
>> I don't think modelling each CPU makes sense.  We should probably just model
>> all cpus in a single device for the sake of simplicity.
>>      
> How would this work for systems with multiple CPUs which have different
> views of the world? (ie their memory maps differ so that eg some RAM is
> shared between them but some parts of the address space are different
> RAM for the two cores, some devices one core only, some devices shared
> between cores but the device can tell which core made an IO request)
> With a bus-style abstraction this is straightforward: each core has its
> own bus which is what defines its view of the world, some devices
> and RAM are wired up to both buses. I'm not sure how the bidirectional
> reference model would look for this?
>    

Each core has it's own northbridge.  You would do:

-device arm-cpu,northbridge=nb1  -device dsp,northbridge=nb2

Or whatever.

Regards,

Anthony Liguori

> (Real world examples would be if we ever had any need to actually
> model any of the auxiliary cores in say an OMAP device, or the
> M3 in a versatile-express. Yes, most systems won't look that odd
> but it does come up, especially in testbench type designs, and our
> interface abstraction should be able to handle it.)
>
> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/13/2011 03:24 PM, Peter Maydell wrote:
> On 13 February 2011 16:56, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> If we can move away from Bus abstraction and to a simpler interface
>> mechanism, then we can express peer relationships by just having bidirection
>> references.  IOW:
>>
>> -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus
>>
>> I don't think modelling each CPU makes sense.  We should probably just model
>> all cpus in a single device for the sake of simplicity.
>>      
> How would this work for systems with multiple CPUs which have different
> views of the world? (ie their memory maps differ so that eg some RAM is
> shared between them but some parts of the address space are different
> RAM for the two cores, some devices one core only, some devices shared
> between cores but the device can tell which core made an IO request)
> With a bus-style abstraction this is straightforward: each core has its
> own bus which is what defines its view of the world, some devices
> and RAM are wired up to both buses. I'm not sure how the bidirectional
> reference model would look for this?
>    

Each core has it's own northbridge.  You would do:

-device arm-cpu,northbridge=nb1  -device dsp,northbridge=nb2

Or whatever.

Regards,

Anthony Liguori

> (Real world examples would be if we ever had any need to actually
> model any of the auxiliary cores in say an OMAP device, or the
> M3 in a versatile-express. Yes, most systems won't look that odd
> but it does come up, especially in testbench type designs, and our
> interface abstraction should be able to handle it.)
>
> -- PMM
>
>    

Re: [Qemu-devel] KVM call minutes for Feb 8

[Peter Maydell]

On 13 February 2011 22:43, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/13/2011 03:24 PM, Peter Maydell wrote:
>> How would this work for systems with multiple CPUs which have different
>> views of the world? (ie their memory maps differ so that eg some RAM is
>> shared between them but some parts of the address space are different
>> RAM for the two cores, some devices one core only, some devices shared
>> between cores but the device can tell which core made an IO request)
>> With a bus-style abstraction this is straightforward: each core has its
>> own bus which is what defines its view of the world, some devices
>> and RAM are wired up to both buses. I'm not sure how the bidirectional
>> reference model would look for this?
>
> Each core has it's own northbridge.  You would do:
>
> -device arm-cpu,northbridge=nb1  -device dsp,northbridge=nb2

I'm afraid I don't really understand what you mean here. "Northbridge"
as I understand it is a very PC-architecture specific term; can you
explain a bit more about what would actually be going on here?
(ie what are the various components in this kind of system model
and what are they doing?)

-- PMM

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 04:29 AM, Avi Kivity wrote:
> On 02/10/2011 09:47 AM, Anthony Liguori wrote:
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3, and 
>> usb controller that get initialized automatically.  The piix3 embeds 
>> the PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
>> serial, etc.).
>
> This I like.
>
>>
>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>> essentially equivalent to creating a bare machine.
>
> No, it's not.  The 440fx does not include an IOAPIC, for example.  
> There may be other optional components, or differences in wiring, that 
> make two machines with i440fx not identical.

The IOAPIC is basically the only other component and I view it as part 
of the CPU interface to the chipset.

But still, if we're creating a machine from scratch:

qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb

Is not all that unreasonable and presents a fully functioning PC.

>>
>> 4) model the CPUs as devices that take a pointer to a host 
>> controller, for x86, the normal case would be giving it a pointer to 
>> i440fx.
>>
>
> Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
> there happens to be an 440fx north bridge at the end of it.  It could 
> also be a Q35 or something else.

I see being on a bus as really just taking a pointer to an interface.  
So yes, the i440fx would implement a PentiumCpuInterface or something 
like that and the CPU would take a pointer to a PentiumCpuInterface[1].

This is part of why having proper polymorphism is important.  We need it 
in order to be able to express concepts like interfaces.

[1] This is just a Random Bad Name.  Don't read anything into it.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Anthony Liguori]

On 02/10/2011 04:29 AM, Avi Kivity wrote:
> On 02/10/2011 09:47 AM, Anthony Liguori wrote:
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3, and 
>> usb controller that get initialized automatically.  The piix3 embeds 
>> the PCI-to-ISA bridge along with all of the default ISA devices (rtc, 
>> serial, etc.).
>
> This I like.
>
>>
>> 2) get rid of the entire concept of machines.  Creating a i440fx is 
>> essentially equivalent to creating a bare machine.
>
> No, it's not.  The 440fx does not include an IOAPIC, for example.  
> There may be other optional components, or differences in wiring, that 
> make two machines with i440fx not identical.

The IOAPIC is basically the only other component and I view it as part 
of the CPU interface to the chipset.

But still, if we're creating a machine from scratch:

qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device 
ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb

Is not all that unreasonable and presents a fully functioning PC.

>>
>> 4) model the CPUs as devices that take a pointer to a host 
>> controller, for x86, the normal case would be giving it a pointer to 
>> i440fx.
>>
>
> Surely the connection is via a bus?  An x86 cpu talks to the bus, and 
> there happens to be an 440fx north bridge at the end of it.  It could 
> also be a Q35 or something else.

I see being on a bus as really just taking a pointer to an interface.  
So yes, the i440fx would implement a PentiumCpuInterface or something 
like that and the CPU would take a pointer to a PentiumCpuInterface[1].

This is part of why having proper polymorphism is important.  We need it 
in order to be able to express concepts like interfaces.

[1] This is just a Random Bad Name.  Don't read anything into it.

Regards,

Anthony Liguori

Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 02/09/2011 09:15 PM, Blue Swirl wrote:
>>
>> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 02/09/2011 06:48 PM, Blue Swirl wrote:
>>>
>>>>>
>>>>> ISASerialState dev;
>>>>>
>>>>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>>>>
>>>>>
>>>>
>>>> Do you mean that there should be a generic way of doing that, like
>>>> sysbus_create_varargs() for qdev, or just add inline functions which
>>>> hide qdev property setup?
>>>>
>>>> I still think that FDT should be used in the future. That would
>>>> require that the properties can be set up mechanically, and I don't
>>>> see how your proposal would help that.
>>>>
>>>>
>>>
>>> Yeah, I don't think that is a good idea anymore.  I think this is part of
>>> why we're having so many problems with qdev.
>>>
>>> While (most?) hardware hierarchies can be represented by device tree
>>> syntax,
>>> not all valid device trees correspond to interface and/or useful hardware
>>> hierarchies.
>>>
>>
>> User creates a non-working machine and so gets to fix the problems?
>> How is that a problem for us?
>>
>
> It's not about creating a non-working machine.  It's about what user-level
> abstraction we need to provide.
>
> It's a whole lot easier to implement an i440fx device with a fixed set of
> parameters than it is to make every possible subdevice have a proper factory
> interface along with mechanisms to hook everything together.
>
> Basically, we're making things much harder for ourselves than we should.
>
>>> We want to have an interface to create large chunks of hardware (like an
>>> i440fx) which then results in a significant portion of a device tree.
>>>
>>
>> But how would this affect interface to devices? I don't see how that
>> would be any different with current model and the function call model.
>>
>
> If all composition is done through a factory interface, it doesn't.  But my
> main argument here is that we shouldn't try to make all composition done
> through a factory interface--only where it makes sense.
>
> So very concretely, I'm suggesting we do the following to target-i386:
>
> 1) make the i440fx device have an embedded ide controller, piix3, and usb
> controller that get initialized automatically.  The piix3 embeds the
> PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial,
> etc.).

This makes sense.

> 2) get rid of the entire concept of machines.  Creating a i440fx is
> essentially equivalent to creating a bare machine.

This doesn't make so much sense. There's still memory and the PCI
devices plugged to PCI bus created by i440fx. The various drives need
to be connected IDE channels, chardevs to serial ports etc., the
devices can't claim them in order of creation. The connections must be
managed at board level.

But I don't disagree completely, some time ago I proposed that
machines should be qdevified and also some of host functions.

> 3) just use the existing -device infrastructure to support all of this.  A
> very simple device config corresponds to a very complex device tree but
> that's the desired effect.

This depends on the above.

> 4) model the CPUs as devices that take a pointer to a host controller, for
> x86, the normal case would be giving it a pointer to i440fx.

For more precision, each CPUs should connect to its cache controller,
which should connect to local APIC, that to global bus for IOAPIC,
that to northbridge, which connects to both memory and southbridge.

Anyway, all of the above points 1 to 4 are orthogonal to qdev and its
API, they can be done either way.