aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2022-01-12ppc/pnv: use stack->pci_regs[] in pnv_pec_stk_pci_xscom_write()Daniel Henrique Barboza1-10/+10
pnv_pec_stk_pci_xscom_write() is pnv_pec_stk_pci_xscom_ops write callback. It writes values into regs in the stack->nest_regs[] array. The pnv_pec_stk_pci_xscom_read read callback, on the other hand, returns values of the stack->pci_regs[]. In fact, at this moment, the only use of stack->pci_regs[] is in pnv_pec_stk_pci_xscom_read(). There's no code that is written anything in stack->pci_regs[], which is suspicious. Considering that stack->nest_regs[] is widely used by the nested MemoryOps pnv_pec_stk_nest_xscom_ops, in both read and write callbacks, the conclusion is that we're writing the wrong array in pnv_pec_stk_pci_xscom_write(). This function should write stack->pci_regs[] instead. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220111200132.633896-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn pnv_phb4_update_regions() into staticDaniel Henrique Barboza1-26/+26
Its only callers are inside pnv_phb4.c. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Introduce user creatable pnv-phb4 devicesDaniel Henrique Barboza3-4/+89
This patch introduces pnv-phb4 user creatable devices that are created in a similar manner as pnv-phb3 devices, allowing the user to interact with the PHBs directly instead of creating PCI Express Controllers that will create a certain amount of PHBs per controller index. We accomplish this by doing the following: - add a pnv_phb4_get_stack() helper to retrieve which stack an user created phb4 would occupy; - when dealing with an user created pnv-phb4 (detected by checking if phb->stack is NULL at the start of phb4_realize()), retrieve its stack and initialize its properties as done in stk_realize(); - use 'defaults_enabled()' in stk_realize() to avoid creating and initializing a 'stack->phb' qdev that might be overwritten by an user created pnv-phb4 device. This process is wrapped into a new helper called pnv_pec_stk_default_phb_realize(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStackDaniel Henrique Barboza2-14/+8
At this moment, stack->phb is the plain PnvPHB4 device itself instead of a pointer to the device. This will present a problem when adding user creatable devices because we can't deal with this struct and the realize() callback from the user creatable device. We can't get rid of this attribute, similar to what we did when enabling pnv-phb3 user creatable devices, because pnv_phb4_update_regions() needs to access stack->phb to do its job. This function is called twice in pnv_pec_stk_update_map(), which is one of the nested xscom write callbacks (via pnv_pec_stk_nest_xscom_write()). In fact, pnv_pec_stk_update_map() code comment is explicit about how the order of the unmap/map operations relates with the PHB subregions. All of this indicates that this code is tied together in a way that we either go on a crusade, featuring lots of refactories and redesign and considerable pain, to decouple stack and phb mapping, or we allow stack update_map operations to access the associated PHB as it is today even after introducing pnv-phb4 user devices. This patch chooses the latter. Instead of getting rid of stack->phb, turn it into a PHB pointer. This will allow us to assign an user created PHB to an existing stack later. In this process, pnv_pec_stk_instance_init() is removed because stack->phb is being initialized in stk_realize() instead. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: move PHB4 XSCOM init to phb4_realize()Daniel Henrique Barboza2-292/+304
The 'stack->phb_regs_mr' PHB4 passthrough XSCOM initialization relies on 'stack->phb' being not NULL. Moving 'stack->phb_regs_mr' region_init() and add_subregion() to phb4_realize() time is a natural thing to do since it's strictly PHB related. The remaining XSCOM initialization is also related to 'stack->phb' but in a different manner. For instance, 'stack->nest_regs_mr' MemoryRegionOps, 'pnv_pec_stk_nest_xscom_ops', uses pnv_pec_stk_nest_xscom_write() as a write callback. When trying to write the PEC_NEST_STK_BAR_EN reg, pnv_pec_stk_update_map() is called. Inside this function, pnv_phb4_update_regions() is called twice. This function uses 'stack->phb' to manipulate memory regions of the phb. This is not a problem now but, when enabling user creatable phb4s, a stack that doesn't have an associated phb (i.e. stack->phb = NULL) it will cause a SIGINT during boot in pnv_phb4_update_regions(). All this can be avoided if all XSCOM realize is moved to phb4_realize(), when we have certainty about the existence of 'stack->phb'. A lot of code was moved from pnv_phb4_pec.c to pnv_phb4.c due to static constant and variables being used but the cleaner logic is worth the trouble. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: set phb4 properties in stk_realize()Daniel Henrique Barboza1-3/+3
Moving all phb4 properties setup to stk_realize() keeps this logic in a single place instead of having it scattered between stk_realize() and pec_realize(). 'phb->index' can be retrieved using stack->stack_no and pnv_phb4_pec_get_phb_id(), deprecating the use of 'phb-id' alias that was being used for this purpose in pec_realize(). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220111131027.599784-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec: use pnv_phb4_pec_get_phb_id() in pnv_pec_dt_xscom()Daniel Henrique Barboza1-3/+2
Relying on stack->phb to write the xscom DT of the PEC is something that we won't be able to do with user creatable pnv-phb4 devices. Hopefully, this can be done by using pnv_phb4_pec_get_phb_id(), which is already used by pnv_pec_realize() to set the phb-id of the stack. Use the same idea in pnv_pec_dt_xscom() to write ibm,phb-index without the need to accessing stack->phb, since stack->phb is not granted to be != NULL when user creatable phbs are introduced. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4_pec.c: move pnv_pec_phb_offset() to pnv_phb4.cDaniel Henrique Barboza2-14/+18
The logic inside pnv_pec_phb_offset() will be useful in the next patch to determine the stack that should contain a PHB4 device. Move the function to pnv_phb4.c and make it public since there's no pnv_phb4_pec.h header. While we're at it, add 'stack_index' as a parameter and make the function return 'phb-id' directly. And rename it to pnv_phb4_pec_get_phb_id() to be even clearer about the function intent. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220110143346.455901-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Move num_phbs under Pnv8ChipCédric Le Goater1-4/+3
It is not used elsewhere so that's where it belongs. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-10-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Complete user created PHB3 devicesCédric Le Goater2-0/+11
PHB3s ared SysBus devices and should be allowed to be dynamically created. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-9-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Reparent user created PHB3 devices to the PnvChipCédric Le Goater2-0/+23
The powernv machine uses the object hierarchy to populate the device tree and each device should be parented to the chip it belongs to. This is not the case for user created devices which are parented to the container "/unattached". Make sure a PHB3 device is parented to its chip by reparenting the object if necessary. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-8-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Introduce support for user created PHB3 devicesCédric Le Goater2-6/+28
PHB3 devices and PCI devices can now be added to the powernv8 machine using : -device pnv-phb3,chip-id=0,index=1 \ -device nec-usb-xhci,bus=pci.1,addr=0x0 The 'index' property identifies the PHB3 in the chip. In case of user created devices, a lookup on 'chip-id' is required to assign the owning chip. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220105212338.49899-7-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: check if root port exists in rc_config functionsDaniel Henrique Barboza1-2/+8
pnv_phb4_rc_config_read() and pnv_phb4_rc_config_write() are asserting the existence of the root port. The root port is now optional, and there will be cases where a pnv-phb4 device won't have a root port attached. Instead of asserting, check if the root port exists before read/writing into it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-6-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: make pnv-phb4-root-port user creatableDaniel Henrique Barboza1-11/+7
We want to create only the absolutely minimal amount of devices when running with -nodefaults. The root port is something that the machine can boot up without. But, to do that, we need to provide a way for the user to add them by hand. This patch makes pnv-phb4-root-port user creatable and then uses the pnv_phb_attach_root_port() helper to add a pnv_phb4_root_port only when running with default settings. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-5-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12ppc/pnv: Attach PHB3 root port device when defaults are enabledCédric Le Goater2-9/+14
This cleanups the PHB3 model a bit more since the root port is an independent device and it will ease our task when adding user created PHB3s. pnv_phb_attach_root_port() is made public in pnv.c so it can be reused with the pnv_phb4 root port later. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-4-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb4.c: add unique chassis and slot for pnv_phb4_root_portDaniel Henrique Barboza1-0/+15
A similar situation as described previously with pnv_phb3_root_port devices also happens with pnv_phb4_root_ports. The solution is the same: assign an unique chassis/slot combo for them. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-3-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12pnv_phb3.c: add unique chassis and slot for pnv_phb3_root_portDaniel Henrique Barboza1-0/+16
When creating a pnv_phb3_root_port using the command line, the first root port is created successfully, but the second fails with the following error: qemu-system-ppc64: -device pnv-phb3-root-port,bus=phb3-root.0,id=pcie.3: Can't add chassis slot, error -16 This error comes from the realize() function of its parent type, rp_realize() from TYPE_PCIE_ROOT_PORT. pcie_chassis_add_slot() fails with -EBUSY if there's an existing PCIESlot that has the same chassis/slot value, regardless of being in a different bus. One way to prevent this error is simply set chassis and slot values in the command line. However, since phb3 root buses only supports a single root port, we can just get an unique chassis/slot value by checking which root bus the pnv_phb3_root_port is going to be attached, get the equivalent phb3 device and use its chip-id and index values, which are guaranteed to be unique. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220105212338.49899-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-12spapr: Fix support of POWER5+ processorsCédric Le Goater1-4/+6
POWER5+ (ISA v2.03) processors are supported by the pseries machine but they do not have Altivec instructions. Do not advertise support for it in the DT. To be noted that this test is in contradiction with the assert in cap_vsx_apply(). Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Fabiano Rosas <farosas@linux.ibm.com> Message-Id: <20220105095142.3990430-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-01-11Merge remote-tracking branch 'remotes/philmd/tags/sdmmc-20220108' into stagingPeter Maydell1-21/+31
SD/MMC patches queue - Add SDHC support for SD card SPI-mode (Frank Chang) # gpg: Signature made Sat 08 Jan 2022 21:56:02 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd/tags/sdmmc-20220108: hw/sd: Add SDHC support for SD card SPI-mode hw/sd/sdcard: Rename Write Protect Group variables Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-11Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell14-382/+83
virtio: revert config interrupt changes Lots of fallout from config interrupt changes. Author wants to rework the patches. Let's revert quickly so others don't suffer meanwhile. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 10 Jan 2022 21:03:44 GMT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # 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: Revert "virtio: introduce macro IRTIO_CONFIG_IRQ_IDX" Revert "virtio-pci: decouple notifier from interrupt process" Revert "virtio-pci: decouple the single vector from the interrupt process" Revert "vhost: introduce new VhostOps vhost_set_config_call" Revert "vhost-vdpa: add support for config interrupt" Revert "virtio: add support for configure interrupt" Revert "vhost: add support for configure interrupt" Revert "virtio-net: add support for configure interrupt" Revert "virtio-mmio: add support for configure interrupt" Revert "virtio-pci: add support for configure interrupt" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-01-10Revert "virtio: introduce macro IRTIO_CONFIG_IRQ_IDX"Michael S. Tsirkin5-32/+2
This reverts commit bf1d85c166c19af95dbd27b1faba1d2909732323. Fixes: bf1d85c166 ("virtio: introduce macro IRTIO_CONFIG_IRQ_IDX") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-pci: decouple notifier from interrupt process"Michael S. Tsirkin1-57/+31
This reverts commit e3480ef81f6fb61cc9c04e3b5be8b7e84484fc05. Fixes: e3480ef81f ("virtio-pci: decouple notifier from interrupt process") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-pci: decouple the single vector from the interrupt process"Michael S. Tsirkin1-73/+58
This reverts commit 316011b8a74e777eb3ba03171cd701a291c28867. Fixes: 316011b8a7 ("virtio-pci: decouple the single vector from the interrupt process") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "vhost-vdpa: add support for config interrupt"Michael S. Tsirkin2-8/+0
This reverts commit 634f7c89fbd78f57d00d5d6b39c0ade9df1fe27f. Fixes: 634f7c89fb ("vhost-vdpa: add support for config interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio: add support for configure interrupt"Michael S. Tsirkin1-29/+0
This reverts commit 081f864f56307551f59c5e934e3f30a7290d0faa. Fixes: 081f864f56 ("virtio: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "vhost: add support for configure interrupt"Michael S. Tsirkin1-76/+0
This reverts commit f7220a7ce21604a4bc6260ccca4dc9068c1f27f2. Fixes: f7220a7ce2 ("vhost: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-net: add support for configure interrupt"Michael S. Tsirkin3-20/+2
This reverts commit 497679d51087090d5a22fd265d1b96cf92d49d9d. Fixes: 497679d510 ("virtio-net: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-mmio: add support for configure interrupt"Michael S. Tsirkin1-27/+0
This reverts commit d48185f1a40d4e4ed2fa2873a42b2a5eb8748256. Fixes: d48185f1a4 ("virtio-mmio: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-10Revert "virtio-pci: add support for configure interrupt"Michael S. Tsirkin2-83/+13
This reverts commit d5d24d859c3957ea1674d0e102f96439cdbfe93a. Fixes: d5d24d859c ("virtio-pci: add support for configure interrupt") Cc: "Cindy Lu" <lulu@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-09macfb: fix VRAM dirty memory region loggingMark Cave-Ayland1-1/+1
The macfb VRAM memory region was configured with coalescing rather than dirty memory logging enabled, causing some areas of the screen not to redraw after a full screen update. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 8ac919a065 ("hw/m68k: add Nubus macfb video card") Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20220108164147.30813-1-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-09q800: fix segfault with invalid MacROMLaurent Vivier1-2/+3
"qemu-system-m68k -M q800 -bios /dev/null" crashes with a segfault in q800_init(). This happens because the code doesn't check that rom_ptr() returned a non-NULL pointer . To avoid NULL pointer, don't allow 0 sized file and use bios_size with rom_ptr(). Resolves: https://gitlab.com/qemu-project/qemu/-/issues/756 Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20220107105049.961489-1-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-01-09hw: m68k: Add virt compat machine type for 7.0Laurent Vivier1-1/+8
Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20211218114340.1856757-1-laurent@vivier.eu>
2022-01-08hw/riscv: Use error_fatal for SoC realisationAlistair Francis4-4/+4
When realising the SoC use error_fatal instead of error_abort as the process can fail and report useful information to the user. Currently a user can see this: $ ../qemu/bld/qemu-system-riscv64 -M sifive_u -S -monitor stdio -display none -drive if=pflash QEMU 6.1.93 monitor - type 'help' for more information (qemu) Unexpected error in sifive_u_otp_realize() at ../hw/misc/sifive_u_otp.c:229: qemu-system-riscv64: OTP drive size < 16K Aborted (core dumped) Which this patch addresses Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-8-alistair.francis@opensource.wdc.com>
2022-01-08hw/intc: sifive_plic: Cleanup remaining functionsAlistair Francis1-87/+22
We can remove the original sifive_plic_irqs_pending() function and instead just use the sifive_plic_claim() function (renamed to sifive_plic_claimed()) to determine if any interrupts are pending. This requires move the side effects outside of sifive_plic_claimed(), but as they are only invoked once that isn't a problem. We have also removed all of the old #ifdef debugging logs, so let's cleanup the last remaining debug function while we are here. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-5-alistair.francis@opensource.wdc.com>
2022-01-08hw/intc: sifive_plic: Cleanup the read functionAlistair Francis1-44/+11
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-4-alistair.francis@opensource.wdc.com>
2022-01-08hw/intc: sifive_plic: Cleanup the write functionAlistair Francis1-49/+27
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-3-alistair.francis@opensource.wdc.com>
2022-01-08hw/intc: sifive_plic: Add a reset functionAlistair Francis1-0/+18
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220105213937.1113508-2-alistair.francis@opensource.wdc.com>
2022-01-08hw/dma: sifive_pdma: permit 4/8-byte access size of PDMA registersJim Shu1-0/+4
It's obvious that PDMA supports 64-bit access of 64-bit registers, and in previous commit, we confirm that PDMA supports 32-bit access of both 32/64-bit registers. Thus, we configure 32/64-bit memory access of PDMA registers as valid in general. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20220104063408.658169-3-jim.shu@sifive.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-08hw/dma: sifive_pdma: support high 32-bit access of 64-bit registerJim Shu1-22/+155
Real PDMA supports high 32-bit read/write memory access of 64-bit register. The following result is PDMA tested in U-Boot on Unmatched board: 1. Real PDMA allows high 32-bit read/write to 64-bit register. => mw.l 0x3000000 0x0 <= Disclaim channel 0 => mw.l 0x3000000 0x1 <= Claim channel 0 => mw.l 0x3000010 0x80000000 <= Write low 32-bit NextDest (NextDest = 0x280000000) => mw.l 0x3000014 0x2 <= Write high 32-bit NextDest => md.l 0x3000010 1 <= Dump low 32-bit NextDest 03000010: 80000000 => md.l 0x3000014 1 <= Dump high 32-bit NextDest 03000014: 00000002 => mw.l 0x3000018 0x80001000 <= Write low 32-bit NextSrc (NextSrc = 0x280001000) => mw.l 0x300001c 0x2 <= Write high 32-bit NextSrc => md.l 0x3000018 1 <= Dump low 32-bit NextSrc 03000010: 80001000 => md.l 0x300001c 1 <= Dump high 32-bit NextSrc 03000014: 00000002 2. PDMA transfer from 0x280001000 to 0x280000000 is OK. => mw.q 0x3000008 0x4 <= NextBytes = 4 => mw.l 0x3000004 0x22000000 <= wsize = rsize = 2 (2^2 = 4 bytes) => mw.l 0x280000000 0x87654321 <= Fill test data to dst => mw.l 0x280001000 0x12345678 <= Fill test data to src => md.l 0x280000000 1; md.l 0x280001000 1 <= Dump src/dst memory contents 280000000: 87654321 !Ce. 280001000: 12345678 xV4. => md.l 0x3000000 8 <= Dump PDMA status 03000000: 00000001 22000000 00000004 00000000 ......."........ 03000010: 80000000 00000002 80001000 00000002 ................ => mw.l 0x3000000 0x3 <= Set channel 0 run and claim bits => md.l 0x3000000 8 <= Dump PDMA status 03000000: 40000001 22000000 00000004 00000000 ...@..."........ 03000010: 80000000 00000002 80001000 00000002 ................ => md.l 0x280000000 1; md.l 0x280001000 1 <= Dump src/dst memory contents 280000000: 12345678 xV4. 280001000: 12345678 xV4. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20220104063408.658169-2-jim.shu@sifive.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07Merge tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson34-392/+893
into staging virtio,pci,pc: features,fixes,cleanups New virtio mem options. A vhost-user cleanup. Control over smbios entry point type. Config interrupt support for vdpa. Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Fri 07 Jan 2022 04:30:41 PM PST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # 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 * tag 'for_upstream' of git://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (55 commits) tests: acpi: Add updated TPM related tables acpi: tpm: Add missing device identification objects tests: acpi: prepare for updated TPM related tables virtio/vhost-vsock: don't double close vhostfd, remove redundant cleanup hw/scsi/vhost-scsi: don't double close vhostfd on error hw/scsi/vhost-scsi: don't leak vqs on error docs: reSTify virtio-balloon-stats documentation and move to docs/interop hw/i386/pc: Add missing property descriptions acpihp: simplify acpi_pcihp_disable_root_bus tests: acpi: SLIC: update expected blobs tests: acpi: add SLIC table test tests: acpi: whitelist expected blobs before changing them acpi: fix QEMU crash when started with SLIC table intel-iommu: correctly check passthrough during translation virtio-mem: Set "unplugged-inaccessible=auto" for the 7.0 machine on x86 virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE linux-headers: sync VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE MAINTAINERS: Add a separate entry for acpi/VIOT tables virtio: signal after wrapping packed used_idx virtio-mem: Support "prealloc=on" option ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-01-07acpi: tpm: Add missing device identification objectsStefan Berger2-0/+8
Add missing TPM device identification objects _STR and _UID. They will appear as files 'description' and 'uid' under Linux sysfs. Following inspection of sysfs entries for hardware TPMs we chose uid '1'. Cc: Shannon Zhao <shannon.zhaosl@gmail.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Ani Sinha <ani@anisinha.ca> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/708 Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Shannon Zhao <shannon.zhaosl@gmail.com> Message-id: 20211223022310.575496-3-stefanb@linux.ibm.com Message-Id: <20220104175806.872996-3-stefanb@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2022-01-07virtio/vhost-vsock: don't double close vhostfd, remove redundant cleanupDaniil Tatianin1-6/+5
In case of an error during initialization in vhost_dev_init, vhostfd is closed in vhost_dev_cleanup. Remove close from err_virtio as it's both redundant and causes a double close on vhostfd. Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Message-Id: <20211129125204.1108088-1-d-tatianin@yandex-team.ru> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07hw/scsi/vhost-scsi: don't double close vhostfd on errorDaniil Tatianin1-1/+8
vhost_dev_init calls vhost_dev_cleanup on error, which closes vhostfd, don't double close it. Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Message-Id: <20211129132358.1110372-2-d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07hw/scsi/vhost-scsi: don't leak vqs on errorDaniil Tatianin1-2/+4
vhost_dev_init calls vhost_dev_cleanup in case of an error during initialization, which zeroes out the entire vsc->dev as well as the vsc->dev.vqs pointer. This prevents us from properly freeing it in free_vqs. Keep a local copy of the pointer so we can free it later. Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Message-Id: <20211129132358.1110372-1-d-tatianin@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07hw/i386/pc: Add missing property descriptionsThomas Huth1-0/+8
When running "qemu-system-x86_64 -M pc,help" I noticed that some properties were still missing their description. Add them now so that users get at least a slightly better idea what they are all about. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211206134255.94784-1-thuth@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07acpihp: simplify acpi_pcihp_disable_root_busAni Sinha1-7/+2
Get rid of the static variable that keeps track of whether hotplug has been disabled on the root pci bus. Simply use qbus_is_hotpluggable() api to perform the same check. This eliminates additional if conditional and simplifies the function. Signed-off-by: Ani Sinha <ani@anisinha.ca> Message-Id: <1640764674-7784-1-git-send-email-ani@anirban.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07acpi: fix QEMU crash when started with SLIC tableIgor Mammedov2-2/+4
if QEMU is started with used provided SLIC table blob, -acpitable sig=SLIC,oem_id='CRASH ',oem_table_id="ME",oem_rev=00002210,asl_compiler_id="",asl_compiler_rev=00000000,data=/dev/null it will assert with: hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) and following backtrace: ... build_append_padded_str (array=0x555556afe320, str=0x555556afdb2e "CRASH ME", maxlen=0x6, pad=0x20) at hw/acpi/aml-build.c:61 acpi_table_begin (desc=0x7fffffffd1b0, array=0x555556afe320) at hw/acpi/aml-build.c:1727 build_fadt (tbl=0x555556afe320, linker=0x555557ca3830, f=0x7fffffffd318, oem_id=0x555556afdb2e "CRASH ME", oem_table_id=0x555556afdb34 "ME") at hw/acpi/aml-build.c:2064 ... which happens due to acpi_table_begin() expecting NULL terminated oem_id and oem_table_id strings, which is normally the case, but in case of user provided SLIC table, oem_id points to table's blob directly and as result oem_id became longer than expected. Fix issue by handling oem_id consistently and make acpi_get_slic_oem() return NULL terminated strings. PS: After [1] refactoring, oem_id semantics became inconsistent, where NULL terminated string was coming from machine and old way pointer into byte array coming from -acpitable option. That used to work since build_header() wasn't expecting NULL terminated string and blindly copied the 1st 6 bytes only. However commit [2] broke that by replacing build_header() with acpi_table_begin(), which was expecting NULL terminated string and was checking oem_id size. 1) 602b45820 ("acpi: Permit OEM ID and OEM table ID fields to be changed") 2) Fixes: 4b56e1e4eb08 ("acpi: build_fadt: use acpi_table_begin()/acpi_table_end() instead of build_header()") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/786 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20211227193120.1084176-2-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Denis Lisov <dennis.lissov@gmail.com> Tested-by: Alexander Tsoy <alexander@tsoy.me> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07intel-iommu: correctly check passthrough during translationJason Wang1-15/+23
When scalable mode is enabled, the passthrough more is not determined by the context entry but PASID entry, so switch to use the logic of vtd_dev_pt_enabled() to determine the passthrough mode in vtd_do_iommu_translate(). Signed-off-by: Jason Wang <jasowang@redhat.com> Message-Id: <20220105041945.13459-2-jasowang@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07virtio-mem: Set "unplugged-inaccessible=auto" for the 7.0 machine on x86David Hildenbrand2-2/+4
Set the new default to "auto", keeping it set to "off" for compat machines. This property is only available for x86 targets. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211217134039.29670-4-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-01-07virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLEDavid Hildenbrand1-0/+63
With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, we signal the VM that reading unplugged memory is not supported. We have to fail feature negotiation in case the guest does not support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. First, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is required to properly handle memory backends (or architectures) without support for the shared zeropage in the hypervisor cleanly. Without the shared zeropage, even reading an unpopulated virtual memory location can populate real memory and consequently consume memory in the hypervisor. We have a guaranteed shared zeropage only on MAP_PRIVATE anonymous memory. Second, we want VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE to be the default long-term as even populating the shared zeropage can be problematic: for example, without THP support (possible) or without support for the shared huge zeropage with THP (unlikely), the PTE page tables to hold the shared zeropage entries can consume quite some memory that cannot be reclaimed easily. Third, there are other optimizations+features (e.g., protection of unplugged memory, reducing the total memory slot size and bitmap sizes) that will require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE. We really only support x86 targets with virtio-mem for now (and Linux similarly only support x86), but that might change soon, so prepare for different targets already. Add a new "unplugged-inaccessible" tristate property for x86 targets: - "off" will keep VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE unset and legacy guests working. - "on" will set VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and stop legacy guests from using the device. - "auto" selects the default based on support for the shared zeropage. Warn in case the property is set to "off" and we don't have support for the shared zeropage. For existing compat machines, the property will default to "off", to not change the behavior but eventually warn about a problematic setup. Short-term, we'll set the property default to "auto" for new QEMU machines. Mid-term, we'll set the property default to "on" for new QEMU machines. Long-term, we'll deprecate the parameter and disallow legacy guests completely. The property has to match on the migration source and destination. "auto" will result in the same VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE setting as long as the qemu command line (esp. memdev) match -- so "auto" is good enough for migration purposes and the parameter doesn't have to be migrated explicitly. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20211217134039.29670-3-david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.1 at 2024-10-13 14:26:17 +0000