There's no need to call into ->parse and ->print manually.  The
QOM legacy properties do that for us.

Furthermore, in some cases legacy and static properties have exactly
the same behavior, and we could drop the legacy properties right away.
Add an appropriate fallback to prepare for this.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

These can set a link to any object, as long as it is included in
the composition tree.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This allows to restrict partial matches to objects of the expected
type.  It will let people use bare names to reference drives
even though their name might be the same as a device's (e.g.
-drive id=hd0,if=none,... -device ...,drive=hd0,id=hd0).

As a useful byproduct, this fixes a problem with links of interface
type.  When a link property's type is an interface, the code expects
the implementation object (not the parent object) to be stored in the
variable.  The parent object does not contain the right vtable.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add wrappers that let you get/set properties using normal C data types.

Reviewed-by: Anthony Liguori <anthony@aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Move the creation of QmpInputVisitor and QmpOutputVisitor from qmp.c
to qom/object.c, since it's the only practical way to access object
properties.

Keep this isolated such that it's easy to remove.  At some point, we need
to remove all usage of QObject in the tree and replace it with GVariant.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The interface loop can be performed only on the parent object.  It
does not need to be done on each interface.  Similarly, we can
simplify the code by switching early from the implementation
object to the parent object.
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
 - Add license (Paolo)

Now we have the following behavior:

1) object_new() returns an object with ref = 1
2) object_initialize() does not increase the reference count (ref may be 0).
3) object_deref() will finalize the object when ref = 0.  it does not free the
   memory associated with the object.
4) both link and child properties correctly set the reference count.

The expected usage is the following:

1) child devices should generally be created via object_initialize() using
   memory from the parent device.  Adding the object as a child property will
   take ownership of the object and tie the child's life cycle to the parent.

2) If a child device is created via qdev_create() or some other form of
   object_new(), there must be an object_delete() call in the parent device's
   finalize function.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Links had limited utility before as they only allowed a concrete type to be
specified.  Now we can support abstract types and interfaces which means it's
now possible to have a link<PCIDevice>.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is mostly code movement although not entirely.  This makes properties part
of the Object base class which means that we can now start using Object in a
meaningful way outside of qdev.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

I'm sure the intentions were good here, but there's no reason this should be in
qdev.  Move it to qemu-char where it belongs.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qdev-monitor.c deals with the -device, device_add, and info qdm/qtree
interfaces.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Note that the FIXME gets fixed in series 4/4.  We need to convert BusState to
QOM before we can make parent_bus a link.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This gets us closer to being able to object_new() a qdev type and have a
functioning object verses having to call qdev_create().
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This adds a command that allows searching for types that implement a property.
This allows you to do things like search for all available PCIDevices.  In the
future, we'll also have a standard interface for things with a BlockDriverState
property that a PCIDevice could implement.

This will enable search queries like, "any type that implements the BlockDevice
interface" which would allow management tools to present available block devices
without having to hard code device names.  Since an object can implement
multiple interfaces, one device could act both as a BlockDevice and a
NetworkDevice.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Limit them to the device_add functionality.  Device aliases were a hack based
on the fact that virtio was modeled the wrong way.  The mechanism for aliasing
is very limited in that only one alias can exist for any device.

We have to support it for the purposes of compatibility but we only need to
support it in device_add so restrict it to that piece of code.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
 - Use a table for aliases (Paolo)

It is no longer used in the tree since everything is done natively through
QEMU Object Model.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This was done in a mostly automated fashion.  I did it in three steps and then
rebased it into a single step which avoids repeatedly touching every file in
the tree.

The first step was a sed-based addition of the parent type to the subclass
registration functions.

The second step was another sed-based removal of subclass registration functions
while also adding virtual functions from the base class into a class_init
function as appropriate.

Finally, a python script was used to convert the DeviceInfo structures and
qdev_register_subclass functions to TypeInfo structures, class_init functions,
and type_register_static calls.

We are almost fully converted to QOM after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Teach the various bits of code that need to walk through available devices to
do so via QOM.

Signed-off-by: Anthony Liguori

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As we use class_init to set class members, DeviceInfo no longer holds this
information.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This allows us to drop per-Device registration functions by allowing the
class_init functions to overload qdev methods.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Now DeviceInfo is no longer used after object construction.  All of the
relevant members have been moved to DeviceClass.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Introduce accessors and remove any code that directly accesses DeviceInfo
members.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Type registeration is going to get turned into a QOM call so decouple the
legacy support.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We can probably model USBHidDevice as a base class to get even better code
sharing but for now, just use a common function to initialize the common class
members.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This file only contains code from Red Hat, so it can use GPLv2+.
Tested with `git blame -M -C net/checksum.c`.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The most common use of -net tap is to connect a tap device to a bridge.  This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.

This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to run qemu as root.  The only really viable
mechanism is to use tunctl to create a tap device, attach it to a bridge as
root, and then hand that tap device to qemu.  The problem with this mechanism
is that it requires administrator intervention whenever a user wants to create
a guest.

By essentially writing a helper that implements the most common qemu-ifup
script that can be safely given cap_net_admin, we can dramatically simplify
things for non-privileged users.  We still support existing -net tap options
as a mechanism for advanced users and backwards compatibility.

Currently, this is very Linux centric but there's really no reason why it
couldn't be extended for other Unixes.

A typical invocation would be similar to one of the following:

  qemu linux.img -net bridge -net nic,model=virtio

  qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper"
                 -net nic,model=virtio

  qemu linux.img -netdev bridge,id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

  qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper",id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

The default bridge that we attach to is br0.  The thinking is that a distro
could preconfigure such an interface to allow out-of-the-box bridged networking.

Alternatively, if a user wants to use a different bridge, a typical invocation
would be simliar to one of the following:

  qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio

  qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0"
                 -net nic,model=virtio

  qemu linux.img -netdev bridge,br=qemubr0,id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

  qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0",id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The ideal way to use qemu-bridge-helper is to give it an fscap of using:

 setcap cap_net_admin=ep qemu-bridge-helper

Unfortunately, most distros still do not have a mechanism to package files
with fscaps applied.  This means they'll have to SUID the qemu-bridge-helper
binary.

To improve security, use libcap to reduce our capability set to just
cap_net_admin, then reduce privileges down to the calling user.  This is
hopefully close to equivalent to fscap support from a security perspective.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NRicha Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: NCorey Bryant <coreyb@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>