{"push_id":723462311,"size":23,"distinct_size":14,"ref":"refs/heads/spapr-dev","head":"e629e838a7f125030ea825ee50db2cfcf03ff56c","before":"9915cf2e30df9f6e0fe1de8a0cc226b7b62c6ea2","commits":[{"sha":"9f90602cf40b4d2f2f7dd672b7a140f1f5755920","author":{"email":"37852461ec08f94420c663824224090aed552843@linux.vnet.ibm.com","name":"Bharata B Rao"},"message":"spapr: Support ibm,dynamic-reconfiguration-memory\n\nParse ibm,architecture.vec table obtained from the guest and enable\nmemory node configuration via ibm,dynamic-reconfiguration-memory if guest\nsupports it. This is in preparation to support memory hotplug for\nsPAPR guests.\n\nThis changes the way memory node configuration is done. Currently all\nmemory nodes are built upfront. But after this patch, only memory@0 node\nfor RMA is built upfront. Guest kernel boots with just that and rest of\nthe memory nodes (via memory@XXX or ibm,dynamic-reconfiguration-memory)\nare built when guest does ibm,client-architecture-support call.\n\nNote: This patch needs a SLOF enhancement which is already part of\nSLOF binary in QEMU.\n\nSigned-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/9f90602cf40b4d2f2f7dd672b7a140f1f5755920"},{"sha":"13bd36786d0a7ddbc3b2b04d0c7fd3c0feb2a27b","author":{"email":"37852461ec08f94420c663824224090aed552843@linux.vnet.ibm.com","name":"Bharata B Rao"},"message":"spapr: Make hash table size a factor of maxram_size\n\nThe hash table size is dependent on ram_size, but since with hotplug\nthe memory can grow till maxram_size. Hence make hash table size dependent\non maxram_size.\n\nThis allows to hotplug huge amounts of memory to the guest.\n\nSigned-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/13bd36786d0a7ddbc3b2b04d0c7fd3c0feb2a27b"},{"sha":"ba7e983409d6565f953be3edda18c4db55704ba9","author":{"email":"37852461ec08f94420c663824224090aed552843@linux.vnet.ibm.com","name":"Bharata B Rao"},"message":"spapr: Memory hotplug support\n\nMake use of pc-dimm infrastructure to support memory hotplug\nfor PowerPC.\n\nSigned-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/ba7e983409d6565f953be3edda18c4db55704ba9"},{"sha":"0755b420a06ffb8d03bd9614bf344e6f61e41df8","author":{"email":"37852461ec08f94420c663824224090aed552843@linux.vnet.ibm.com","name":"Bharata B Rao"},"message":"spapr: Don't allow memory hotplug to memory less nodes\n\nCurrently PowerPC kernel doesn't allow hot-adding memory to memory-less\nnode, but instead will silently add the memory to the first node that has\nsome memory. This causes two unexpected behaviours for the user.\n\n- Memory gets hotplugged to a different node than what the user specified.\n- Since pc-dimm subsystem in QEMU still thinks that memory belongs to\n  memory-less node, a reboot will set things accordingly and the previously\n  hotplugged memory now ends in the right node. This appears as if some\n  memory moved from one node to another.\n\nSo until kernel starts supporting memory hotplug to memory-less\nnodes, just prevent such attempts upfront in QEMU.\n\nSigned-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/0755b420a06ffb8d03bd9614bf344e6f61e41df8"},{"sha":"03e92371a6a5e474797074a34b2a894e172d8336","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@gibson.dropbear.id.au","name":"David Gibson"},"message":"spapr: Fix print format warning on 32-bit hosts\n\nThis recently added error_report() uses a %lx format to display\nnuma_info[].node_mem which is a uint64_t.  This will cause a warning when\nbuild on 32-bit hosts.  This fixes it to correctly use the PRIx64\nspecifier macro.\n\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/03e92371a6a5e474797074a34b2a894e172d8336"},{"sha":"cbad1d5cd924ed1514b6406a70c35224d20572d8","author":{"email":"a51408d8d2986b24f193f7be912617112828e2a6@au1.ibm.com","name":"Sam Bobroff"},"message":"spapr: Add /ibm,partition-name\n\nQEMU has a notion of the guest name, so if it's present we might as\nwell put that into the device tree as /ibm,partition-name.\n\nThis is specificed by PAPR.\n\nSigned-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/cbad1d5cd924ed1514b6406a70c35224d20572d8"},{"sha":"0e71dcab2fc42783dfa3bea008a8afe52ed60bf9","author":{"email":"a51408d8d2986b24f193f7be912617112828e2a6@au1.ibm.com","name":"Sam Bobroff"},"message":"spapr: Add /rtas/ibm,change-msix-capable\n\nQEMU is MSI-X capable and makes it available via ibm,change-msi, so\nwe should indicate this by adding /rtas/ibm,change-msix-capable to the\ndevice tree.\n\nThis is specificed by PAPR.\n\nSigned-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/0e71dcab2fc42783dfa3bea008a8afe52ed60bf9"},{"sha":"8f3c2bc89d114103a8c90f4e8b6d85b909efb8e0","author":{"email":"a51408d8d2986b24f193f7be912617112828e2a6@au1.ibm.com","name":"Sam Bobroff"},"message":"spapr: Make ibm, change-msi respect 3 return values\n\nCurrently, rtas_ibm_change_msi() always returns four values even if\nless are specified.\n\nCorrect this by only returning the fourth parameter if it was\nrequested.\n\nThis is specified by PAPR.\n\nSigned-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/8f3c2bc89d114103a8c90f4e8b6d85b909efb8e0"},{"sha":"3af80b0590e8e4518c273c3e47720b83711bea52","author":{"email":"a51408d8d2986b24f193f7be912617112828e2a6@us1.ibm.com","name":"Sam Bobroff"},"message":"spapr: SPLPAR Characteristics\n\nImprove the SPLPAR Characteristics information:\n\n    Add MaxPlatProcs: set to max_cpus, the maximum CPUs that could be\n    addded to the system.\n    Add DesMem: set to the initial memory of the system.\n    Add DesProcs: set to smp_cpus, the inital number of CPUs in the\n    system.\n\nThese tokens and values are specified by PAPR.\n\nSigned-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":false,"url":"https://api.github.com/repos/dgibson/qemu/commits/3af80b0590e8e4518c273c3e47720b83711bea52"},{"sha":"e540d6fecf2e67d6e164ddaa582ea4a85ecc7874","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@gibson.dropbear.id.au","name":"David Gibson"},"message":"spapr_drc: Fix potential undefined behaviour\n\nThe DRC_INDEX_ID_MASK macro does a left shift on ~0, which is a signed\nquantity, and therefore undefined behaviour according to the C spec.  In\nparticular this causes warnings from the clang sanitizer.\n\nThis fixes it by calculating the same mask without using ~0 (I think the\nnew method is a more common idiom for generating masks anyway).  For good\nmeasure I also use 1ULL to force the expression's type to unsigned long\nlong, which should be good for assigning to anything we're going to want\nto.\n\nReported-by: Peter Maydell <peter.maydell@linaro.org>\nSigned-off-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/e540d6fecf2e67d6e164ddaa582ea4a85ecc7874"},{"sha":"e47b7b7056016ba2cb136e6f852525741ff1b208","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"vmstate: Define VARRAY with VMS_ALLOC\n\nThis allows dynamic allocation for migrating arrays.\n\nAlready existing VMSTATE_VARRAY_UINT32 requires an array to be\npre-allocated, however there are cases when the size is not known in\nadvance and there is no real need to enforce it.\n\nThis defines another variant of VMSTATE_VARRAY_UINT32 with WMS_ALLOC\nflag which tells the receiving side to allocate memory for the array\nbefore receiving the data.\n\nThe first user of it is a dynamic DMA window which existence and size\nare totally dynamic.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/e47b7b7056016ba2cb136e6f852525741ff1b208"},{"sha":"7db9659cc308f272dc33173ac579fe4e48d7ac1c","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_pci: Convert finish_realize() to dma_capabilities_update()+dma_init_window()\n\nThis reworks finish_realize() which used to finalize DMA setup with\nan assumption that it will not change later.\n\nNew callbacks supports various window parameters such as page and\nwindows sizes. The new callback return error code rather than Error**.\n\nThis is a mechanical change so no change in behaviour is expected.\nThis is a part of getting rid of spapr-pci-vfio-host-bridge type.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/7db9659cc308f272dc33173ac579fe4e48d7ac1c"},{"sha":"f62870257a6e3b219aad892f5239ab6fd8bbf300","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_iommu: Move table allocation to helpers\n\nAt the moment presence of vfio-pci devices on a bus affect the way\nthe guest view table is allocated. If there is no vfio-pci on a PHB\nand the host kernel supports KVM acceleration of H_PUT_TCE, a table\nis allocated in KVM. However, if there is vfio-pci and we do yet not\nKVM acceleration for these, the table has to be allocated by\nthe userspace. At the moment the table is allocated once at boot time\nbut next patches will reallocate it.\n\nThis moves kvmppc_create_spapr_tce/g_malloc0 and their counterparts\nto helpers.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/f62870257a6e3b219aad892f5239ab6fd8bbf300"},{"sha":"6f7f287afdccae70fc46733b984d64a8c6952a84","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_iommu: Introduce \"enabled\" state for TCE table\n\nCurrently TCE tables are created once at start and their size never\nchanges. We are going to change that by introducing a Dynamic DMA windows\nsupport where DMA configuration may change during the guest execution.\n\nThis changes spapr_tce_new_table() to create an empty stub object. Only\nLIOBN is assigned by the time of creation. It still will be called once\nat the owner object (VIO or PHB) creation.\n\nThis introduces an \"enabled\" state for TCE table objects with two\nhelper functions - spapr_tce_table_enable()/spapr_tce_table_disable().\nspapr_tce_table_enable() receives TCE table parameters and allocates\na guest view of the TCE table (in the user space or KVM).\nspapr_tce_table_disable() disposes the table.\n\nFollow up patches will disable+enable tables on reset (system reset\nor DDW reset).\n\nNo visible change in behaviour is expected except the actual table\nwill be reallocated every reset. We might optimize this later.\n\nThe other way to implement this would be dynamically create/remove\nthe TCE table QOM objects but this would make migration impossible\nas migration expects all QOM objects to exist at the receiver\nso we have to have TCE table objects created when migration begins.\n\nspapr_tce_table_do_enable() is separated from from spapr_tce_table_enable()\nas later it will be called at the sPAPRTCETable post-migration stage when\nit has all the properties set after the migration.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/6f7f287afdccae70fc46733b984d64a8c6952a84"},{"sha":"4948b281d9b64830f915f074648e4448f613ea25","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@gibson.dropbear.id.au","name":"David Gibson"},"message":"spapr_iommu: Remove vfio_accel flag from sPAPRTCETable\n\nsPAPRTCETable has a vfio_accel flag which is passed to\nkvmppc_create_spapr_tce() and controls whether to create a guest view\ntable in KVM as this depends on the host kernel ability to accelerate\nH_PUT_TCE for VFIO devices. We would set this flag at the moment\nwhen sPAPRTCETable is created in spapr_tce_new_table() and\nuse when the table is allocated in spapr_tce_table_realize().\n\nNow we explicitly enable/disable DMA windows via spapr_tce_table_enable()\nand spapr_tce_table_disable() and can pass this flag directly without\ncaching it in sPAPRTCETable.\n\nThis removes the flag. This should cause no behavioural change.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/4948b281d9b64830f915f074648e4448f613ea25"},{"sha":"f4fae72edd8f61ef17941953a2f4505bf44fe3d7","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_iommu: Add root memory region\n\nWe are going to have multiple DMA windows at different offsets on\na PCI bus. For the sake of migration, we will have as many TCE table\nobjects pre-created as many windows supported.\nSo we need a way to map windows dynamically onto a PCI bus\nwhen migration of a table is completed but at this stage a TCE table\nobject does not have access to a PHB to ask it to map a DMA window\nbacked by just migrated TCE table.\n\nThis adds a \"root\" memory region (UINT64_MAX long) to the TCE object.\nThis new region is mapped on a PCI bus with enabled overlapping as\nthere will be one root MR per TCE table, each of them mapped at 0.\nThe actual IOMMU memory region is a subregion of the root region and\na TCE table enables/disables this subregion and maps it at\nthe specific offset inside the root MR which is 1:1 mapping of\na PCI address space.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/f4fae72edd8f61ef17941953a2f4505bf44fe3d7"},{"sha":"fd3444c6a4717788b68dfd85cb7e09f94ef21dfa","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_pci: Do complete reset of DMA config when resetting PHB\n\nOn a system reset, DMA configuration has to reset too. At the moment\nit clears the table content. This is enough for the single table case\nbut with DDW, we will also have to disable all DMA windows except\nthe default one. Furthermore according to sPAPR, if the guest removed\nthe default window and created a huge one at the same zero offset on\na PCI bus, the reset handler has to recreate the default window with\nthe default properties (2GB big, 4K pages).\n\nThis reworks SPAPR PHB code to disable the existing DMA window on reset\nand then configure and enable the default window.\nWithout DDW that means that the same window will be disabled and then\nenabled with no other change in behaviour.\n\nThis changes the table creation to do it in one place in PHB (VFIO PHB\njust inherits the behaviour from PHB). The actual table allocation is\ndone from the reset handler and this is where dma_init_window() is called.\n\nThis disables all DMA windows on a PHB reset. It does not make any\ndifference now as there is just one DMA window but it will later with DDW\npatches.\n\nThis makes spapr_phb_dma_reset() and spapr_phb_dma_remove_window() public\nas these will be used in DDW RTAS \"ibm,reset-pe-dma-window\" and\n\"ibm,remove-pe-dma-window\" handlers later; the handlers will reside in\nhw/ppc/spapr_rtas_ddw.c.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/fd3444c6a4717788b68dfd85cb7e09f94ef21dfa"},{"sha":"1b594ac32496d53d14b9227b052885e04a9720a4","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_vfio_pci: Remove redundant spapr-pci-vfio-host-bridge\n\nsPAPRTCETable is handling 2 TCE tables already:\n\n1) guest view of the TCE table - emulated devices use only this table;\n\n2) hardware IOMMU table - VFIO PCI devices use it for actual work but\nit does not replace 1) and it is not visible to the guest.\nThe initialization of this table is driven by vfio-pci device,\nDMA map/unmap requests are handled via MemoryListener so there is very\nlittle to do in spapr-pci-vfio-host-bridge.\n\nThis moves VFIO bits to the generic spapr-pci-host-bridge which allows\nputting emulated and VFIO devices on the same PHB. It is still possible\nto create multiple PHBs and avoid sharing PHB resouces for emulated and\nVFIO devices.\n\nIf there is no VFIO-PCI device attaches, no special ioctls will be called.\nIf there are some VFIO-PCI devices attached, PHB may refuse to attach\nanother VFIO-PCI device if a VFIO container on the host kernel side\ndoes not support container sharing.\n\nThis changes spapr-pci-host-bridge to support properties of\nspapr-pci-vfio-host-bridge. This makes spapr-pci-vfio-host-bridge type\nequal to spapr-pci-host-bridge except it has an additional \"iommu\"\nproperty for backward compatibility reasons.\n\nThis moves PCI device lookup from spapr_phb_vfio_eeh_set_option() to\nrtas_ibm_set_eeh_option() as we need to know if the device is \"vfio-pci\"\nand decide whether to call spapr_phb_vfio_eeh_set_option() or not.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/1b594ac32496d53d14b9227b052885e04a9720a4"},{"sha":"2bf1c07f0d468b982a73af11000b9aa38bc4ed6e","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_pci: Enable vfio-pci hotplug\n\nsPAPR IOMMU is managing two copies of an TCE table:\n1) a guest view of the table - this is what emulated devices use and\nthis is where H_GET_TCE reads from;\n2) a hardware TCE table - only present if there is at least one vfio-pci\ndevice on a PHB; it is updated via a memory listener on a PHB address\nspace which forwards map/unmap requests to vfio-pci IOMMU host driver.\n\nAt the moment presence of vfio-pci devices on a bus affect the way\nthe guest view table is allocated. If there is no vfio-pci on a PHB\nand the host kernel supports KVM acceleration of H_PUT_TCE, a table\nis allocated in KVM. However, if there is vfio-pci and we do yet not\nsupport KVM acceleration for these, the table has to be allocated\nby the userspace.\n\nWhen vfio-pci device is hotplugged and there were no vfio-pci devices\nalready, the guest view table could have been allocated by KVM which\nmeans that H_PUT_TCE is handled by the host kernel and since we\ndo not support vfio-pci in KVM, the hardware table will not be updated.\n\nThis reallocates the guest view table in QEMU if the first vfio-pci\ndevice has just been plugged. spapr_tce_realloc_userspace() handles this.\n\nThis replays all the mappings to make sure that the tables are in sync.\nThis will not have a visible effect though as for a new device\nthe guest kernel will allocate-and-map new addresses and therefore\nexisting mappings from emulated devices will not be used by vfio-pci\ndevices.\n\nThis adds calls to spapr_phb_dma_capabilities_update() in PCI hotplug\nhooks.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/2bf1c07f0d468b982a73af11000b9aa38bc4ed6e"},{"sha":"1896647f8731e68234a606e8d001c5e575718adc","author":{"email":"ac1fc56530d7d037e1ea666f130daca22d72f964@ozlabs.ru","name":"Alexey Kardashevskiy"},"message":"spapr_pci_vfio: Enable multiple groups per container\n\nThis enables multiple IOMMU groups in one VFIO container which means\nthat multiple devices from different groups can share the same IOMMU\ntable (or tables if DDW).\n\nThis removes a group id from vfio_container_ioctl(). The kernel support\nis required for this; if the host kernel does not have the support,\nit will allow only one group per container. The PHB's \"iommuid\" property\nis ignored. The ioctl is called for every container attached to\nthe address space. At the moment there is just one container anyway.\n\nIf there is no container attached to the address space,\nvfio_container_do_ioctl() returns -1.\n\nThis removes casts to sPAPRPHBVFIOState as none of sPAPRPHBVFIOState\nmembers is accessed here.\n\nSigned-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>\nReviewed-by: David Gibson <david@gibson.dropbear.id.au>","distinct":true,"url":"https://api.github.com/repos/dgibson/qemu/commits/1896647f8731e68234a606e8d001c5e575718adc"}]}