aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2022-09-02Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into stagingStefan Hajnoczi
# -----BEGIN PGP SIGNATURE----- # Version: GnuPG v1 # # iQEcBAABAgAGBQJjEaMLAAoJEO8Ells5jWIRoRwIAJpwefLgH/+lkd1mtWqxBhuS # KLa0bkcS6nIGnjQzNX/XWipu/5tMbBLzbaKw0myodvoK6Yx0MFog1cWf6gLHuvWH # Jy3ONUrF9umHYuOa9sJJtXv/aP7neNJSB3RW67BaiLCLkaetDj9lLciA/KKMvb/I # JNFtuLVTPibZ5iVTjvifFWmJD/Yk0P8mlrH5yfrA3B2EaaWf1es0GWobGIwwLu9s # ZSqjhMDAhfOW2E1sBh7jFRh4lJX1t1jRhyIGx2bOXevPx2hFHq6FSq+yuJ9OsZvO # wC8mC4DD+fovypDWbv3WLslIejM0+THD8KuBQnZtKX5Mbhc+0cELpIFLUdH95TM= # =eMUT # -----END PGP SIGNATURE----- # gpg: Signature made Fri 02 Sep 2022 02:30:35 EDT # gpg: using RSA key EF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [full] # Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211 * tag 'net-pull-request' of https://github.com/jasowang/qemu: (21 commits) net: tulip: Restrict DMA engine to memories net/colo.c: Fix the pointer issue reported by Coverity. vdpa: Delete CVQ migration blocker vdpa: Add virtio-net mac address via CVQ at start vhost_net: add NetClientState->load() callback vdpa: extract vhost_vdpa_net_cvq_add from vhost_vdpa_net_handle_ctrl_avail vdpa: Move command buffers map to start of net device vdpa: add net_vhost_vdpa_cvq_info NetClientInfo vhost_net: Add NetClientInfo stop callback vhost_net: Add NetClientInfo start callback vhost: Do not depend on !NULL VirtQueueElement on vhost_svq_flush vhost: Delete useless read memory barrier vhost: use SVQ element ndescs instead of opaque data for desc validation vhost: stop transfer elem ownership in vhost_handle_guest_kick vdpa: Use ring hwaddr at vhost_vdpa_svq_unmap_ring vhost: Always store new kick fd on vhost_svq_set_svq_kick_fd vdpa: Make SVQ vring unmapping return void vdpa: Remove SVQ vring from iova_tree at shutdown util: accept iova_tree_remove_parameter by value vdpa: do not save failed dma maps in SVQ iova tree ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-09-02Merge tag 'char-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi
into staging chardev patches & small audio fix # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmMSAXYcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5YvaD/9VUIy96LZUGIexEhLj # IT804yjCtSl9iV7/V7oivIPr9IpTKnUQS/yqbX8B8Afc6uQHDQRrhoNmuDRb3gCo # V4XhZxZTzUvwJ/FUp35tgsEvqTMsK9taVrPtwVB9VJ3c7OkjvJGn1Q9+Di7WbsuZ # +rZVR7+1IxkFpIqxBiSqdjHCkqSsAYtaL7wqSnpwiz3jw1nbL25iheo3gylNJbg5 # tfxLLJDFUs9Qqf04iVFtMv9vKoXZDBlCLEiCaCHbpzMXylP6t82oRoj3j2XioqvS # 9dc3NNcWqTg5Srx1HJ95V8jPnUqLXD91fw9EqD+v0Va1l1JZ+2lGvqnTWDRZfBl3 # 2WZ23oHgwPSgFUyArmrSMX6qRG+f29NHA+r6F5ebVm8AzCP/QkhIqY/EJx8te77C # 6cN8xS8LDkiL6fsJ5r5ZXViaCgvC33oLSmBQ/wVAJtNChYykmFUBw66Wc+ySSM/L # HqNNflM1vWHnAc4/EqQT9PYV7cl5Ooss7i1lDIXu5tEpWtBFzV5OFtGE+njfQJ4B # gpe0zhwXM/+fRyGvDnCkwINTQMgoKku12nTTE9NBpMWxlhW9BtCpY92Ht5BJmNVj # b+ylbZaTiGBjHfshx0UlZ4vsDDy5gA28gJa7S6cs/Ak7TMLjwqj0Av+upUYt3PBW # 8A1IB2wL91sFESh5RrMJCg4Bbg== # =jtDp # -----END PGP SIGNATURE----- # gpg: Signature made Fri 02 Sep 2022 09:13:26 EDT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'char-pull-request' of https://gitlab.com/marcandre.lureau/qemu: audio: exit(1) if audio backend failed to be found or initialized tests/unit: Update test-io-channel-socket.c for Windows chardev/char-socket: Update AF_UNIX for Windows util/qemu-sockets: Enable unix socket support on Windows Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-09-02util/qemu-sockets: Enable unix socket support on WindowsBin Meng
Support for the unix socket has existed both in BSD and Linux for the longest time, but not on Windows. Since Windows 10 build 17063 [1], the native support for the unix socket has come to Windows. Starting this build, two Win32 processes can use the AF_UNIX address family over Winsock API to communicate with each other. [1] https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220802075200.907360-3-bmeng.cn@gmail.com>
2022-09-02vdpa: Delete CVQ migration blockerEugenio Pérez
We can restore the device state in the destination via CVQ now. Remove the migration blocker. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vhost_net: add NetClientState->load() callbackEugenio Pérez
It allows per-net client operations right after device's successful start. In particular, to load the device status. Vhost-vdpa net will use it to add the CVQ buffers to restore the device status. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vhost_net: Add NetClientInfo stop callbackEugenio Pérez
Used by the backend to perform actions after the device is stopped. In particular, vdpa net use it to unmap CVQ buffers to the device, cleaning the actions performed in prepare(). Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02vhost_net: Add NetClientInfo start callbackEugenio Pérez
This is used by the backend to perform actions before the device is started. In particular, vdpa net use it to map CVQ buffers to the device, so it can send control commands using them. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-02util: accept iova_tree_remove_parameter by valueEugenio Pérez
It's convenient to call iova_tree_remove from a map returned from iova_tree_find or iova_tree_find_iova. With the current code this is not possible, since we will free it, and then we will try to search for it again. Fix it making accepting the map by value, forcing a copy of the argument. Not applying a fixes tag, since there is no use like that at the moment. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-09-01Merge tag 'pull-ppc-20220831' of https://gitlab.com/danielhb/qemu into stagingStefan Hajnoczi
ppc patch queue for 2022-08-31: In the first 7.2 queue we have changes in the powernv pnv-phb handling, the start of the QOMification of the ppc405 model, the removal of the taihu machine, a new SLOF image and others. # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQQX6/+ZI9AYAK8oOBk82cqW3gMxZAUCYw/AFgAKCRA82cqW3gMx # ZI6XAP0d8m6r1JqKXPSfCwVYy+AfrwY7oZWYbeTqdamK6xHcUQD+JyCcFcogY4Vz # YwvHLd9W2cqvoWiZ4tmkK4Mb0Xt0Xg4= # =0uL/ # -----END PGP SIGNATURE----- # gpg: Signature made Wed 31 Aug 2022 16:09:58 EDT # gpg: using EDDSA key 17EBFF9923D01800AF2838193CD9CA96DE033164 # gpg: Good signature from "Daniel Henrique Barboza <danielhb413@gmail.com>" [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: 17EB FF99 23D0 1800 AF28 3819 3CD9 CA96 DE03 3164 * tag 'pull-ppc-20220831' of https://gitlab.com/danielhb/qemu: (60 commits) ppc4xx: Fix code style problems reported by checkpatch ppc/ppc4xx: Fix sdram trace events hw/ppc/Kconfig: Move imply before select hw/ppc/sam460ex: Remove PPC405 dependency from sam460ex ppc405: Move machine specific code to ppc405_boards.c ppc/ppc405: QOM'ify FPGA ppc/ppc405: Use an explicit I2C object hw/intc/ppc-uic: Convert ppc-uic to a PPC4xx DCR device ppc/ppc405: Use an embedded PPCUIC model in SoC state ppc4xx: Rename ppc405-ebc to ppc4xx-ebc ppc4xx: Move EBC model to ppc4xx_devs.c ppc4xx: Rename ppc405-plb to ppc4xx-plb ppc4xx: Move PLB model to ppc4xx_devs.c ppc/ppc405: QOM'ify MAL ppc/ppc405: QOM'ify PLB ppc/ppc405: QOM'ify POB ppc/ppc405: QOM'ify OPBA ppc/ppc405: QOM'ify EBC ppc/ppc405: QOM'ify DMA ppc/ppc405: QOM'ify GPIO ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-09-01scsi: Add buf_len parameter to scsi_req_new()John Millikin
When a SCSI command is received from the guest, the CDB length implied by the first byte might exceed the number of bytes the guest sent. In this case scsi_req_new() will read uninitialized data, causing unpredictable behavior. Adds the buf_len parameter to scsi_req_new() and plumbs it through the call stack. Signed-off-by: John Millikin <john@john-millikin.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1127 Message-Id: <20220817053458.698416-1-john@john-millikin.com> [Fill in correct length for adapters other than ESP. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-08-31hw/intc/ppc-uic: Convert ppc-uic to a PPC4xx DCR deviceBALATON Zoltan
Make ppc-uic a subclass of ppc4xx-dcr-device which will handle the cpu link and make it uniform with the other PPC4xx devices. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <eb548130cf60aea8a6ea4dba4dee1686b3cabc3d.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-ebc to ppc4xx-ebcBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <63d9b14c8ff5f73e35bffca1036394b5235735ee.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move EBC model to ppc4xx_devs.cBALATON Zoltan
The EBC is shared between 405 and 440 so move it to shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <10eae70509ca4bd74858fc2c0a0f0e4eb9330199.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-plb to ppc4xx-plbBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <5b13ebfd12a71a28035bed5a915cbeee81cf21d1.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move PLB model to ppc4xx_devs.cBALATON Zoltan
The PLB is shared between 405 and 440 so move it to the shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <2498384bf3e18959ee8cb984d72fb66b8a6ecadc.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify MALCédric Le Goater
The Memory Access Layer (MAL) controller is currently modeled as a DCR device with 4 IRQs. Also drop the ppc4xx_mal_init() helper and adapt the sam460ex machine. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes, add finalize method] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <d54a243dff94d95ba30dbcc09c27700a90ade932.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc4xx: Introduce a DCR device modelCédric Le Goater
The Device Control Registers (DCR) of on-SoC devices are accessed by software through the use of the mtdcr and mfdcr instructions. These are converted in transactions on a side band bus, the DCR bus, which connects the on-SoC devices to the CPU. Ideally, we should model these accesses with a DCR namespace and DCR memory regions but today the DCR handlers are installed in a DCR table under the CPU. Instead, introduce a little device model wrapper to hold a CPU link and handle registration of DCR handlers. The DCR device inherits from SysBus because most of these devices also have MMIO regions and/or IRQs. Being a SysBusDevice makes things easier to install the device model in the overall SoC. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: Explicit opaque parameter for dcr callbacks] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <9b21bdf55e0a728f093bad299e030d98f302ded0.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify CPUCédric Le Goater
Drop the use of ppc4xx_init() and duplicate a bit of code related to clocks in the SoC realize routine. We will clean that up in the following patches. ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe this could be done in model initializer of the CPU families needing it. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-8-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/pnv: turn chip8->phbs[] into a PnvPHB* arrayDaniel Henrique Barboza
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different manners. The only difference between these PHBs is that one will have a valid phb3->chip that is assigned during pnv_chip_power8_realize(), while the user created needs to search which chip it belongs to. Aside from that there shouldn't be any difference. Making the default PHBs behave in line with the user created ones will make it easier to re-introduce them later on. It will also make the code easier to follow since we are dealing with them in equal manner. The first step is to turn chip8->phbs[] into a PnvPHB3 pointer array. This will allow us to assign user created PHBs into it later on. The way we initilize the default case is now more in line with that would happen with the user created case: the object is created, parented by the chip because pnv_xscom_dt() relies on it, and then assigned to the array. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-6-danielhb413@gmail.com>
2022-08-31ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". They are needed to amend the QOM and bus hierarchies of user created pnv-phbs, matching them with default pnv-phbs. A new helper pnv_phb_user_device_init() is created to handle user-created devices setup. We're going to call it inside pnv_phb_realize() in case we're realizing an user created device. This will centralize all user device realated in a single spot, leaving the realize functions of the phb3/phb4 backends untouched. Another helper called pnv_chip_add_phb() was added to handle the particularities of each chip version when adding a new PHB. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-5-danielhb413@gmail.com>
2022-08-31ppc/pnv: add phb-id/chip-id PnvPHB4RootBus propertiesDaniel Henrique Barboza
The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: - there's not user side advantage in doing so. Unifying the root ports presents a clear user QOL change when we enable user created devices back. The buses objects, aside from having a different QOM name, is transparent to the user; - we leave a door opened in case we want to increase the root port limit for phb4/5 later on without having to deal with phb3 code. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-3-danielhb413@gmail.com>
2022-08-31ppc/pnv: add phb-id/chip-id PnvPHB3RootBus propertiesDaniel Henrique Barboza
We rely on the phb-id and chip-id, which are PHB properties, to assign chassis and slot to the root port. For default devices this is no big deal: the root port is being created under pnv_phb_realize() and the values are being passed on via the 'index' and 'chip-id' of the pnv_phb_attach_root_port() helper. If we want to implement user created root ports we have a problem. The user created root port will not be aware of which PHB it belongs to, unless we're willing to violate QOM best practices and access the PHB via dev->parent_bus->parent. What we can do is to access the root bus parent bus. Since we're already assigning the root port as QOM child of the bus, and the bus is initiated using PHB properties, let's add phb-id and chip-id as properties of the bus. This will allow us trivial access to them, for both user-created and default root ports, without doing anything too shady with QOM. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-2-danielhb413@gmail.com>
2022-08-31ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza
The helper is only used in this file. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-13-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove PnvPHB4.versionDaniel Henrique Barboza
It's unused. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-12-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pecc->rp_modelDaniel Henrique Barboza
The attribute is unused. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-11-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza
We support only a single root port, PNV_PHB_ROOT_PORT. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-10-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pnv-phb4-root-portDaniel Henrique Barboza
The unified pnv-phb-root-port can be used instead. The phb4-root-port device isn't exposed to the user in any official QEMU release so there's no ABI breakage in removing it. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-9-danielhb413@gmail.com>
2022-08-31ppc/pnv: remove pnv-phb3-root-portDaniel Henrique Barboza
The unified pnv-phb-root-port can be used in its place. There is no ABI breakage in doing so because no official QEMU release introduced user creatable pnv-phb3-root-port devices. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-8-danielhb413@gmail.com>
2022-08-31ppc/pnv: turn PnvPHB4 into a PnvPHB backendDaniel Henrique Barboza
Change the parent type of the PnvPHB4 device to TYPE_PARENT since the PCI bus is going to be initialized by the PnvPHB parent. Functions that needs to access the bus via a PnvPHB4 object can do so via the phb4->phb_base pointer. pnv_phb4_pec now creates a PnvPHB object. The powernv9 machine class will create PnvPHB devices with version '4'. powernv10 will create using version '5'. Both are using global machine properties in their class_init() to do that. These changes will benefit us when adding PnvPHB user creatable devices for powernv9 and powernv10. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-6-danielhb413@gmail.com>
2022-08-31ppc/pnv: add PHB4 bus init helperDaniel Henrique Barboza
Similar to what we already did for the PnvPHB3 device, let's add a helper to init the bus when using a PnvPHB4. This helper will be used by PnvPHb when PnvPHB4 turns into a backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-5-danielhb413@gmail.com>
2022-08-31ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend. In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bus, change PnvPHB3 parent to TYPE_DEVICE. There are a couple of instances in pnv_phb3.c that needs to access the PCI bus, so a phb_base pointer is added to allow access to the parent PnvPHB. The PnvPHB3 root port will now be connected to a PnvPHB object. In pnv.c, the powernv8 machine chip8 will now hold an array of PnvPHB objects. pnv_get_phb3_child() needs to be adapted to return the PnvPHB3 backend from the PnvPHB child. A global property is added in pnv_machine_power8_class_init() to ensure that all PnvPHBs are created with phb->version = 3. After all these changes we're still able to boot a powernv8 machine with default settings. The real gain will come with user created PnvPHB devices, coming up next. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-4-danielhb413@gmail.com>
2022-08-31ppc/pnv: add PHB3 bus init helperDaniel Henrique Barboza
The PnvPHB3 bus init consists of initializing the pci_io and pci_mmio regions, registering it via pci_register_root_bus() and then setup the iommu. We'll want to init the bus from outside pnv_phb3.c when the bus is removed from the PnvPHB3 device and put into a new parent PnvPHB device. The new pnv_phb3_bus_init() helper will be used by the parent to init the bus when using the PHB3 backend. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-2-danielhb413@gmail.com>
2022-08-31fpu: Add rebias bool, value and operationLucas Mateus Castro (alqotel)
Added the possibility of recalculating a result if it overflows or underflows, if the result overflow and the rebias bool is true then the intermediate result should have 3/4 of the total range subtracted from the exponent. The same for underflow but it should be added to the exponent of the intermediate number instead. Signed-off-by: Lucas Mateus Castro (alqotel) <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220805141522.412864-2-lucas.araujo@eldorado.org.br> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/pnv: Add initial P9/10 SBE modelNicholas Piggin
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register access, MPIPL). The latter facilities are accessed mostly via a message system called SBEFIFO. This driver provides initial emulation for the SBE runtime registers and a very basic SBEFIFO implementation that provides the timer command. This covers the basic SBE behaviour expected by skiboot when booting. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20220811093726.1442343-1-npiggin@gmail.com> [danielhb: fixed SBE_HOST_RESPONSE_MASK long line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-26util/mmap-alloc: Remove qemu_mempath_getpagesize()Thomas Huth
The last user of this function has just been removed, so we can drop this function now, too. Message-Id: <20220810125720.3849835-4-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-08-25hw: Add compat machines for 7.2Cornelia Huck
Add 7.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20220727121755.395894-1-cohuck@redhat.com> [thuth: fixed conflict with pcmc->legacy_no_rng_seed] Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-08-11linux-user/aarch64: Reset target data on MADV_DONTNEEDVitaly Buka
aarch64 stores MTE tags in target_date, and they should be reset by MADV_DONTNEED. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220711220028.2467290-1-vitalybuka@google.com> [lv: fix code style issues] Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-08-04include/qemu/host-utils.h: Simplify the compiler check in mulu128()Thomas Huth
We currently require at least GCC 7.4 or Clang 6.0 for compiling QEMU. GCC has __builtin_mul_overflow since version 5 already, and Clang 6.0 also provides this built-in function (see its documentation on this page: https://releases.llvm.org/6.0.0/tools/clang/docs/LanguageExtensions.html ). So we can simplify the #if statement here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220721074809.1513357-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2022-08-02main loop: add missing documentation links to GS/IO macrosEmanuele Giuseppe Esposito
If we go directly to GLOBAL_STATE_CODE, IO_CODE or IO_OR_GS_CODE definition, we just find that they "mark and check that the function is part of the {category} API". However, ther is no definition on what {category} API is, they are in include/block/block-*.h Therefore, add a comment that refers to such documentation. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20220609122206.1016936-1-eesposit@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-08-01misc: fix commonly doubled up wordsDaniel P. Berrangé
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220707163720.1421716-5-berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-07-29hw/loongarch: Change macro name 'LS7A_XXX' to 'VIRT_XXX'Xiaojuan Yang
Change macro name 'LS7A_XXX' to 'VIRT_XXX', as the loongarch virt machinue use the GPEX bridge instead of LS7A bridge. So the macro name should keep consistency. Signed-off-by: Xiaojuan Yang <yangxiaojuan@loongson.cn> Message-Id: <20220729073018.27037-3-yangxiaojuan@loongson.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-07-29qapi: Add exit-failure PanicActionIlya Leoshkevich
Currently QEMU exits with code 0 on both panic an shutdown. For tests it is useful to return 1 on panic, so that it counts as a test failure. Introduce a new exit-failure PanicAction that makes main() return EXIT_FAILURE. Tests can use -action panic=exit-failure option to activate this behavior. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20220725223746.227063-2-iii@linux.ibm.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2022-07-26i386/pc: restrict AMD only enforcing of 1Tb hole to new machine typeJoao Martins
The added enforcing is only relevant in the case of AMD where the range right before the 1TB is restricted and cannot be DMA mapped by the kernel consequently leading to IOMMU INVALID_DEVICE_REQUEST or possibly other kinds of IOMMU events in the AMD IOMMU. Although, there's a case where it may make sense to disable the IOVA relocation/validation when migrating from a non-amd-1tb-aware qemu to one that supports it. Relocating RAM regions to after the 1Tb hole has consequences for guest ABI because we are changing the memory mapping, so make sure that only new machine enforce but not older ones. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-12-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: pass pci_hole64_size to pc_memory_init()Joao Martins
Use the pre-initialized pci-host qdev and fetch the pci-hole64-size into pc_memory_init() newly added argument. Use PCI_HOST_PROP_PCI_HOLE64_SIZE pci-host property for fetching pci-hole64-size. This is in preparation to determine that host-phys-bits are enough and for pci-hole64-size to be considered to relocate ram-above-4g to be at 1T (on AMD platforms). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-4-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26i386/pc: create pci-host qdev prior to pc_memory_init()Joao Martins
At the start of pc_memory_init() we usually pass a range of 0..UINT64_MAX as pci_memory, when really its 2G (i440fx) or 32G (q35). To get the real user value, we need to get pci-host passed property for default pci_hole64_size. Thus to get that, create the qdev prior to memory init to better make estimations on max used/phys addr. This is in preparation to determine that host-phys-bits are enough and also for pci-hole64-size to be considered to relocate ram-above-4g to be at 1T (on AMD platforms). Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-3-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26hw/i386: add 4g boundary start to X86MachineStateJoao Martins
Rather than hardcoding the 4G boundary everywhere, introduce a X86MachineState field @above_4g_mem_start and use it accordingly. This is in preparation for relocating ram-above-4g to be dynamically start at 1T on AMD platforms. Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20220719170014.27028-2-joao.m.martins@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26hw/cxl: Fix size of constant in interleave granularity function.Jonathan Cameron
Whilst the interleave granularity is always small enough that this isn't a real problem (much less than 4GiB) let's change the constant to ULL to fix the coverity warning. Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 829de299d1 ("hw/cxl/component: Add utils for interleave parameter encoding/decoding") Fixes: Coverity CID 1488868 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20220701132300.2264-4-Jonathan.Cameron@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26hw/machine: Clear out left over CXL related pointer from move of state ↵Jonathan Cameron
handling to machines. This got left behind in the move of the CXL setup code from core files to the machines that support it. Link: https://gitlab.com/qemu-project/qemu/-/commit/1ebf9001fb2701e3c00b401334c8f3900a46adaa Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20220701132300.2264-2-Jonathan.Cameron@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-07-26acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()Robert Hoo
Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Jingqi Liu <jingqi.liu@intel.com> Message-Id: <20220704085852.330005-1-robert.hu@linux.intel.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-07-22hw/i386: pass RNG seed via setup_data entryJason A. Donenfeld
Tiny machines optimized for fast boot time generally don't use EFI, which means a random seed has to be supplied some other way. For this purpose, Linux (≥5.20) supports passing a seed in the setup_data table with SETUP_RNG_SEED, specially intended for hypervisors, kexec, and specialized bootloaders. The linked commit shows the upstream kernel implementation. At Paolo's request, we don't pass these to versioned machine types ≤7.0. Link: https://git.kernel.org/tip/tip/c/68b8e9713c8 Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <eduardo@habkost.net> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Message-Id: <20220721125636.446842-1-Jason@zx2c4.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 11:00:02 +0000