aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2019-10-24spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivateDavid Gibson3-64/+58
It turns out that all the logic in the SpaprIrq::reset hooks (and some in the SpaprIrq::post_load hooks) isn't really related to resetting the irq backend (that's handled by the backends' own reset routines). Rather its about getting the backend ready to be the active interrupt controller or stopping being the active interrupt controller - reset (and post_load) is just the only time that changes at present. To make this flow clearer, move the logic into the explicit backend activate and deactivate hooks. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr: Remove SpaprIrq::init_kvm hookDavid Gibson1-49/+25
This hook is a bit odd. The only caller is spapr_irq_init_kvm(), but it explicitly takes an SpaprIrq *, so it's never really called through the current SpaprIrq. Essentially this is just a way of passing through a function pointer so that spapr_irq_init_kvm() can handle some configuration and error handling logic without duplicating it between the xics and xive reset paths. So, make it just take that function pointer. Because of earlier reworks to the KVM connect/disconnect code in the xics and xive backends we can also eliminate some wrapper functions and streamline error handling a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routinesDavid Gibson3-33/+20
Both XICS and XIVE have routines to connect and disconnect KVM with similar but not identical signatures. This adjusts them to match exactly, which will be useful for further cleanups later. While we're there, we add an explicit return value to the connect path to streamline error reporting in the callers. We remove error reporting the disconnect path. In the XICS case this wasn't used at all. In the XIVE case the only error case was if the KVM device was set up, but KVM didn't have the capability to do so which is pretty obviously impossible. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Move dt_populate from SpaprIrq to SpaprInterruptControllerDavid Gibson4-77/+76
This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Move print_info from SpaprIrq to SpaprInterruptControllerDavid Gibson4-37/+39
This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Move set_irq from SpaprIrq to SpaprInterruptControllerDavid Gibson3-31/+31
This method depends only on the active irq controller. Now that we've formalized the notion of active controller we can dispatch directly through that, rather than dispatching via SpaprIrq with the dual version having to do a second conditional dispatch. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr: Formalize notion of active interrupt controllerDavid Gibson1-0/+51
spapr now has the mechanism of constructing both XICS and XIVE instances of the SpaprInterruptController interface. However, only one of the interrupt controllers will actually be active at any given time, depending on feature negotiation with the guest. This is handled in the current code via spapr_irq_current() which checks the OV5 vector from feature negotiation to determine the current backend. Determining the active controller at the point we need it like this can be pretty confusing, because it makes it very non obvious at what points the active controller can change. This can make it difficult to reason about the code and where a change of active controller could appear in sequence with other events. Make this mechanism more explicit by adding an 'active_intc' pointer and an explicit spapr_irq_update_active_intc() function to update it from the CAS state. We also add hooks on the intc backend which will get called when it is activated or deactivated. For now we just introduce the switch and hooks, later patches will actually start using them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Move irq claim and free from SpaprIrq to ↵David Gibson3-111/+99
SpaprInterruptController These methods, like cpu_intc_create, really belong to the interrupt controller, but need to be called on all possible intcs. Like cpu_intc_create, therefore, make them methods on the intc and always call it for all existing intcs. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Move cpu_intc_create from SpaprIrq to ↵David Gibson4-59/+68
SpaprInterruptController This method essentially represents code which belongs to the interrupt controller, but needs to be called on all possible intcs, rather than just the currently active one. The "dual" version therefore calls into the xics and xive versions confusingly. Handle this more directly, by making it instead a method on the intc backend, and always calling it on every backend that exists. While we're there, streamline the error reporting a bit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr, xics, xive: Introduce SpaprInterruptController QOM interfaceDavid Gibson3-0/+21
The SpaprIrq structure is used to represent ths spapr machine's irq backend. Except that it kind of conflates two concepts: one is the backend proper - a specific interrupt controller that we might or might not be using, the other is the irq configuration which covers the layout of irq space and which interrupt controllers are allowed. This leads to some pretty confusing code paths for the "dual" configuration where its hooks redirect to other SpaprIrq structures depending on the currently active irq controller. To clean this up, we start by introducing a new SpaprInterruptController QOM interface to represent strictly an interrupt controller backend, not counting anything configuration related. We implement this interface in the XICs and XIVE interrupt controllers, and in future we'll move relevant methods from SpaprIrq into it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2019-10-24spapr: Set VSMT to smp_threads by defaultGreg Kurz1-1/+6
Support for setting VSMT is available in KVM since linux-4.13. Most distros that support KVM on POWER already have it. It thus seem reasonable enough to have the default machine to set VSMT to smp_threads. This brings contiguous VCPU ids and thus brings their upper bound down to the machine's max_cpus. This is especially useful for XIVE KVM devices, which may thus allocate only one VP descriptor per VCPU. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157010411885.246126.12610015369068227139.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-10-24ppc/pnv: Use address_space_stq_be() when triggering an interrupt from PSICédric Le Goater1-3/+12
Include the XIVE_TRIGGER_PQ bit in the trigger data which is how hardware signals to the IC that the PQ bits of the interrupt source have been checked. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191007084102.29776-3-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-10-24ppc/pnv: Improve trigger data definitionCédric Le Goater2-6/+18
The trigger data is used for both triggers of a HW source interrupts, PHB, PSI, and triggers for rerouting interrupts between interrupt controllers. When an interrupt is rerouted, the trigger data follows an "END trigger" format. In that case, the remote IC needs EAS containing an END index to perform a lookup of an END. An END trigger, bit0 of word0 set to '1', is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 E=1 |1P--|BLOC| END IDX | W1 E=1 |M | END DATA | An EAS is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 |V---|BLOC| END IDX | W1 |M | END DATA | The END trigger adds an extra 'PQ' bit, bit1 of word0 set to '1', signaling that the PQ bits have been checked. That bit is unused in the initial EAS definition. When a HW device performs the trigger, the trigger data follows an "EAS trigger" format because the trigger data in that case contains an EAS index which the IC needs to look for. An EAS trigger, bit0 of word0 set to '0', is defined as : |0123|4567|0123|4567|0123|4567|0123|4567| W0 E=0 |0P--|---- ---- ---- ---- ---- ---- ----| W1 E=0 |BLOC| EAS INDEX | There is also a 'PQ' bit, bit1 of word0 to '1', signaling that the PQ bits have been checked. Introduce these new trigger bits and rename the XIVE_SRCNO macros in XIVE_EAS to reflect better the nature of the data. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20191007084102.29776-2-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-10-24xics: Make some device types not user creatableGreg Kurz1-0/+10
Some device types of the XICS model are exposed to the QEMU command line: $ ppc64-softmmu/qemu-system-ppc64 -device help | grep ic[sp] name "icp" name "ics" name "ics-spapr" name "pnv-icp", desc "PowerNV ICP" These are internal devices that shouldn't be instantiable by the user. By the way, they can't be because their respective realize functions expect link properties that can't be set from the command line: qemu-system-ppc64: -device icp: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device ics: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device ics-spapr: required link 'xics' not found: Property '.xics' not found qemu-system-ppc64: -device pnv-icp: required link 'xics' not found: Property '.xics' not found Hide them by setting dc->user_creatable to false in the base class "icp" and "ics" init functions. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157017826724.337875.14822177178282524024.stgit@bahia.lan> Message-Id: <157045578962.865784.8551555523533955113.stgit@bahia.lan> [dwg: Folded reason comment into base patch] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-10-24xive: Make some device types not user creatableGreg Kurz1-0/+15
Some device types of the XIVE model are exposed to the QEMU command line: $ ppc64-softmmu/qemu-system-ppc64 -device help | grep xive name "xive-end-source", desc "XIVE END Source" name "xive-source", desc "XIVE Interrupt Source" name "xive-tctx", desc "XIVE Interrupt Thread Context" These are internal devices that shouldn't be instantiable by the user. By the way, they can't be because their respective realize functions expect link properties that can't be set from the command line: qemu-system-ppc64: -device xive-source: required link 'xive' not found: Property '.xive' not found qemu-system-ppc64: -device xive-end-source: required link 'xive' not found: Property '.xive' not found qemu-system-ppc64: -device xive-tctx: required link 'cpu' not found: Property '.cpu' not found Hide them by setting dc->user_creatable to false in their respective class init functions. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157017473006.331610.2983143972519884544.stgit@bahia.lan> Message-Id: <157045578401.865784.6058183726552779559.stgit@bahia.lan> Reviewed-by: Cédric Le Goater <clg@kaod.org> [dwg: Folded comment update into base patch] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-10-22hw/arm/digic4: Inline digic4_board_setup_ram() functionPhilippe Mathieu-Daudé1-7/+2
Having the RAM creation code in a separate function is not very helpful. Move this code directly inside the board_init() function, this will later allow the board to have the QOM ownership of the RAM. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-7-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/omap1: Create the RAM in the boardPhilippe Mathieu-Daudé3-11/+17
The SDRAM is incorrectly created in the OMAP310 SoC. Move its creation in the board code, this will later allow the board to have the QOM ownership of the RAM. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-6-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/omap2: Create the RAM in the boardPhilippe Mathieu-Daudé2-11/+12
The SDRAM is incorrectly created in the OMAP2420 SoC. Move its creation in the board code, this will later allow the board to have the QOM ownership of the RAM. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-5-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/collie: Create the RAM in the boardPhilippe Mathieu-Daudé3-11/+8
The SDRAM is incorrectly created in the SA1110 SoC. Move its creation in the board code, this will later allow the board to have the QOM ownership of the RAM. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-4-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/mps2: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé2-2/+4
IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-3-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/xilinx_zynq: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé1-1/+2
IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20191021190653.9511-2-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/arm/exynos4210: Use the Samsung s3c SDHCI controllerPhilippe Mathieu-Daudé1-1/+1
The Exynos SoC has specific SDHCI registers. Use the s3c SDHCI model which handle these specific registers. This silents the following "SDHC ... not implemented" warnings so we can focus on the important registers missing: $ qemu-system-arm ... -d unimp \ -append "... root=/dev/mmcblk0 rootfstype=ext4 rw rootwait" \ -drive file=linux-build-test/rootfs/arm/rootfs-armv5.ext2,if=sd,format=raw [...] [ 25.744858] sdhci: Secure Digital Host Controller Interface driver [ 25.745862] sdhci: Copyright(c) Pierre Ossman [ 25.783188] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (12000000 Hz) SDHC rd_4b @0x80 not implemented SDHC wr_4b @0x80 <- 0x00000020 not implemented SDHC wr_4b @0x8c <- 0x00030000 not implemented SDHC rd_4b @0x80 not implemented SDHC wr_4b @0x80 <- 0xc0004100 not implemented SDHC wr_4b @0x84 <- 0x80808080 not implemented [ 26.013318] mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA [ 26.032318] Synopsys Designware Multimedia Card Interface Driver [ 42.024885] Waiting for root device /dev/mmcblk0... Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Message-id: 20191005154748.21718-5-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/sd/sdhci: Add dummy Samsung SDHCI controllerPhilippe Mathieu-Daudé1-0/+65
The Linux kernel access few S3C-specific registers [1] to set some clock. We don't care about this part for device emulation [2]. Add a dummy device to properly ignore these accesses, so we can focus on the important registers missing. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c-regs.h?h=cc014f3 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c.c?h=v5.3#n263 Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Message-id: 20191005154748.21718-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functionsPhilippe Mathieu-Daudé1-1/+2
This file keeps the various QDev blocks separated by comments. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20191005154748.21718-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-22hw/m68k/mcf5208.c: Switch to transaction-based ptimer APIPeter Maydell1-4/+5
Switch the mcf5208 code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the timer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Thomas Huth <huth@tuxfamily.org> Message-id: 20191017132905.5604-9-peter.maydell@linaro.org
2019-10-22hw/watchdog/etraxfs_timer.c: Switch to transaction-based ptimer APIPeter Maydell1-10/+13
Switch the etraxfs_timer code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the timer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017132905.5604-7-peter.maydell@linaro.org
2019-10-22hw/timer/altera_timer.c: Switch to transaction-based ptimer APIPeter Maydell1-4/+9
Switch the altera_timer code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the timer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017132905.5604-6-peter.maydell@linaro.org
2019-10-22hw/timer/lm32_timer: Switch to transaction-based ptimer APIPeter Maydell1-4/+9
Switch the lm32_timer code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the ytimer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017132905.5604-4-peter.maydell@linaro.org
2019-10-22hw/timer/sh_timer: Switch to transaction-based ptimer APIPeter Maydell1-4/+9
Switch the sh_timer code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the timer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017132905.5604-3-peter.maydell@linaro.org
2019-10-22hw/timer/puv3_ost.c: Switch to transaction-based ptimer APIPeter Maydell1-4/+5
Switch the puv3_ost code away from bottom-half based ptimers to the new transaction-based ptimer API. This just requires adding begin/commit calls around the various places that modify the ptimer state, and using the new ptimer_init() function to create the timer. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017132905.5604-2-peter.maydell@linaro.org
2019-10-22hw/timer/arm_mptimer.c: Undo accidental rename of arm_mptimer_init()Peter Maydell1-2/+2
In commit b01422622b we did an automated rename of the ptimer_init() function to ptimer_init_with_bh(). Unfortunately this caught the unrelated arm_mptimer_init() function. Undo that accidental renaming. Fixes: b01422622b7c7293196fdaf1dbb4f495af44ecf9 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20191017133331.5901-1-peter.maydell@linaro.org
2019-10-22hw/timer/exynos4210_mct: Initialize ptimer before starting itGuenter Roeck1-1/+1
When booting a recent Linux kernel, the qemu message "Timer with delta zero, disabling" is seen, apparently because a ptimer is started before being initialized. Fix the problem by initializing the offending ptimer before starting it. The bug is effectively harmless in the old QEMUBH setup because the sequence of events is: * the delta zero means the timer expires immediately * ptimer_reload() arranges for exynos4210_gfrc_event() to be called * ptimer_reload() notices the zero delta and disables the timer * later, the QEMUBH runs, and exynos4210_gfrc_event() correctly configures the timer and restarts it In the new transaction based API the bug is still harmless, but differences of when the callback function runs mean the message is not printed any more: * ptimer_run() does nothing as it's inside a transaction block * ptimer_transaction_commit() sees it has work to do and calls ptimer_reload() * the zero delta means the timer expires immediately * ptimer_reload() calls exynos4210_gfrc_event() directly * exynos4210_gfrc_event() configures the timer * the delta is no longer zero so ptimer_reload() doesn't complain (the zero-delta test is after the trigger-callback in the ptimer_reload() function) Regardless, the behaviour here was not intentional, and we should just program the ptimer correctly to start with. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20191018143149.9216-1-peter.maydell@linaro.org [PMM: Expansion/clarification of the commit message: the message is about a zero delta, not a zero period; added detail to the commit message of the analysis of what is happening and why the kernel boots even with the message; added note that the message goes away with the new ptimer API] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-18Merge remote-tracking branch ↵Peter Maydell1-69/+390
'remotes/kraxel/tags/audio-20191018-pull-request' into staging audio: bugfixes, pa connection and stream naming. audio: 5.1/7.1 support for alsa, pa and usb-audio. # gpg: Signature made Fri 18 Oct 2019 08:41:26 BST # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/audio-20191018-pull-request: paaudio: fix channel order for usb-audio 5.1 and 7.1 streams usbaudio: change playback counters to 64 bit usb-audio: support more than two channels of audio usb-audio: do not count on avail bytes actually available audio: basic support for multichannel audio audio: replace shift in audio_pcm_info with bytes_per_frame audio: support more than two channels in volume setting paaudio: get/put_buffer functions audio: make mixeng optional audio: add mixing-engine option (documentation) audio: paaudio: ability to specify stream name audio: paaudio: fix connection and stream name audio: fix parameter dereference before NULL check Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-18usbaudio: change playback counters to 64 bitKővágó, Zoltán1-6/+8
With stereo playback, they need about 375 minutes of continuous audio playback to overflow, which is usually not a problem (as stopping and later resuming playback resets the counters). But with 7.1 audio, they only need about 95 minutes to overflow. After the overflow, the buf->prod % USBAUDIO_PACKET_SIZE(channels) assertion no longer holds true, which will result in overflowing the buffer. With 64 bit variables, it would take about 762000 years to overflow. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: ff866985ed369f1e18ea7c70da6a7fce8e241deb.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18usb-audio: support more than two channels of audioKővágó, Zoltán1-53/+366
This commit adds support for 5.1 and 7.1 audio playback. This commit adds a new property to usb-audio: * multi=on|off Whether to enable the 5.1 and 7.1 audio support. When off (default) it continues to emulate the old stereo-only device. When on, it emulates a slightly different audio device that supports 5.1 and 7.1 audio. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 98e96606228afa907fa238eac26573d5af63434a.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18usb-audio: do not count on avail bytes actually availableKővágó, Zoltán1-11/+17
This assumption is no longer true when mixeng is turned off. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: d63f4d39a0ee7a2e4e7e4a2eb005ba79120eaf1d.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-17Merge remote-tracking branch ↵Peter Maydell11-48/+41
'remotes/ehabkost/tags/machine-next-pull-request' into staging x86 and machine queue, 2019-10-15 Features: * Snowridge-v2 (no MPX) CPU model (Xiaoyao Li) Bug fixes: * cpu-plug-test: fix device_add for pc/q35 machines (Igor Mammedov) * Fix legacy guest with xsave panic on older Linux kernel (Bingsong Si) * Omit all-zeroes entries from KVM CPUID table (Eduardo Habkost) Cleanups: * Convert reset handlers to DeviceReset (Philippe Mathieu-Daudé) * MachineClass::auto_enable_numa field (Tao Xu) * target/i386/cpu.h cleanups (Tao Xu) * memory_device_get_free_addr() cleanups (Wei Yang) # gpg: Signature made Tue 15 Oct 2019 22:35:43 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/machine-next-pull-request: target/i386: Add Snowridge-v2 (no MPX) CPU model i386: Omit all-zeroes entries from KVM CPUID table i386: Fix legacy guest with xsave panic on host kvm without update cpuid. target/i386: drop the duplicated definition of cpuid AVX512_VBMI macro target/i386: clean up comments over 80 chars per line memory-device: break the loop if tmp exceed the hinted range memory-device: not necessary to use goto for the last check hw/misc/vmcoreinfo: Add comment about reset handler hw/input/lm832x: Convert reset handler to DeviceReset hw/isa/vt82c686: Convert reset handler to DeviceReset hw/ide/via82c: Convert reset handler to DeviceReset hw/ide/sii3112: Convert reset handler to DeviceReset hw/ide/piix: Convert reset handler to DeviceReset hw/isa/piix4: Convert reset handler to DeviceReset hw/acpi/piix4: Convert reset handler to DeviceReset numa: Introduce MachineClass::auto_enable_numa for implicit NUMA node tests: cpu-plug-test: fix device_add for pc/q35 machines tests: add qtest_qmp_device_add_qdict() helper Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-17Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell12-39/+879
virtio, vhost, acpi: features, fixes, tests ARM ACPI memory hotplug support + tests for new arm/virt ACPI tables. Virtio fs support (no migration). A vhost-user reconnect bugfix. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 15 Oct 2019 22:02:19 BST # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: virtio: add vhost-user-fs-pci device virtio: add vhost-user-fs base device virtio: Add virtio_fs linux headers tests/acpi: add expected tables for arm/virt tests: document how to update acpi tables tests: Add bios tests to arm/virt tests: allow empty expected files tests/acpi: add empty files tests: Update ACPI tables list for upcoming arm/virt tests docs/specs: Add ACPI GED documentation hw/arm: Use GED for system_powerdown event hw/arm: Factor out powerdown notifier from GPIO hw/arm/virt-acpi-build: Add PC-DIMM in SRAT hw/arm/virt: Enable device memory cold/hot plug with ACPI boot hw/arm/virt: Add memory hotplug framework hw/acpi: Add ACPI Generic Event Device Support hw/acpi: Do not create memory hotplug method when handler is not defined hw/acpi: Make ACPI IO address space configurable vhost-user: save features if the char dev is closed Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-15memory-device: break the loop if tmp exceed the hinted rangeWei Yang1-0/+2
The memory-device list built by memory_device_build_list is ordered by its address, this means if the tmp range exceed the hinted range, all the following range will not overlap with it. And this won't change default pc-dimm mapping and address assignment stay the same as before this change. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20190730003740.20694-3-richardw.yang@linux.intel.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15memory-device: not necessary to use goto for the last checkWei Yang1-1/+0
We are already at the last condition check. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20190730003740.20694-2-richardw.yang@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/misc/vmcoreinfo: Add comment about reset handlerPhilippe Mathieu-Daudé1-0/+4
The VM coreinfo device does not sit on a bus, so it won't be reset automatically. This is why it calls qemu_register_reset(). Add a comment about it, so we don't convert its reset handler to a DeviceReset method. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-9-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/input/lm832x: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-7/+5
The LM8323 key-scan controller is a I2C device, it will be reset when the I2C bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-8-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/isa/vt82c686: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-7/+4
The VIA VT82C686 Southbridge is a PCI device, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-7-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/ide/via82c: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-6/+4
The VIA82C686B IDE controller is a PCI device, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-6-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/ide/sii3112: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-4/+3
The SiI3112A SATA controller is a PCI device, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-5-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/ide/piix: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-5/+4
The PIIX/IDE is a PCI device within a PIIX chipset, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-4-philmd@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/isa/piix4: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-4/+3
The PIIX4/ISA is a PCI device within the PIIX4 chipset, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-3-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/acpi/piix4: Convert reset handler to DeviceResetPhilippe Mathieu-Daudé1-4/+3
The PIIX4/PM is a PCI device within the PIIX4 chipset, it will be reset when the PCI bus it stands on is reset. Convert its reset handler into a proper Device reset method. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191010131527.32513-2-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15numa: Introduce MachineClass::auto_enable_numa for implicit NUMA nodeTao Xu2-10/+9
Add MachineClass::auto_enable_numa field. When it is true, a NUMA node is expected to be created implicitly. Acked-by: David Gibson <david@gibson.dropbear.id.au> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190905083238.1799-1-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-10-15hw/misc/bcm2835_mbox: Add trace eventsPhilippe Mathieu-Daudé3-0/+13
Add trace events for read/write accesses and IRQ. Properties are structures used for the ARM particular MBOX. Since one call in bcm2835_property.c concerns the mbox block, name this trace event in the same bcm2835_mbox* namespace. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190926173428.10713-8-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.1 at 2025-01-25 05:05:31 +0000