| a5f54290 | 20-May-2014 |
Peter Crosthwaite <peter.crosthwaite@xilinx.com> |
qdev: Implement named GPIOs
Implement named GPIOs on the Device layer. Listifies the existing GPIOs stuff using string keys. Legacy un-named GPIOs are preserved by using a NULL name string - they ar
qdev: Implement named GPIOs
Implement named GPIOs on the Device layer. Listifies the existing GPIOs stuff using string keys. Legacy un-named GPIOs are preserved by using a NULL name string - they are just a single matchable element in the name list.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
show more ...
|
| 65cd9064 | 25-Apr-2014 |
Markus Armbruster <armbru@redhat.com> |
qom: Clean up fragile use of error_is_set() in set() methods
Using error_is_set(ERRP) to find out whether a function failed is either wrong, fragile, or unnecessarily opaque. It's wrong when ERRP m
qom: Clean up fragile use of error_is_set() in set() methods
Using error_is_set(ERRP) to find out whether a function failed is either wrong, fragile, or unnecessarily opaque. It's wrong when ERRP may be null, because errors go undetected when it is. It's fragile when proving ERRP non-null involves a non-local argument. Else, it's unnecessarily opaque (see commit 84d18f0).
I guess the error_is_set(errp) in the ObjectProperty set() methods are merely fragile right now, because I can't find a call chain that passes a null errp argument.
Make the code more robust and more obviously correct: receive the error in a local variable, then propagate it through the parameter.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
show more ...
|
| 6e4a876b | 03-Mar-2014 |
Stefan Hajnoczi <stefanha@redhat.com> |
iothread: add "iothread" qdev property type
Add a "iothread" qdev property type so devices can be hooked up to an IOThread from the comand-line:
qemu -object iothread,id=iothread0 \ -devic
iothread: add "iothread" qdev property type
Add a "iothread" qdev property type so devices can be hooked up to an IOThread from the comand-line:
qemu -object iothread,id=iothread0 \ -device some-device,x-iothread=iothread0
Note that Paolo Bonzini <pbonzini@redhat.com> has suggested using QOM links instead. This way the relationship between the objects is reflected in QOM. There are currently shortcomings of object_property_add_link() which prevent this use case. I will attempt to fix them and move to QOM links in a separate series.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
| 5c21ce77 | 12-Mar-2014 |
Bandan Das <bsd@redhat.com> |
qdev: Realize buses on device realization
Integrate (un)realization of child buses with realization/unrealization of the device hosting them. Code in device_unparent() is reordered for unrealization
qdev: Realize buses on device realization
Integrate (un)realization of child buses with realization/unrealization of the device hosting them. Code in device_unparent() is reordered for unrealization of buses to work as part of device unrealization.
That way no changes need to be made to bus instantiation.
Signed-off-by: Bandan Das <bsd@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
show more ...
|
| 36d20cb2 | 05-Mar-2014 |
Marcel Apfelbaum <marcel.a@redhat.com> |
hw/core: Introduce QEMU machine as QOM object
The main functional change is to convert QEMUMachine into MachineClass and QEMUMachineInitArgs into MachineState, instance of MachineClass.
As a first
hw/core: Introduce QEMU machine as QOM object
The main functional change is to convert QEMUMachine into MachineClass and QEMUMachineInitArgs into MachineState, instance of MachineClass.
As a first step, in order to make possible an incremental development, both QEMUMachine and QEMUMachineInitArgs are being embedded into the new types.
Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
show more ...
|
| 267a3264 | 18-Feb-2014 |
Igor Mammedov <imammedo@redhat.com> |
qdev: Set DeviceClass::hotpluggable default in class_init()
Move setting DeviceClass::hotpluggable default from device's class_base_init() to device's class_init().
Reported-by: Andreas Färber <afa
qdev: Set DeviceClass::hotpluggable default in class_init()
Move setting DeviceClass::hotpluggable default from device's class_base_init() to device's class_init().
Reported-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>
show more ...
|
| ac41881b | 06-Mar-2014 |
Michael S. Tsirkin <mst@redhat.com> |
pc: avoid duplicate names for ROM MRs
Since commit 04920fc0faa4760f9c4fc0e73b992b768099be70 loader: store FW CFG ROM files in RAM RAM MRs including ROM files in FW CFGs are created and named usi
pc: avoid duplicate names for ROM MRs
Since commit 04920fc0faa4760f9c4fc0e73b992b768099be70 loader: store FW CFG ROM files in RAM RAM MRs including ROM files in FW CFGs are created and named using the file basename.
This becomes problematic if these names are supplied by user, since the basename might not be unique.
There are two cases we care about: - option-rom flag. - option ROM for devices. This triggers e.g. when using rombar=0.
At the moment we get an assert. E.g qemu -option-rom /usr/share/ipxe/8086100e.rom -option-rom /usr/share/ipxe.efi/8086100e.rom RAMBlock "/rom@genroms/8086100e.rom" already registered, abort!
This is a regression from 1.6.
For now let's keep it simple and just avoid creating the MRs in case of option ROMs.
when using 1.7 machine types, enable option ROMs in RAM to match that version.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 61de3676 | 06-Feb-2014 |
Alexander Graf <agraf@suse.de> |
qdev: Keep global allocation counter per bus
When we have 2 separate qdev devices that both create a qbus of the same type without specifying a bus name or device name, we end up with two buses of t
qdev: Keep global allocation counter per bus
When we have 2 separate qdev devices that both create a qbus of the same type without specifying a bus name or device name, we end up with two buses of the same name, such as ide.0 on the Mac machines:
dev: macio-ide, id "" bus: ide.0 type IDE dev: macio-ide, id "" bus: ide.0 type IDE
If we now spawn a device that connects to a ide.0 the last created bus gets the device, with the first created bus inaccessible to the command line.
After some discussion on IRC we concluded that the best quick fix way forward for this is to make automated bus-class type based allocation count a global counter. That's what this patch implements. With this we instead get
dev: macio-ide, id "" bus: ide.1 type IDE dev: macio-ide, id "" bus: ide.0 type IDE
on the example mentioned above.
This also means that if you did -device ...,bus=ide.0 you got a device on the first bus (the last created one) before this patch and get that device on the second one (the first created one) now. Breaks migration unless you change bus=ide.0 to bus=ide.1 on the destination.
This is intended and makes the bus enumeration work as expected.
As per review request follows a list of otherwise affected boards and the reasoning for the conclusion that they are ok:
target machine bus id times ------ ------- ------ -----
aarch64 n800 i2c-bus.0 2 aarch64 n810 i2c-bus.0 2 arm n800 i2c-bus.0 2 arm n810 i2c-bus.0 2
-> Devices are only created explicitly on one of the two buses, using s->mpu->i2c[0], so no change to the guest.
aarch64 vexpress-a15 virtio-mmio-bus.0 4 aarch64 vexpress-a9 virtio-mmio-bus.0 4 aarch64 virt virtio-mmio-bus.0 32 arm vexpress-a15 virtio-mmio-bus.0 4 arm vexpress-a9 virtio-mmio-bus.0 4 arm virt virtio-mmio-bus.0 32
-> Makes -device bus= work for all virtio-mmio buses. Breaks migration. Workaround for migration from old to new: specify virtio-mmio-bus.4 or .32 respectively rather than .0 on the destination.
aarch64 xilinx-zynq-a9 usb-bus.0 2 arm xilinx-zynq-a9 usb-bus.0 2 mips64el fulong2e usb-bus.0 2
-> Normal USB operation not affected. Migration driver needs command line to use the other bus.
i386 isapc ide.0 2 x86_64 isapc ide.0 2 mips mips ide.0 2 mips64 mips ide.0 2 mips64el mips ide.0 2 mipsel mips ide.0 2 ppc g3beige ide.0 2 ppc mac99 ide.0 2 ppc prep ide.0 2 ppc64 g3beige ide.0 2 ppc64 mac99 ide.0 2 ppc64 prep ide.0 2
-> Makes -device bus= work for all IDE buses. Breaks migration. Workaround for migration from old to new: specify ide.1 rather than ide.0 on the destination.
Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Andreas Faerber <afaerber@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|