qdev_prop_set is not needed anymore except for hacks, simplify it and
inline it.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Do not poke anymore in the struct when accessing qdev properties.
Instead, ask the object to set the right value.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Drop the special free callback. Instead, register a "regular"
release method in the non-legacy property.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Pointer properties (except for PROP_PTR of course) should not need a
legacy counterpart. In the future, relative paths will ensure that
QEMU will support the same syntax as now for drives etc..
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
PCI addresses are set with qdev_prop_uint32. Thus we make the QOM
property accept a device and function encoded in an 8-bit integer,
instead of the magic dd.f hex string.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Also generalize the code so that we can have more enum properties
in the future.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We need the print method to put double quotes, but parsing is not special.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In some cases, a legacy property does need a special print method
but not a special parse method. In this case, we can reuse the get/set
from the static (non-legacy) property.
If neither parse nor print is needed, though, do not register the
legacy property at all. The previous patch ensures that the right
fallback will be used.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These can set a link to any object, as long as it is included in
the composition tree.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo 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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo 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: Paolo 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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo 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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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: Anthony 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: Anthony 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: Anthony 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: Anthony 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: Anthony 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: Anthony 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: Anthony 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: Anthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
- Use a table for aliases (Paolo)
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: Anthony 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: Anthony 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: Anthony 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: Anthony 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: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony 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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
Signed-off-by: Anthony 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: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini
Anthony Liguori
Stefan Weil
Corey Bryant