- 11 6月, 2020 1 次提交
-
-
由 Jon Doron 提交于
As vmbus-bridge is derived from sysbus device, it has to be whitelisted to be allowed to be created with -device. Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com> Signed-off-by: NMaciej S. Szmigiero <maciej.szmigiero@oracle.com> Signed-off-by: NJon Doron <arilou@gmail.com> Message-Id: <20200424123444.3481728-5-arilou@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 15 5月, 2020 1 次提交
-
-
由 Markus Armbruster 提交于
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
-
- 06 5月, 2020 1 次提交
-
-
由 Cornelia Huck 提交于
Add 5.1 machine types for arm/i440fx/q35/s390x/spapr. Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com> Message-id: 20200429144605.7262-1-cohuck@redhat.com
-
- 04 5月, 2020 1 次提交
-
-
由 Kwangwoo Lee 提交于
This patch makes IO base and size configurable to create NPIO AML for ACPI NFIT. Since a different architecture like AArch64 does not use port-mapped IO, a configurable IO base is required to create correct mapping of ACPI IO address and size. Signed-off-by: NKwangwoo Lee <kwangwoo.lee@sk.com> Signed-off-by: NEric Auger <eric.auger@redhat.com> Signed-off-by: NShameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <20200421125934.14952-3-shameerali.kolothum.thodi@huawei.com> Acked-by: NPeter Maydell <peter.maydell@linaro.org> Tested-by: NEric Auger <eric.auger@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 09 3月, 2020 1 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
All this files use methods/definitions declared in the NVDIMM device header. Include it. This fixes (when modifying unrelated headers): hw/i386/acpi-build.c:2733:9: error: implicit declaration of function 'nvdimm_build_acpi' is invalid in C99 [-Werror,-Wimplicit-function-declaration] nvdimm_build_acpi(table_offsets, tables_blob, tables->linker, ^ hw/i386/pc.c:1996:61: error: use of undeclared identifier 'TYPE_NVDIMM' const bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); ^ hw/i386/pc.c:2032:55: error: use of undeclared identifier 'TYPE_NVDIMM' bool is_nvdimm = object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM); ^ hw/i386/pc.c:2040:9: error: implicit declaration of function 'nvdimm_plug' is invalid in C99 [-Werror,-Wimplicit-function-declaration] nvdimm_plug(ms->nvdimms_state); ^ hw/i386/pc.c:2040:9: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] nvdimm_plug(ms->nvdimms_state); ^ hw/i386/pc.c:2065:42: error: use of undeclared identifier 'TYPE_NVDIMM' if (object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM)) { ^ hw/i386/pc_i440fx.c:307:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration] nvdimm_init_acpi_state(machine->nvdimms_state, system_io, ^ hw/i386/pc_q35.c:332:9: error: implicit declaration of function 'nvdimm_init_acpi_state' is invalid in C99 [-Werror,-Wimplicit-function-declaration] nvdimm_init_acpi_state(machine->nvdimms_state, system_io, ^ Acked-by: NJohn Snow <jsnow@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-Id: <20200228114649.12818-17-philmd@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
- 07 1月, 2020 1 次提交
-
-
由 Denis Plotnikov 提交于
5.0 machine type uses 4.2 compats. This seems to be incorrect, since the latests machine type by now is 5.0 and it should use its own compat or shouldn't use any relying on the defaults. Seems, like this appeared because of some problems on merge/rebase. Signed-off-by: NDenis Plotnikov <dplotnikov@virtuozzo.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <20191223072856.5369-1-dplotnikov@virtuozzo.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 05 1月, 2020 1 次提交
-
-
由 Denis Plotnikov 提交于
5.0 machine type uses 4.2 compats. This seems to be incorrect, since the latests machine type by now is 5.0 and it should use its own compat or shouldn't use any relying on the defaults. Seems, like this appeared because of some problems on merge/rebase. Signed-off-by: NDenis Plotnikov <dplotnikov@virtuozzo.com> Message-Id: <20191223072856.5369-1-dplotnikov@virtuozzo.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 18 12月, 2019 1 次提交
-
-
由 Paolo Bonzini 提交于
Add it to microvm as well, it is a generic property of the x86 architecture. Suggested-by: NSergio Lopez <slp@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 14 12月, 2019 1 次提交
-
-
由 Cornelia Huck 提交于
Add 5.0 machine types for arm/i440fx/q35/s390x/spapr. For i440fx and q35, unversioned cpu models are still translated to -v1; I'll leave changing this (if desired) to the respective maintainers. Signed-off-by: NCornelia Huck <cohuck@redhat.com> Message-Id: <20191112104811.30323-1-cohuck@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 13 12月, 2019 1 次提交
-
-
由 Evgeny Yakovlev 提交于
Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device Initialization: "Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if they offer VIRTIO_BLK_F_CONFIG_WCE" Currently F_CONFIG_WCE and F_WCE are not connected to each other. Qemu will advertise F_CONFIG_WCE if config-wce argument is set for virtio-blk device. And F_WCE is advertised only if underlying block backend actually has it's caching enabled. Fix this by advertising F_WCE if F_CONFIG_WCE is also advertised. To preserve backwards compatibility with newer machine types make this behaviour governed by "x-enable-wce-if-config-wce" virtio-blk-device property and introduce hw_compat_4_2 with new property being off by default for all machine types <= 4.2 (but don't introduce 4.3 machine type itself yet). Signed-off-by: NEvgeny Yakovlev <wrfsh@yandex-team.ru> Message-Id: <1572978137-189218-1-git-send-email-wrfsh@yandex-team.ru> Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 19 11月, 2019 1 次提交
-
-
由 Liam Merwick 提交于
Attempting to migrate a VM using the microvm machine class results in the source QEMU aborting with the following message/backtrace: target/i386/machine.c:955:tsc_khz_needed: Object 0x555556608fa0 is not an instance of type generic-pc-machine abort() object_class_dynamic_cast_assert() vmstate_save_state_v() vmstate_save_state() vmstate_save() qemu_savevm_state_complete_precopy() migration_thread() migration_thread() migration_thread() qemu_thread_start() start_thread() clone() The access to the machine class returned by MACHINE_GET_CLASS() in tsc_khz_needed() is crashing as it is trying to dereference a different type of machine class object (TYPE_PC_MACHINE) to that of this microVM. This can be resolved by extending the changes in the following commit f0bb276b ("hw/i386: split PCMachineState deriving X86MachineState from it") and moving the save_tsc_khz field in PCMachineClass to X86MachineClass. Fixes: f0bb276b ("hw/i386: split PCMachineState deriving X86MachineState from it") Signed-off-by: NLiam Merwick <liam.merwick@oracle.com> Reviewed-by: NDarren Kenny <darren.kenny@oracle.com> Message-Id: <1574075605-25215-1-git-send-email-liam.merwick@oracle.com> Reviewed-by: NSergio Lopez <slp@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 26 10月, 2019 1 次提交
-
-
由 Paolo Bonzini 提交于
Move it out of pc.c since it is strictly tied to TCG. This is almost exclusively code movement, the next patch will implement IGNNE. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 25 10月, 2019 1 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
The MC146818 is a Real Time Clock, not a timer. Move it under the hw/rtc/ subdirectory. Use copyright statement from 80cabfad for "hw/rtc/mc146818rtc.h". Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191003230404.19384-4-philmd@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
- 24 10月, 2019 4 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
By extracting pc_gsi_create() and pc_i8259_create() we removed the access to "kvm_i386.h" from the machine code. We can now remove it. Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191015162705.28087-25-philmd@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
The i8259 creation code is common to all PC machines, extract the common code. Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191018135910.24286-5-philmd@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
The code block related to IRQ starts few lines later. Move the comment and the pc_gsi_create() invocation where we start to use the IRQs. Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191018135910.24286-4-philmd@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
The GSI creation code is common to all PC machines, extract the common code. Reviewed-by: NAleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191018135910.24286-2-philmd@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 22 10月, 2019 4 次提交
-
-
由 Sergio Lopez 提交于
As a last step into splitting PCMachineState and deriving X86MachineState from it, make the functions previously extracted from pc.c to x86.c independent from PCMachineState, using X86MachineState instead. Signed-off-by: NSergio Lopez <slp@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Paolo Bonzini 提交于
Split up PCMachineState and PCMachineClass and derive X86MachineState and X86MachineClass from them. This allows sharing code with non-PC x86 machine types. Signed-off-by: NSergio Lopez <slp@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Sergio Lopez 提交于
Move x86 functions that will be shared between PC and non-PC machine types to x86.c, along with their helpers. Signed-off-by: NSergio Lopez <slp@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
-
由 Sergio Lopez 提交于
The following functions are named *pc* but are not PC-machine specific but generic to the X86 architecture, rename them: load_linux -> x86_load_linux pc_new_cpu -> x86_new_cpu pc_cpus_init -> x86_cpus_init pc_cpu_index_to_props -> x86_cpu_index_to_props pc_get_default_cpu_node_id -> x86_get_default_cpu_node_id pc_possible_cpu_arch_ids -> x86_possible_cpu_arch_ids old_pc_system_rom_init -> x86_system_rom_init Signed-off-by: NSergio Lopez <slp@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 21 9月, 2019 1 次提交
-
-
由 Corey Minyard 提交于
This is so I2C devices can be found in the ACPI namespace. Currently that's only IPMI, but devices can be easily added now. Adding the devices required some PCI information, and the bus itself to be added to the PCMachineState structure. Note that this only works on Q35, the ACPI for PIIX4 is not capable of handling an SMBus device. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 21 8月, 2019 1 次提交
-
-
由 Cornelia Huck 提交于
Add 4.2 machine types for arm/i440fx/q35/s390x/spapr. For i440fx and q35, unversioned cpu models are still translated to -v1, as 0788a56b ("i386: Make unversioned CPU models be aliases") states this should only transition to the latest cpu model version in 4.3 (or later). Signed-off-by: NCornelia Huck <cohuck@redhat.com> Message-Id: <20190724103524.20916-1-cohuck@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 16 8月, 2019 3 次提交
-
-
由 Markus Armbruster 提交于
hw/boards.h pulls in almost 60 headers. The less we include it into headers, the better. As a first step, drop superfluous inclusions, and downgrade some more to what's actually needed. Gets rid of just one inclusion into a header. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-23-armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Markus Armbruster 提交于
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
-
由 Markus Armbruster 提交于
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
-
- 06 7月, 2019 1 次提交
-
-
由 Eduardo Habkost 提交于
This will make unversioned CPU models behavior depend on the machine type: * "pc-*-4.0" and older will not report them as aliases. This is done to keep compatibility with older QEMU versions after management software starts translating aliases. * "pc-*-4.1" will translate unversioned CPU models to -v1. This is done to keep compatibility with existing management software, that still relies on CPU model runnability promises. * "none" will translate unversioned CPU models to their latest version. This is planned become the default in future machine types (probably in pc-*-4.3). Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20190628002844.24894-8-ehabkost@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 21 6月, 2019 1 次提交
-
-
由 Greg Kurz 提交于
Commit c87759ce fixed a regression affecting pc-q35 machines by introducing a new pc-q35-4.0.1 machine version to be used instead of pc-q35-4.0. The only purpose was to revert the default behaviour of not using split irqchip, but the change also introduced the usual hw_compat and pc_compat bits, and wired them for pc-q35 only. This raises questions when it comes to add new compat properties for 4.0* machine versions of any architecture. Where to add them ? In 4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach all other architectures about 4.0.1. This solution isn't satisfying, especially since this is a pc-q35 specific issue. It turns out that the split irqchip default is handled in the machine option function and doesn't involve compat lists at all. Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1 machine option function. Move the compat props that were added to the 4.0.1 since c87759ce to 4.0. Even if only hw_compat_4_0_1 had an impact on other architectures, drop pc_compat_4_0_1 as well for consistency. Fixes: c87759ce "q35: Revert to kernel irqchip" Suggested-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Message-Id: <156051774276.244890.8660277280145466396.stgit@bahia.lan> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 03 6月, 2019 1 次提交
-
-
由 Alex Williamson 提交于
Commit b2fc91db ("q35: set split kernel irqchip as default") changed the default for the pc-q35-4.0 machine type to use split irqchip, which turned out to have disasterous effects on vfio-pci INTx support. KVM resampling irqfds are registered for handling these interrupts, but these are non-functional in split irqchip mode. We can't simply test for split irqchip in QEMU as userspace handling of this interrupt is a significant performance regression versus KVM handling (GeForce GPUs assigned to Windows VMs are non-functional without forcing MSI mode or re-enabling kernel irqchip). The resolution is to revert the change in default irqchip mode in the pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable branch. The qemu-q35-4.0 machine type should not be used in vfio-pci configurations for devices requiring legacy INTx support without explicitly modifying the VM configuration to use kernel irqchip. Link: https://bugs.launchpad.net/qemu/+bug/1826422 Fixes: b2fc91db ("q35: set split kernel irqchip as default") Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Message-Id: <155786484688.13873.6037015630912983760.stgit@gimli.home> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 26 4月, 2019 1 次提交
-
-
由 Cornelia Huck 提交于
Add 4.1 machine types for arm/i440fx/q35/s390x/spapr. Signed-off-by: NCornelia Huck <cohuck@redhat.com> Message-Id: <20190411102025.22559-1-cohuck@redhat.com> Acked-by: NGreg Kurz <groug@kaod.org> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 11 3月, 2019 1 次提交
-
-
由 Eric Auger 提交于
As NVDIMM support is looming for ARM and SPAPR, let's move the acpi_nvdimm_state to the generic machine struct instead of duplicating the same code in several machines. It is also renamed into nvdimms_state and becomes a pointer. nvdimm and nvdimm-persistence become generic machine options. They become guarded by a nvdimm_supported machine class member. We also add a description for those options. Signed-off-by: NEric Auger <eric.auger@redhat.com> Suggested-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <20190308182053.5487-3-eric.auger@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 28 2月, 2019 2 次提交
-
-
由 Corey Minyard 提交于
Migration capability is being added for pm_smbus and SMBus devices. This change will allow backwards compatibility to be kept when migrating back to an old qemu version. Add a bool to the machine class tho keep smbus migration from happening. Future changes will use this. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Corey Minyard 提交于
smbus.c and smbus.h had device side code, master side code, and smbus.h has some smbus_eeprom.c definitions. Split them into separate files. Signed-off-by: NCorey Minyard <cminyard@mvista.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
-
- 05 2月, 2019 1 次提交
-
-
由 Stefano Garzarella 提交于
In order to avoid migration issues, we enable PVH only for machine type >= 4.0 Suggested-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NStefano Garzarella <sgarzare@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 08 1月, 2019 1 次提交
-
-
由 Paolo Bonzini 提交于
This function is only needed when Q35 is in use. Moving it to the same file that uses it lets you disable the entire USB subsystem in x86_64-softmmu.mak; of course doing that will cause -usb to break horribly, but one thing at a time. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Message-id: 1545064358-4601-1-git-send-email-pbonzini@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 07 1月, 2019 5 次提交
-
-
由 Marc-André Lureau 提交于
Use static arrays instead. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Marc-André Lureau 提交于
Use static arrays instead. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Marc-André Lureau 提交于
Use static arrays instead. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Marc-André Lureau 提交于
Use static arrays instead. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Marc-André Lureau 提交于
Use static arrays instead. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NCornelia Huck <cohuck@redhat.com> Acked-by: NEduardo Habkost <ehabkost@redhat.com>
-