- 18 6月, 2012 1 次提交
-
-
由 Paolo Bonzini 提交于
In qdev, each bus in practice identified an abstract superclass, but this was mostly hidden. In QOM, instead, these abstract classes are explicit so we can move bus properties there. All bus property walks are removed, and all device property walks are changed to look along the class hierarchy instead. We would have duplicates if class A defines some properties and its subclass B does not define any, because class_b->props will be left equal to class_a->props. The solution here is to reintroduce the class_base_init TypeInfo callback, that was present in one of the early QOM versions but removed (on my request...) before committing. This breaks global bus properties, an obscure feature when used with the command-line which is actually useful and used when used by backwards-compatible machine types. So this patch also adjusts the global bus properties in hw/pc_piix.c to refer to the abstract class. Globals and other properties must be modified in the same patch to avoid complications related to initialization ordering. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 08 6月, 2012 2 次提交
-
-
由 Paolo Bonzini 提交于
Range checking in PropertyInfo is now used only for pci_devfn properties and some error reporting. Remove all code that implements it in the various property types, and the now unused fields. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> [AF: Fix blocksize min/max for 32-bit hosts by using const int64_t.] Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Michael Roth 提交于
Valid range for devfn is -1 to 255 (-1 for automatic assignment). We do not currently validate this due to devfn being stored as a uint32_t. This can lead to segfaults and other strange behavior. We could technically just cast it to int32_t to implement the checking, but this will not work for visitor-based setting where we may do additional bounds-checking based on target container type, which is int32_t for this case. Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 10 4月, 2012 1 次提交
-
-
由 Luiz Capitulino 提交于
It currently uses qerror_report(), but next commit will convert the drive_del command to the QAPI and this requires using error_set(). One particularity of qerror_report() is that it knows when it's running on monitor context or command-line context and prints the error message accordingly. error_set() doesn't do this, so we have to be careful not to drop error messages. qdev_unplug() has three kinds of usages: 1. It's called when hot adding a device fails, to undo anything that has been done before hitting the error 2. It's called by function monitor functions like device_del(), to unplug a device 3. It's used by xen_platform.c in a way that doesn't _seem_ to be in monitor context Only item 2 can print an error message to the user, this commit maintains that. Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
-
- 05 4月, 2012 1 次提交
-
-
由 Stefan Hajnoczi 提交于
Storage interfaces like virtio-blk can be configured with block size information so that the guest can take advantage of efficient I/O request sizes. According to the SCSI Block Commands (SBC) standard a device's block size is "almost always greater than one byte and may be a multiple of 512 bytes". QEMU currently has a 512 byte minimum block size because the block layer functions work at that granularity. Furthermore, the block size should be a power of 2 because QEMU calculates bitmasks from the value. Introduce a "blocksize" property type so devices can enforce these constraints on block size values. If the constraints are relaxed in the future then this property can be updated. Introduce the new PropertyValueNotPowerOf2 QError so QMP clients know exactly why a block size value was rejected. Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 03 4月, 2012 1 次提交
-
-
由 Paolo Bonzini 提交于
Avoid cluttering too much the QOM root. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 07 2月, 2012 5 次提交
-
-
由 Paolo Bonzini 提交于
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Similarly, use the object properties also to set the default values of the qdev properties. This requires reordering registration and initialization. Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Do not poke anymore in the struct when accessing qdev properties. Instead, ask the object to set the right value. Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Drop the special free callback. Instead, register a "regular" release method in the non-legacy property. Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Also generalize the code so that we can have more enum properties in the future. Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 04 2月, 2012 10 次提交
-
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
qdev-monitor.c deals with the -device, device_add, and info qdm/qtree interfaces. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
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)
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
Teach the various bits of code that need to walk through available devices to do so via QOM. Signed-off-by: Anthony Liguori
-
由 Anthony Liguori 提交于
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>
-
由 Anthony Liguori 提交于
Introduce accessors and remove any code that directly accesses DeviceInfo members. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 02 2月, 2012 1 次提交
-
-
由 Jan Kiszka 提交于
Potentially tick-generating timer devices will gain a common property: lock_tick_policy. It allows to encode 4 different ways how to deal with tick events the guest did not process in time: discard - ignore lost ticks (e.g. if the guest compensates for them already) delay - replay all lost ticks in a row once the guest accepts them again merge - if multiple ticks are lost, all of them are merged into one which is replayed once the guest accepts it again slew - lost ticks are gradually replayed at a higher frequency than the original tick Not all timer device will need to support all modes. However, all need to accept the configuration via this common property. Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 28 1月, 2012 6 次提交
-
-
由 Anthony Liguori 提交于
Since we are still dynamically creating TypeInfo, we need to chain the class_init function in order to be able to make use of it within subclasses of TYPE_DEVICE. This will disappear once we register TypeInfos directly. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
In order to introduce inheritance while still using the qdev registration interfaces, we need to be able to use a parent other than TYPE_DEVICE. Add a new interface that allows this. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
We already have a QOM interface for this so let's use it. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
Right now, DeviceInfo acts as the class for qdev. In order to switch to a proper ObjectClass derivative, we need to ween all of the callers off of interacting directly with the info pointer. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
This is a very shallow integration. We register a TYPE_DEVICE but only use QOM as basically a memory allocator. This will make all devices show up as QOM objects but they will all carry the TYPE_DEVICE. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com> --- v1 -> v2 - update for new location of object.h
-
- 22 1月, 2012 1 次提交
-
-
由 Blue Swirl 提交于
Improve VGA selection logic, push check for device availabilty to vl.c. Create the devices at board level unconditionally. Remove now unused pci_try_create*() functions. Make PCI VGA devices optional. Reviewed-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
-
- 20 12月, 2011 5 次提交
-
-
由 Anthony Liguori 提交于
The peripheral[-anon] containers are initialized lazily but since they sit on sysbus, they can not be created after realize. This was causing an abort() to occur during hotplug if no -device option was used. This was spotted by qemu-test::device-add.sh Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Paolo Bonzini 提交于
Push legacy properties into a "legacy-..." namespace, and make them available with correct types too. For now, all properties come in both variants. This need not be the case for string properties. We will revisit this after -device is changed to actually use the legacy properties. 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>
-
由 Paolo Bonzini 提交于
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>
-
由 Paolo Bonzini 提交于
This patch adds a visitor interface to Property. This way, QOM will be able to expose Properties that access a fixed field in a struct without exposing also the everything-is-a-string "feature" of qdev properties. Whenever the printed representation in both QOM and qdev (which is typically the case for device backends), parse/print code can be reused via get_generic/set_generic. Dually, whenever multiple PropertyInfos have the same representation in both the struct and the visitors the code can be reused (for example among all of int32/uint32/hex32). 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>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 15 12月, 2011 6 次提交
-
-
由 Anthony Liguori 提交于
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
The full tree search was a bit unreasonable. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
Links represent an ephemeral relationship between devices. They are meant to replace the qdev concept of busses by allowing more informal relationships between devices. Links are fairly limited in their usefulness without implementing QOM-style subclassing and interfaces. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
Child properties express a relationship of composition. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Anthony Liguori 提交于
There are two types of supported paths--absolute paths and partial paths. Absolute paths are derived from the root device and can follow child<> or link<> properties. Since they can follow link<> properties, they can be arbitrarily long. Absolute paths look like absolute filenames and are prefixed with a leading slash. Partial paths are look like relative filenames. They do not begin with a prefix. The matching rules for partial paths are subtle but designed to make specifying devices easy. At each level of the composition tree, the partial path is matched as an absolute path. The first match is not returned. At least two matches are searched for. A successful result is only returned if only one match is founded. If more than one match is found, a flag is returned to indicate that the match was ambiguous. At the end of the day, partial path support means that if you create a device called 'ide0', you can just say 'ide0' as the path name and it will Just Work. If we internally create a device called 'i440fx', you can just say 'i440fx' and it will Just Work and long as you don't do anything silly. A management tool should probably always use absolute paths since then they don't have to deal with the possibility of ambiguity. Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-