{"push_id":2817957992,"size":112,"distinct_size":112,"ref":"refs/heads/master","head":"13b7b188501d419a7d63c016e00065bcc693b7d4","before":"0abaa41d936becd914a16ee1fe2a981d96d19428","commits":[{"sha":"b0e5de93811077254a536c23b713b49e12efb742","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"memory, exec: Expose all memory block related flags.\n\nWe need to use these flags in other files rather than just in exec.c,\nFor example, RAM_SHARED should be used when create a ram block from file.\nWe expose them the exec/memory.h\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/b0e5de93811077254a536c23b713b49e12efb742"},{"sha":"cbfc01710362f3de6fca3010a17b0e1c866fc181","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"memory, exec: switch file ram allocation functions to 'flags' parameters\n\nAs more flag parameters besides the existing 'share' are going to be\nadded to following functions\nmemory_region_init_ram_from_file\nqemu_ram_alloc_from_fd\nqemu_ram_alloc_from_file\nlet's switch them to use the 'flags' parameters so as to ease future\nflag additions.\n\nThe existing 'share' flag is converted to the RAM_SHARED bit in ram_flags,\nand other flag bits are ignored by above functions right now.\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nSigned-off-by: Haozhong Zhang <haozhong.zhang@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/cbfc01710362f3de6fca3010a17b0e1c866fc181"},{"sha":"17824406fa55b303379f2e4af715c1e876c3535f","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"configure: add libpmem support\n\nAdd a pair of configure options --{enable,disable}-libpmem to control\nwhether QEMU is compiled with PMDK libpmem [1].\n\nQEMU may write to the host persistent memory (e.g. in vNVDIMM label\nemulation and live migration), so it must take the proper operations\nto ensure the persistence of its own writes. Depending on the CPU\nmodels and available instructions, the optimal operation can vary [2].\nPMDK libpmem have already implemented those operations on multiple CPU\nmodels (x86 and ARM) and the logic to select the optimal ones, so QEMU\ncan just use libpmem rather than re-implement them.\n\nLibpem is a part of PMDK project(formerly known as NMVL).\nThe project's home page is: http://pmem.io/pmdk/\nAnd the project's repository is: https://github.com/pmem/pmdk/\n\nFor more information about libpmem APIs, you can refer to the comments\nin source code of: pmdk/src/libpmem/pmem.c, begin at line 33.\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nSigned-off-by: Haozhong Zhang <haozhong.zhang@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/17824406fa55b303379f2e4af715c1e876c3535f"},{"sha":"a4de8552b2580adf6fa4874439217b65d3bdd88b","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"hostmem-file: add the 'pmem' option\n\nWhen QEMU emulates vNVDIMM labels and migrates vNVDIMM devices, it\nneeds to know whether the backend storage is a real persistent memory,\nin order to decide whether special operations should be performed to\nensure the data persistence.\n\nThis boolean option 'pmem' allows users to specify whether the backend\nstorage of memory-backend-file is a real persistent memory. If\n'pmem=on', QEMU will set the flag RAM_PMEM in the RAM block of the\ncorresponding memory region. If 'pmem' is set while lack of libpmem\nsupport, a error is generated.\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nSigned-off-by: Haozhong Zhang <haozhong.zhang@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/a4de8552b2580adf6fa4874439217b65d3bdd88b"},{"sha":"faf8a13d80de98b43342a7ec9878b4fd76b18327","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"mem/nvdimm: ensure write persistence to PMEM in label emulation\n\nGuest writes to vNVDIMM labels are intercepted and performed on the\nbackend by QEMU. When the backend is a real persistent memort, QEMU\nneeds to take proper operations to ensure its write persistence on the\npersistent memory. Otherwise, a host power failure may result in the\nloss of guest label configurations.\n\nSigned-off-by: Haozhong Zhang <haozhong.zhang@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/faf8a13d80de98b43342a7ec9878b4fd76b18327"},{"sha":"469dd51bc664979f159d47885997d482991394b8","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"migration/ram: Add check and info message to nvdimm post copy.\n\nThe nvdimm kind memory does not support post copy now.\nWe disable post copy if we have nvdimm memory and print some\nlog hint to user.\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/469dd51bc664979f159d47885997d482991394b8"},{"sha":"56eb90af39abf66c0e80588a9f50c31e7df7320b","author":{"name":"Junyan He","email":"8f73a735c668918c9613b750d3a88ebf2489599f@intel.com"},"message":"migration/ram: ensure write persistence on loading all data to PMEM.\n\nBecause we need to make sure the pmem kind memory data is synced\nafter migration, we choose to call pmem_persist() when the migration\nfinish. This will make sure the data of pmem is safe and will not\nlose if power is off.\n\nSigned-off-by: Junyan He <junyan.he@intel.com>\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\nReviewed-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/56eb90af39abf66c0e80588a9f50c31e7df7320b"},{"sha":"3aeaac8fa2d008a1f55b040fde6d4ec06f2f5146","author":{"name":"Dou Liyang","email":"829a85a8a2c47baa0201a22ca31c02e71d988d73@cn.fujitsu.com"},"message":"machine: Fix coding style at machine_run_board_init()\n\nCommit 7747abf11487 (\"hw/machine: Remove the Zero check of\nnb_numa_nodes for numa_complete_configuration()\") removed the\ncurly brackets.  Re-add them.\n\nSigned-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>\nMessage-Id: <20180710105129.23296-1-douly.fnst@cn.fujitsu.com>\nReviewed-by: Igor Mammedov <imammedo@redhat.com>\n[ehabkost: rewrote commit message]\nSigned-off-by: Eduardo Habkost <ehabkost@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/3aeaac8fa2d008a1f55b040fde6d4ec06f2f5146"},{"sha":"be64d7776bcc48a542acf1f74765a3930692cef4","author":{"name":"Mark Cave-Ayland","email":"843eb11336b6e35bd55f1d23652fb443c71c9ae4@ilande.co.uk"},"message":"sysbus: always allow explicit_ofw_unit_address() to override address generation\n\nSome SysBusDevices either use sysbus_init_mmio() without\nsysbus_mmio_map() or the first MMIO memory region doesn't represent the\nbus address, causing a firmware device path with an invalid address to\nbe generated.\n\nSysBusDeviceClass does provide a virtual explicit_ofw_unit_address()\nmethod that can be used to override this process, but it was originally intended\nonly as as a fallback option meaning that any existing MMIO memory regions still\ntake priority whilst determining the firmware device address.\n\nThere is currently only one user of explicit_ofw_unit_address() and that\nis the PCI expander bridge (PXB) device which has no MMIO/PIO resources\ndefined. This enables us to allow explicit_ofw_unit_address() to take\npriority without affecting backwards compatibility, allowing the address\nto be customised as required.\n\nSigned-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>\nReviewed-by: Laszlo Ersek <lersek@redhat.com>\nMessage-Id: <20180805112850.26063-2-mark.cave-ayland@ilande.co.uk>\nReviewed-by: Thomas Huth <thuth@redhat.com>\nReviewed-by: Eduardo Habkost <ehabkost@redhat.com>\nSigned-off-by: Eduardo Habkost <ehabkost@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/be64d7776bcc48a542acf1f74765a3930692cef4"},{"sha":"907aac2f6af6ef775367c368b87cc1720e39d407","author":{"name":"Mark Cave-Ayland","email":"843eb11336b6e35bd55f1d23652fb443c71c9ae4@ilande.co.uk"},"message":"fw_cfg: ignore suffixes in the bootdevice list dependent on machine class\n\nFor the older machines (such as Mac and SPARC) the DT nodes representing\nbootdevices for disk nodes are irregular for mainly historical reasons.\n\nSince the majority of bootdevice nodes for these machines either do not have a\nseparate disk node or require different (custom) names then it is much easier\nfor processing to just disable all suffixes for a particular machine.\n\nIntroduce a new ignore_boot_device_suffixes MachineClass property to control\nbootdevice suffix generation, defaulting to false in order to preserve\ncompatibility.\n\nSuggested-by: Eduardo Habkost <ehabkost@redhat.com>\nSigned-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>\nMessage-Id: <20180810124027.10698-1-mark.cave-ayland@ilande.co.uk>\nReviewed-by: Laszlo Ersek <lersek@redhat.com>\nAcked-by: David Gibson <david@gibson.dropbear.id.au>\nSigned-off-by: Eduardo Habkost <ehabkost@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/907aac2f6af6ef775367c368b87cc1720e39d407"},{"sha":"b8dbfc9cc662ba05ea0b8ffc4598e422b76fbcbd","author":{"name":"Laurent Vivier","email":"f1b010126f61b5c59e7d5eb42c5c68f6105c5914@vivier.eu"},"message":"qemu-binfmt-conf.sh: add x86_64 target\n\nSigned-off-by: Laurent Vivier <laurent@vivier.eu>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>\nReviewed-by: Thomas Huth <thuth@redhat.com>\nMessage-Id: <20180801102944.23457-1-laurent@vivier.eu>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/b8dbfc9cc662ba05ea0b8ffc4598e422b76fbcbd"},{"sha":"3e23de15237c81fe7af7c3ffa299a6ae5fec7d43","author":{"name":"Laurent Vivier","email":"f1b010126f61b5c59e7d5eb42c5c68f6105c5914@vivier.eu"},"message":"linux-user: fix 32bit g2h()/h2g()\n\nsparc32plus has 64bit long type but only 32bit virtual address space.\n\nFor instance, \"apt-get upgrade\" failed because of a mmap()/msync()\nsequence.\n\nmmap() returned 0xff252000 but msync() used g2h(0xffffffffff252000)\nto find the host address. The \"(target_ulong)\" in g2h() doesn't fix the\naddress because it is 64bit long.\n\nThis patch introduces an \"abi_ptr\" that is set to uint32_t\nif the virtual address space is addressed using 32bit in the linux-user\ncase. It stays set to target_ulong with softmmu case.\n\nSigned-off-by: Laurent Vivier <laurent@vivier.eu>\nMessage-Id: <20180814171217.14680-1-laurent@vivier.eu>\nReviewed-by: Richard Henderson <richard.henderson@linaro.org>\n[lv: added \"%\" in TARGET_ABI_FMT_ptr \"%\"PRIx64]","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/3e23de15237c81fe7af7c3ffa299a6ae5fec7d43"},{"sha":"01ccbec7bdf6f89f1b7d46dda05e4c1fd2dd5ade","author":{"name":"Alex Williamson","email":"7469de9b95ba379e2656fa9677689657c47a7690@redhat.com"},"message":"balloon: Allow multiple inhibit users\n\nA simple true/false internal state does not allow multiple users.  Fix\nthis within the existing interface by converting to a counter, so long\nas the counter is elevated, ballooning is inhibited.\n\nReviewed-by: David Hildenbrand <david@redhat.com>\nReviewed-by: Peter Xu <peterx@redhat.com>\nReviewed-by: Cornelia Huck <cohuck@redhat.com>\nSigned-off-by: Alex Williamson <alex.williamson@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/01ccbec7bdf6f89f1b7d46dda05e4c1fd2dd5ade"},{"sha":"f59489423ab79852e98d9b3025b7d99ba8da584f","author":{"name":"Alex Williamson","email":"7469de9b95ba379e2656fa9677689657c47a7690@redhat.com"},"message":"kvm: Use inhibit to prevent ballooning without synchronous mmu\n\nRemove KVM specific tests in balloon_page(), instead marking\nballooning as inhibited without KVM_CAP_SYNC_MMU support.\n\nReviewed-by: David Hildenbrand <david@redhat.com>\nReviewed-by: Peter Xu <peterx@redhat.com>\nReviewed-by: Cornelia Huck <cohuck@redhat.com>\nAcked-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Alex Williamson <alex.williamson@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/f59489423ab79852e98d9b3025b7d99ba8da584f"},{"sha":"c65ee433153b5925e183a00ebf568e160077c694","author":{"name":"Alex Williamson","email":"7469de9b95ba379e2656fa9677689657c47a7690@redhat.com"},"message":"vfio: Inhibit ballooning based on group attachment to a container\n\nWe use a VFIOContainer to associate an AddressSpace to one or more\nVFIOGroups.  The VFIOContainer represents the DMA context for that\nAdressSpace for those VFIOGroups and is synchronized to changes in\nthat AddressSpace via a MemoryListener.  For IOMMU backed devices,\nmaintaining the DMA context for a VFIOGroup generally involves\npinning a host virtual address in order to create a stable host\nphysical address and then mapping a translation from the associated\nguest physical address to that host physical address into the IOMMU.\n\nWhile the above maintains the VFIOContainer synchronized to the QEMU\nmemory API of the VM, memory ballooning occurs outside of that API.\nInflating the memory balloon (ie. cooperatively capturing pages from\nthe guest for use by the host) simply uses MADV_DONTNEED to \"zap\"\npages from QEMU's host virtual address space.  The page pinning and\nIOMMU mapping above remains in place, negating the host's ability to\nreuse the page, but the host virtual to host physical mapping of the\npage is invalidated outside of QEMU's memory API.\n\nWhen the balloon is later deflated, attempting to cooperatively\nreturn pages to the guest, the page is simply freed by the guest\nballoon driver, allowing it to be used in the guest and incurring a\npage fault when that occurs.  The page fault maps a new host physical\npage backing the existing host virtual address, meanwhile the\nVFIOContainer still maintains the translation to the original host\nphysical address.  At this point the guest vCPU and any assigned\ndevices will map different host physical addresses to the same guest\nphysical address.  Badness.\n\nThe IOMMU typically does not have page level granularity with which\nit can track this mapping without also incurring inefficiencies in\nusing page size mappings throughout.  MMU notifiers in the host\nkernel also provide indicators for invalidating the mapping on\nballoon inflation, not for updating the mapping when the balloon is\ndeflated.  For these reasons we assume a default behavior that the\nmapping of each VFIOGroup into the VFIOContainer is incompatible\nwith memory ballooning and increment the balloon inhibitor to match\nthe attached VFIOGroups.\n\nReviewed-by: Peter Xu <peterx@redhat.com>\nSigned-off-by: Alex Williamson <alex.williamson@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/c65ee433153b5925e183a00ebf568e160077c694"},{"sha":"238e91728503d400e1c4e644e3a9b80f9e621682","author":{"name":"Alex Williamson","email":"7469de9b95ba379e2656fa9677689657c47a7690@redhat.com"},"message":"vfio/ccw/pci: Allow devices to opt-in for ballooning\n\nIf a vfio assigned device makes use of a physical IOMMU, then memory\nballooning is necessarily inhibited due to the page pinning, lack of\npage level granularity at the IOMMU, and sufficient notifiers to both\nremove the page on balloon inflation and add it back on deflation.\nHowever, not all devices are backed by a physical IOMMU.  In the case\nof mediated devices, if a vendor driver is well synchronized with the\nguest driver, such that only pages actively used by the guest driver\nare pinned by the host mdev vendor driver, then there should be no\noverlap between pages available for the balloon driver and pages\nactively in use by the device.  Under these conditions, ballooning\nshould be safe.\n\nvfio-ccw devices are always mediated devices and always operate under\nthe constraints above.  Therefore we can consider all vfio-ccw devices\nas balloon compatible.\n\nThe situation is far from straightforward with vfio-pci.  These\ndevices can be physical devices with physical IOMMU backing or\nmediated devices where it is unknown whether a physical IOMMU is in\nuse or whether the vendor driver is well synchronized to the working\nset of the guest driver.  The safest approach is therefore to assume\nall vfio-pci devices are incompatible with ballooning, but allow user\nopt-in should they have further insight into mediated devices.\n\nSigned-off-by: Alex Williamson <alex.williamson@redhat.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/238e91728503d400e1c4e644e3a9b80f9e621682"},{"sha":"a544c9110d3971cc764c2dcd86a55b28534e4a63","author":{"name":"Peter Maydell","email":"313afa09ce093b19ae1dd74f57c1ebd94508584c@linaro.org"},"message":"Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20180817.0' into staging\n\nVFIO update 2018-08-17\n\n - Enhance balloon inhibitor for multiple users and use around vfio\n   device assignment (Alex Williamson)\n\n# gpg: Signature made Fri 17 Aug 2018 17:43:37 BST\n# gpg:                using RSA key 239B9B6E3BB08B22\n# gpg: Good signature from \"Alex Williamson <alex.williamson@redhat.com>\"\n# gpg:                 aka \"Alex Williamson <alex@shazbot.org>\"\n# gpg:                 aka \"Alex Williamson <alwillia@redhat.com>\"\n# gpg:                 aka \"Alex Williamson <alex.l.williamson@gmail.com>\"\n# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22\n\n* remotes/awilliam/tags/vfio-update-20180817.0:\n  vfio/ccw/pci: Allow devices to opt-in for ballooning\n  vfio: Inhibit ballooning based on group attachment to a container\n  kvm: Use inhibit to prevent ballooning without synchronous mmu\n  balloon: Allow multiple inhibit users\n\nSigned-off-by: Peter Maydell <peter.maydell@linaro.org>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/a544c9110d3971cc764c2dcd86a55b28534e4a63"},{"sha":"751522275a800c0d1c215b386a17f537bc76cd37","author":{"name":"Yuval Shaia","email":"83e4ffed649926897bb0fe5a03abb173082dd891@oracle.com"},"message":"hw/rdma: Make distinction between device init and start modes\n\nThere are certain operations that are well considered as part of device\nconfiguration while others are needed only when \"start\" command is\ntriggered by the guest driver. An example of device initialization step\nis msix_init and example of \"device start\" stage is the creation of a CQ\ncompletion handler thread.\n\nDriver expects such distinction - implement it.\n\nSigned-off-by: Yuval Shaia <yuval.shaia@oracle.com>\nReviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>\nMessage-Id: <20180805153518.2983-2-yuval.shaia@oracle.com>\nSigned-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/751522275a800c0d1c215b386a17f537bc76cd37"},{"sha":"b462a1348031e4731b25abd615529f56cc524bc1","author":{"name":"Yuval Shaia","email":"83e4ffed649926897bb0fe5a03abb173082dd891@oracle.com"},"message":"hw/pvrdma: Bugfix - provide the correct attr_mask to query_qp\n\nCalling rdma_rm_query_qp with attr_mask equals to -1 leads to error\nwhere backend query_qp fails to retrieve the needed QP attributes.\nFix it by providing the attr_mask we got from driver.\n\nSigned-off-by: Yuval Shaia <yuval.shaia@oracle.com>\nMessage-Id: <20180805153518.2983-3-yuval.shaia@oracle.com>\nReviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>\nSigned-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/b462a1348031e4731b25abd615529f56cc524bc1"},{"sha":"ef846e026c30c39239500d0b91b26d4fecc1f1d0","author":{"name":"Yuval Shaia","email":"83e4ffed649926897bb0fe5a03abb173082dd891@oracle.com"},"message":"hw/rdma: Modify debug macros\n\n- Add line counter to ease navigation in log\n- Print rdma instead of pvrdma\n\nSigned-off-by: Yuval Shaia <yuval.shaia@oracle.com>\nReviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>\nMessage-Id: <20180805153518.2983-4-yuval.shaia@oracle.com>\nSigned-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>","distinct":true,"url":"https://api.github.com/repos/olafhering/qemu/commits/ef846e026c30c39239500d0b91b26d4fecc1f1d0"}]}
{"actor":{"display_login":"olafhering"}}