- 23 3月, 2016 8 次提交
-
-
由 Rutuja Shah 提交于
This patch replaces get_ticks_per_sec() calls with the macro NANOSECONDS_PER_SECOND. Also, as there are no callers, get_ticks_per_sec() is then removed. This replacement improves the readability and understandability of code. For example, timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50)); NANOSECONDS_PER_SECOND makes it obvious that qemu_clock_get_ns matches the unit of the expression on the right side of the plus. Signed-off-by: NRutuja Shah <rutu.shah.26@gmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
DMA_transfer_handler is actually an ISA thing, and as such has no business in qemu-common.h. Move it to hw/isa/isa.h, and rename it to IsaDmaTransferHandler. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
qemu-common.h should only be included by .c files. Its file comment explains why: "No header file should depend on qemu-common.h, as this would easily lead to circular header dependencies." hw/pci/pci.h includes qemu-common.h, but its users only need pcibus_t and PCIHostDeviceAddress from it. Move them to hw/pci/pci.h and drop the ill-advised include. Include hw/pci/pci.h where the moved stuff is now missing. Except we can't in target-i386/kvm_i386.h, because that would break the i386-linux-user compile. Add PCIHostDeviceAddress to qemu/typedefs.h instead. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
qemu-common.h should only be included by .c files. Its file comment explains why: "No header file should depend on qemu-common.h, as this would easily lead to circular header dependencies." hw/hw.h includes qemu-common.h, but its users generally need only hw_error() and qemu/module.h from it. Move the former to hw/hw.h, include the latter there, and drop the ill-advised include. hw/misc/cbus.c now misses hw_error(), so include hw/hw.h there. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
Manually drop redundant includes that scripts/clean-includes misses, e.g. because they're hidden in generator programs, or they use the wrong kind of delimiter. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
Re-run scripts/clean-includes to apply the previous commit's corrections and updates. Besides redundant qemu/typedefs.h, this only finds a redundant config-host.h include in ui/egl-helpers.c. No idea how that escaped the previous runs. Some manual whitespace trimming around dropped includes squashed in. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Markus Armbruster 提交于
Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: NMarkus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 18 3月, 2016 1 次提交
-
-
由 Eric Blake 提交于
Simple unions were carrying a special case that hid their 'data' QMP member from the resulting C struct, via the hack method QAPISchemaObjectTypeVariant.simple_union_type(). But by using the work we started by unboxing flat union and alternate branches, coupled with the ability to visit the members of an implicit type, we can now expose the simple union's implicit type in qapi-types.h: | struct q_obj_ImageInfoSpecificQCow2_wrapper { | ImageInfoSpecificQCow2 *data; | }; | | struct q_obj_ImageInfoSpecificVmdk_wrapper { | ImageInfoSpecificVmdk *data; | }; ... | struct ImageInfoSpecific { | ImageInfoSpecificKind type; | union { /* union tag is @type */ | void *data; |- ImageInfoSpecificQCow2 *qcow2; |- ImageInfoSpecificVmdk *vmdk; |+ q_obj_ImageInfoSpecificQCow2_wrapper qcow2; |+ q_obj_ImageInfoSpecificVmdk_wrapper vmdk; | } u; | }; Doing this removes asymmetry between QAPI's QMP side and its C side (both sides now expose 'data'), and means that the treatment of a simple union as sugar for a flat union is now equivalent in both languages (previously the two approaches used a different layer of dereferencing, where the simple union could be converted to a flat union with equivalent C layout but different {} on the wire, or to an equivalent QMP wire form but with different C representation). Using the implicit type also lets us get rid of the simple_union_type() hack. Of course, now all clients of simple unions have to adjust from using su->u.member to using su->u.member.data; while this touches a number of files in the tree, some earlier cleanup patches helped minimize the change to the initialization of a temporary variable rather than every single member access. The generated qapi-visit.c code is also affected by the layout change: |@@ -7393,10 +7393,10 @@ void visit_type_ImageInfoSpecific_member | } | switch (obj->type) { | case IMAGE_INFO_SPECIFIC_KIND_QCOW2: |- visit_type_ImageInfoSpecificQCow2(v, "data", &obj->u.qcow2, &err); |+ visit_type_q_obj_ImageInfoSpecificQCow2_wrapper_members(v, &obj->u.qcow2, &err); | break; | case IMAGE_INFO_SPECIFIC_KIND_VMDK: |- visit_type_ImageInfoSpecificVmdk(v, "data", &obj->u.vmdk, &err); |+ visit_type_q_obj_ImageInfoSpecificVmdk_wrapper_members(v, &obj->u.vmdk, &err); | break; | default: | abort(); Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <1458254921-17042-13-git-send-email-eblake@redhat.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-
- 17 3月, 2016 21 次提交
-
-
由 Max Reitz 提交于
Before this patch, blk_new() automatically assigned a name to the new BlockBackend and considered it referenced by the monitor. This patch removes the implicit monitor_add_blk() call from blk_new() (and consequently the monitor_remove_blk() call from blk_delete(), too) and thus blk_new() (and related functions) no longer take a BB name argument. In fact, there is only a single point where blk_new()/blk_new_open() is called and the new BB is monitor-owned, and that is in blockdev_init(). Besides thus relieving us from having to invent names for all of the BBs we use in qemu-img, this fixes a bug where qemu cannot create a new image if there already is a monitor-owned BB named "image". If a BB and its BDS tree are created in a single operation, as of this patch the BDS tree will be created before the BB is given a name (whereas it was the other way around before). This results in minor change to the output of iotest 087, whose reference output is amended accordingly. Signed-off-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eduardo Habkost 提交于
The only remaining users of machine_init() only call qemu_add_opts(). Rename machine_init() to opts_init() and move it closer to the qemu_add_opts() calls on vl.c. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Change all machine_init() users that simply call type_register*() to use type_init(). Cc: Evgeny Voevodin <e.voevodin@samsung.com> Cc: Maksim Kozlov <m.kozlov@samsung.com> Cc: Igor Mitsyanko <i.mitsyanko@gmail.com> Cc: Dmitry Solodkiy <d.solodkiy@samsung.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Andrzej Zaborowski <balrogg@gmail.com> Cc: Michael Walle <michael@walle.cc> Cc: "Hervé Poussineau" <hpoussin@reactos.org> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Leon Alrae <leon.alrae@imgtec.com> Cc: Alexander Graf <agraf@suse.de> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Blue Swirl <blauwirbel@gmail.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Peter Maydell 提交于
The SD card object is not a SysBusDevice, so don't create it with qdev_create() if we're not assigning it to a specific bus; use object_new() instead. This was causing 'info qtree' to segfault on boards with SD cards, because qdev_create(NULL, TYPE_FOO) puts the created object on the system bus, and then we may try to run functions like sysbus_dev_print() on it, which fail when casting the object to SysBusDevice. (This is the same mistake that we made with the NAND device and fixed in commit 6749695e.) Reported-by: Nxiaoqiang.zhao <zxq_yx_007@163.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: Nxiaoqiang.zhao <zxq_yx_007@163.com> Message-id: 1458061009-7733-1-git-send-email-peter.maydell@linaro.org
-
由 Grégory ESTRADE 提交于
At present, all DMA transfers complete inline (so a looping descriptor queue will lock up the device). We also do not model pause/abort, arbitrarion/priority, or debug features. Signed-off-by: NGrégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-6-git-send-email-Andrew.Baumann@microsoft.com [AB: implement 2D mode, cleanup/refactoring for upstream submission] Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Grégory ESTRADE 提交于
The property channel driver now interfaces with the framebuffer device to query and set framebuffer parameters. As a result of this, the "get ARM RAM size" query now correctly returns the video RAM base address (not total RAM size), and the ram-size property is no longer relevant here. Signed-off-by: NGrégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-5-git-send-email-Andrew.Baumann@microsoft.com [AB: cleanup/refactoring for upstream submission] Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Grégory ESTRADE 提交于
The framebuffer occupies the upper portion of memory (64MiB by default), but it can only be controlled/configured via a system mailbox or property channel (to be added by a subsequent patch). Signed-off-by: NGrégory ESTRADE <gregory.estrade@gmail.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Message-id: 1457467526-8840-4-git-send-email-Andrew.Baumann@microsoft.com [AB: added Windows (BGR) support and cleanup/refactoring for upstream submission] Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Baumann 提交于
At present only the core UART functions (data path for tx/rx) are implemented, which is enough for UEFI to boot. The following features/registers are unimplemented: * Line/modem control * Scratch register * Extra control * Baudrate * SPI interfaces Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1457467526-8840-3-git-send-email-Andrew.Baumann@microsoft.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Baumann 提交于
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 1457467526-8840-2-git-send-email-Andrew.Baumann@microsoft.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
The new machine is a thin layer over the AST2400 ARM926-based SoC[1]. Between the minimal machine and the current SoC implementation there is enough functionality to boot an aspeed_defconfig Linux kernel to userspace. Nothing yet is specific to the Palmetto's BMC (other than using an AST2400 SoC), but creating specific machine types is preferable to a generic machine that doesn't match any particular hardware. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-5-git-send-email-andrew@aj.id.au Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
While the ASPEED AST2400 SoC[1] has a broad range of capabilities this implementation is minimal, comprising an ARM926 processor, ASPEED VIC and timer devices, and a 8250 UART. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-4-git-send-email-andrew@aj.id.au Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
Implement a basic ASPEED VIC device model for the AST2400 SoC[1], with enough functionality to boot an aspeed_defconfig Linux kernel. The model implements the 'new' (revised) register set: While the hardware exposes both the new and legacy register sets, accesses to the model's legacy register set will not be serviced (however the access will be logged). [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-3-git-send-email-andrew@aj.id.au Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Andrew Jeffery 提交于
Implement basic ASPEED timer functionality for the AST2400 SoC[1]: Up to 8 timers can independently be configured, enabled, reset and disabled. Some hardware features are not implemented, namely clock value matching and pulse generation, but the implementation is enough to boot the Linux kernel configured with aspeed_defconfig. [1] http://www.aspeedtech.com/products.php?fPath=20&rId=376Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> Message-id: 1458096317-25223-2-git-send-email-andrew@aj.id.au Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: f1f565eb9dffdeb582feb1b15ba9e8b0afcf5468.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: 9fa80b4d8c5d0f50c94e77d74f952a7a665e168f.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
EPIT, GPT and other i.MX timers are using "abstract" clocks among which a CLK_IPG_HIGH clock. On i.MX25 and i.MX31 CLK_IPG and CLK_IPG_HIGH are mapped to the same clock but on other SOC like i.MX6 they are mapped to distinct clocks. This patch add the CLK_IPG_HIGH to prepare for SOC where these 2 clocks are different. Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: 224bf650194760284cb40630e985867e1373276a.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
Most clocks supported by the CCM are useless to the qemu framework. Only clocks related to timers (EPIT, GPT, PWM, WATCHDOG, ...) are usefull to QEMU code. Therefore this patch removes clock computation handling for all clocks but: * CLK_NONE, * CLK_IPG, * CLK_32k Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: 9e7222efb349801032e60c0f6b0fbad0e5dcf648.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
This way all CCM clock defines/enums are named CLK_XXX Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: 8537df765c1713625c7a8b9aca4c7ca60b42e0c0.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jean-Christophe Dubois 提交于
GPT timer need to rollover when it reaches 0xffffffff. It also need to reset to 0 when in "restart mode" and crossing the compare 1 register. Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net> Message-id: 6e2b36117a249a78bf822dd59a390368f407136e.1456868959.git.jcd@tribudubois.net Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Wei Huang 提交于
This patch moves the common class initialization code from "virt-2.6" to the new abstract class. An empty property is added to "virt-2.6" machine. In the meanwhile, related funtions are renamed to "virt_2_6_*" for consistency. Signed-off-by: NWei Huang <wei@redhat.com> Message-id: 1457717778-17727-3-git-send-email-wei@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Wei Huang 提交于
In preparation for future ARM virt machine types, this patch creates an abstract type for all ARM machines. The current machine type in QEMU (i.e. "virt") is renamed to "virt-2.6", whose naming scheme is similar to other architectures. For the purpose of backward compatibility, "virt" is converted to an alias, pointing to "virt-2.6". With this patch, "qemu -M ?" lists the following virtual machine types along with others: virt QEMU 2.6 ARM Virtual Machine (alias of virt-2.6) virt-2.6 QEMU 2.6 ARM Virtual Machine Signed-off-by: NWei Huang <wei@redhat.com> Message-id: 1457717778-17727-2-git-send-email-wei@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 16 3月, 2016 10 次提交
-
-
由 David Gibson 提交于
vfio_container_ioctl() was a bad interface that bypassed abstraction boundaries, had semantics that sat uneasily with its name, and was unsafe in many realistic circumstances. Now that spapr-pci-vfio-host-bridge has been folded into spapr-pci-host-bridge, there are no more users, so remove it. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 David Gibson 提交于
Now that spapr-pci-vfio-host-bridge is reduced to just a stub, there is only one implementation of the finish_realize hook in sPAPRPHBClass. So, we can fold that implementation into its (single) caller, and remove the hook. That's the last thing left in sPAPRPHBClass, so that can go away as well. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
Now that the regular spapr-pci-host-bridge can handle EEH, there are only two things that spapr-pci-vfio-host-bridge does differently: 1. automatically sizes its DMA window to match the host IOMMU 2. checks if the attached VFIO container is backed by the VFIO_SPAPR_TCE_IOMMU type on the host (1) is not particularly useful, since the default window used by the regular host bridge will work with the host IOMMU configuration on all current systems anyway. Plus, automatically changing guest visible configuration (such as the DMA window) based on host settings is generally a bad idea. It's not definitively broken, since spapr-pci-vfio-host-bridge is only supposed to support VFIO devices which can't be migrated anyway, but still. (2) is not really useful, because if a guest tries to configure EEH on a different host IOMMU, the first call will fail and that will be that. It's possible there are scripts or tools out there which expect spapr-pci-vfio-host-bridge, so we don't remove it entirely. This patch reduces it to just a stub for backwards compatibility. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
Now that the EEH code is independent of the special spapr-vfio-pci-host-bridge device, we can allow it on all spapr PCI host bridges instead. We do this by changing spapr_phb_eeh_available() to be based on the vfio_eeh_as_ok() call instead of the host bridge class. Because the value of vfio_eeh_as_ok() can change with devices being hotplugged or unplugged, this can potentially lead to some strange edge cases where the guest starts using EEH, then it starts failing because of a change in status. However, it's not really any worse than the current situation. Cases that would have worked previously will still work (i.e. VFIO devices from at most one VFIO IOMMU group per vPHB), it's just that it's no longer necessary to use spapr-vfio-pci-host-bridge with the groupid pre-specified. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
The EEH operations in the spapr-vfio-pci-host-bridge no longer rely on the special groupid field in sPAPRPHBVFIOState. So we can simplify, removing the class specific callbacks with direct calls based on a simple spapr_phb_eeh_enabled() helper. For now we implement that in terms of a boolean in the class, but we'll continue to clean that up later. On its own this is a rather strange way of doing things, but it's a useful intermediate step to further cleanups. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
This switches all EEH on VFIO operations in spapr_pci_vfio.c from the broken vfio_container_ioctl() interface to the new vfio_as_eeh_op() interface. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
-
由 David Gibson 提交于
At present the code handling IBM's Enhanced Error Handling (EEH) interface on VFIO devices operates by bypassing the usual VFIO logic with vfio_container_ioctl(). That's a poorly designed interface with unclear semantics about exactly what can be operated on. In particular it operates on a single vfio container internally (hence the name), but takes an address space and group id, from which it deduces the container in a rather roundabout way. groupids are something that code outside vfio shouldn't even be aware of. This patch creates new interfaces for EEH operations. Internally we have vfio_eeh_container_op() which takes a VFIOContainer object directly. For external use we have vfio_eeh_as_ok() which determines if an AddressSpace is usable for EEH (at present this means it has a single container with exactly one group attached), and vfio_eeh_as_op() which will perform an operation on an AddressSpace in the unambiguous case, and otherwise returns an error. This interface still isn't great, but it's enough of an improvement to allow a number of cleanups in other places. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Greg Kurz 提交于
Since commit "60253ed1 rng: add request queue support to rng-random", the use of a spapr_rng device may hang vCPU threads. The following path is taken without holding the lock to the main loop mutex: h_random() rng_backend_request_entropy() rng_random_request_entropy() qemu_set_fd_handler() The consequence is that entropy_available() may be called before the vCPU thread could even queue the request: depending on the scheduling, it may happen that entropy_available() does not call random_recv()->qemu_sem_post(). The vCPU thread will then sleep forever in h_random()->qemu_sem_wait(). This could not happen before 60253ed1 because entropy_available() used to call random_recv() unconditionally. This patch ensures the lock is held to avoid the race. Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com> Reviewed-by: NCédric Le Goater <clg@fr.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
fa48b432 "target-ppc: Remove hack for ppc_hash64_load_hpte*() with HV KVM" purports to remove a hack in the handling of hash page tables (HPTs) managed by KVM instead of qemu. However, it actually went in the wrong direction. That patch requires anything looking for an external HPT (that is one not managed by the guest itself) to check both env->external_htab (for a qemu managed HPT) and kvmppc_kern_htab (for a KVM managed HPT). That's a problem because kvmppc_kern_htab is local to mmu-hash64.c, but some places which need to check for an external HPT are outside that, such as kvm_arch_get_registers(). The latter was subtly broken by the earlier patch such that gdbstub can no longer access memory. Basically a KVM managed HPT is much more like a qemu managed HPT than it is like a guest managed HPT, so the original "hack" was actually on the right track. This partially reverts fa48b432, so we again mark a KVM managed external HPT by putting a special but non-NULL value in env->external_htab. It then goes further, using that marker to eliminate the kvmppc_kern_htab global entirely. The ppc_hash64_set_external_hpt() helper function is extended to set that marker if passed a NULL value (if you're setting an external HPT, but don't have an actual HPT to set, the assumption is that it must be a KVM managed HPT). This also has some flow-on changes to the HPT access helpers, required by the above changes. Reported-by: NGreg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NGreg Kurz <gkurz@linux.vnet.ibm.com> Tested-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
-
由 David Gibson 提交于
When a Power cpu with 64-bit hash MMU has it's hash page table (HPT) pointer updated by a write to the SDR1 register we need to update some derived variables. Likewise, when the cpu is configured for an external HPT (one not in the guest memory space) some derived variables need to be updated. Currently the logic for this is (partially) duplicated in ppc_store_sdr1() and in spapr_cpu_reset(). In future we're going to need it in some other places, so make some common helpers for this update. In addition the new ppc_hash64_set_external_hpt() helper also updates SDR1 in KVM - it's not updated by the normal runtime KVM <-> qemu CPU synchronization. In a sense this belongs logically in the ppc_hash64_set_sdr1() helper, but that is called from kvm_arch_get_registers() so can't itself call cpu_synchronize_state() without infinite recursion. In practice this doesn't matter because the only other caller is TCG specific. Currently there aren't situations where updating SDR1 at runtime in KVM matters, but there are going to be in future. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NGreg Kurz <gkurz@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com>
-