- 17 5月, 2017 8 次提交
-
-
由 Eduardo Habkost 提交于
sysbus-fdc and SUNW,fdtwo devices need IRQs to be wired and mmio to be mapped, and can't be used with -device. Unset user_creatable on their device classes. Cc: John Snow <jsnow@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Cc: Thomas Huth <thuth@redhat.com> Acked-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-6-ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
amd-iommu and intel-iommu are really meant to be used with -device, so they need user_creatable=true. Remove the FIXME comment. Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-5-ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
xen-backend can be plugged/unplugged dynamically when using the Xen accelerator, so keep the user_creatable flag on the device class and remove the FIXME comment. Cc: Juergen Gross <jgross@suse.com>, Cc: Peter Maydell <peter.maydell@linaro.org>, Cc: Thomas Huth <thuth@redhat.com> Cc: sstabellini@kernel.org Cc: Markus Armbruster <armbru@redhat.com>, Cc: Marcel Apfelbaum <marcel@redhat.com>, Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: NJuergen Gross <jgross@suse.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-4-ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
commit 33cd52b5 unset cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all sysbus devices appear on "-device help" and lack the "no-user" flag in "info qdm". To fix this, we can set user_creatable=false by default on TYPE_SYS_BUS_DEVICE, but this requires setting user_creatable=true explicitly on the sysbus devices that actually work with -device. Fortunately today we have just a few has_dynamic_sysbus=1 machines: virt, pc-q35-*, ppce500, and spapr. virt, ppce500, and spapr have extra checks to ensure just a few device types can be instantiated: * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE. * ppce500 supports only TYPE_ETSEC_COMMON. * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE. This patch sets user_creatable=true explicitly on those 4 device classes. Now, the more complex cases: pc-q35-*: q35 has no sysbus device whitelist yet (which is a separate bug). We are in the process of fixing it and building a sysbus whitelist on q35, but in the meantime we can fix the "-device help" and "info qdm" bugs mentioned above. Also, despite not being strictly necessary for fixing the q35 bug, reducing the list of user_creatable=true devices will help us be more confident when building the q35 whitelist. xen: We also have a hack at xen_set_dynamic_sysbus(), that sets has_dynamic_sysbus=true at runtime when using the Xen accelerator. This hack is only used to allow xen-backend devices to be dynamically plugged/unplugged. This means today we can use -device with the following 22 device types, that are the ones compiled into the qemu-system-x86_64 and qemu-system-i386 binaries: * allwinner-ahci * amd-iommu * cfi.pflash01 * esp * fw_cfg_io * fw_cfg_mem * generic-sdhci * hpet * intel-iommu * ioapic * isabus-bridge * kvmclock * kvm-ioapic * kvmvapic * SUNW,fdtwo * sysbus-ahci * sysbus-fdc * sysbus-ohci * unimplemented-device * virtio-mmio * xen-backend * xen-sysdev This patch adds user_creatable=true explicitly to those devices, temporarily, just to keep 100% compatibility with existing behavior of q35. Subsequent patches will remove user_creatable=true from the devices that are really not meant to user-creatable on any machine, and remove the FIXME comment from the ones that are really supposed to be user-creatable. This is being done in separate patches because we still don't have an obvious list of devices that will be whitelisted by q35, and I would like to get each device reviewed individually. Cc: Alexander Graf <agraf@suse.de> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Frank Blaschka <frank.blaschka@de.ibm.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: John Snow <jsnow@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Cc: Prasad J Pandit <pjp@fedoraproject.org> Cc: qemu-arm@nongnu.org Cc: qemu-block@nongnu.org Cc: qemu-ppc@nongnu.org Cc: Richard Henderson <rth@twiddle.net> Cc: Rob Herring <robh@kernel.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: sstabellini@kernel.org Cc: Thomas Huth <thuth@redhat.com> Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Acked-by: NJohn Snow <jsnow@redhat.com> Acked-by: NJuergen Gross <jgross@suse.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-3-ehabkost@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> [ehabkost: Small changes at sysbus_device_class_init() comments] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd6 to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: NAlistair Francis <alistair.francis@xilinx.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Acked-by: NMarcel Apfelbaum <marcel@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Stefano Stabellini 提交于
Use the common utility function, which contains checks on return values and first calls F_GETFD as recommended by POSIX.1-2001, instead of manually calling fcntl. CID: 1374831 Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com CC: Eric Blake <eblake@redhat.com>
-
由 Stefano Stabellini 提交于
CID: 1374836 Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> CC: anthony.perard@citrix.com CC: groug@kaod.org CC: aneesh.kumar@linux.vnet.ibm.com
-
由 Stefano Stabellini 提交于
The Xen mapcache is able to create long term mappings, they are called "locked" mappings. The third parameter of the xen_map_cache call specifies if a mapping is a "locked" mapping. >From the QEMU point of view there are two kinds of long term mappings: [a] device memory mappings, such as option roms and video memory [b] dma mappings, created by dma_memory_map & friends After certain operations, ballooning a VM in particular, Xen asks QEMU kindly to destroy all mappings. However, certainly [a] mappings are present and cannot be removed. That's not a problem as they are not affected by balloonning. The *real* problem is that if there are any mappings of type [b], any outstanding dma operations could fail. This is a known shortcoming. In other words, when Xen asks QEMU to destroy all mappings, it is an error if any [b] mappings exist. However today we have no way of distinguishing [a] from [b]. Because of that, we cannot even print a decent warning. This patch introduces a new "dma" bool field to MapCacheRev entires, to remember if a given mapping is for dma or is a long term device memory mapping. When xen_invalidate_map_cache is called, we print a warning if any [b] mappings exist. We ignore [a] mappings. Mappings created by qemu_map_ram_ptr are assumed to be [a], while mappings created by address_space_map->qemu_ram_ptr_length are assumed to be [b]. The goal of the patch is to make debugging and system understanding easier. Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 15 5月, 2017 1 次提交
-
-
由 Greg Kurz 提交于
When using the mapped-file security mode, we shouldn't let the client mess with the metadata. The current code already tries to hide the metadata dir from the client by skipping it in local_readdir(). But the client can still access or modify it through several other operations. This can be used to escalate privileges in the guest. Affected backend operations are: - local_mknod() - local_mkdir() - local_open2() - local_symlink() - local_link() - local_unlinkat() - local_renameat() - local_rename() - local_name_to_path() Other operations are safe because they are only passed a fid path, which is computed internally in local_name_to_path(). This patch converts all the functions listed above to fail and return EINVAL when being passed the name of the metadata dir. This may look like a poor choice for errno, but there's no such thing as an illegal path name on Linux and I could not think of anything better. This fixes CVE-2017-7493. Reported-by: NLeo Gaspard <leo@gaspard.io> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com>
-
- 12 5月, 2017 21 次提交
-
-
由 Thomas Huth 提交于
When starting QEMU with the legacy USB serial device like this: qemu-system-x86_64 -usbdevice serial:vendorid=0x1234:stdio it currently aborts since the vendorid property does not exist anymore (it has been removed by commit f29783f7): Unexpected error in object_property_find() at qemu/qom/object.c:1008: qemu-system-x86_64: -usbdevice serial:vendorid=0x1234:stdio: Property '.vendorid' not found Aborted (core dumped) Fix this crash by issuing a more friendly error message instead (and simplify the code also a little bit this way). Signed-off-by: NThomas Huth <thuth@redhat.com> Message-id: 1493883704-27604-1-git-send-email-thuth@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Ladi Prosek 提交于
The strict td link limit added by commit "05f43d44 xhci: limit the number of link trbs we are willing to process" causes problems with Windows guests. Let's raise the limit. This change is analogous to: commit ab6b1105 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue Mar 7 09:40:18 2017 +0100 ohci: relax link check Signed-off-by: NLadi Prosek <lprosek@redhat.com> Message-id: 20170512102100.22675-1-lprosek@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Ladi Prosek 提交于
The spec says: Suspend: (PORT_SUSPEND) This field indicates whether or not the device on this port is suspended. Setting this field causes the device to suspend by not propagating bus traffic downstream. This field may be reset by a request or by resume signaling from the device attached to the port. I can't find any specific statement like "the PORT_SUSPEND field is reset automatically on remote wakeup", but without this patch, the only way to reset it is via the ClearPortFeature request so the ".. or by resume signaling from the device" clause is clearly not implemented on the remote wakeup path. The default xhci Windows driver does not issue the ClearPortFeature request and suspended devices attached to a hub don't properly get out of the suspended state. Interestingly, the default uhci Windows driver *does* issue the ClearPortFeature request and does not exhibit this problem. Signed-off-by: NLadi Prosek <lprosek@redhat.com> Message-id: 20170511125314.24549-3-lprosek@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Ladi Prosek 提交于
slotid and epid were deleted from XHCITransfer in commit d6fcb293. Also deleting one unused forward declaration. Signed-off-by: NLadi Prosek <lprosek@redhat.com> Message-id: 20170511125314.24549-2-lprosek@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Don't reinvent a broken wheel, just use the hexdump function we have. Impact: low, broken code doesn't run unless you have debug logging enabled. Reported-by: N李强 <liqiang6-s@360.cn> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20170509110128.27261-1-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Move to virtio-gpu-3d.c where all the other virgl code lives too. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20170505104101.30589-2-kraxel@redhat.com
-
由 Igor Mammedov 提交于
and remove corresponding part in numa.c that uses node_cpu bitmaps. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-16-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
add machine_run_board_init() wrapper that calls machine init for now but in follow up patches it will be used to run generic machine code that should run before machine init. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-15-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-11-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
it's safe to remove thread node_id != core node_id error branch as machine_set_cpu_numa_node() also does mismatch check and is called even before any CPU is created. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-10-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-9-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Introduce machine_set_cpu_numa_node() helper that stores node mapping for CPU in MachineState::possible_cpus. CPU and node it belongs to is specified by 'props' argument. Patch doesn't remove old way of storing mapping in numa_info[X].node_cpu as removing it at the same time makes patch rather big. Instead it just mirrors mapping in possible_cpus and follow up per target patches will switch to possible_cpus and numa_info[X].node_cpu will be removed once there isn't any users left. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-7-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
it will allow switching from cpu_index to property based numa mapping in follow up patches. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1494415802-227633-5-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
it will allow switching from cpu_index to property based numa mapping in follow up patches. PS: patch changes default value of CPUState::numa_node from 0 to CPU_UNSET_NUMA_NODE_ID. The only place for x86 that would affected is monitor's 'infor numa' command which uses that field. However legacy 0 value is still preserved by pc_cpu_pre_plug() in this patch if user/numa.c hasn't set it explicitly, so there is no change in behavior. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1494415802-227633-4-git-send-email-imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
it will allow switching from cpu_index to core based numa mapping in follow up patches. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <1494415802-227633-3-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Originally CPU threads were by default assigned in round-robin fashion. However it was causing issues in guest since CPU threads from the same socket/core could be placed on different NUMA nodes. Commit fb43b73b (pc: fix default VCPU to NUMA node mapping) fixed it by grouping threads within a socket on the same node introducing cpu_index_to_socket_id() callback and commit 20bb648d (spapr: Fix default NUMA node allocation for threads) reused callback to fix similar issues for SPAPR machine even though socket doesn't make much sense there. As result QEMU ended up having 3 default distribution rules used by 3 targets /virt-arm, spapr, pc/. In effort of moving NUMA mapping for CPUs into possible_cpus, generalize default mapping in numa.c by making boards decide on default mapping and let them explicitly tell generic numa code to which node a CPU thread belongs to by replacing cpu_index_to_socket_id() with @cpu_index_to_instance_props() which provides default node_id assigned by board to specified cpu_index. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1494415802-227633-2-git-send-email-imammedo@redhat.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Currently cpu_index is implicitly auto assigned during cpu.realize() time cpu_exec_realizefn()->cpu_list_add(). It happens to match index in possible_cpus so take control over it and make board initialize cpu_index to possible_cpus index explicitly. It will at least document that board is in control of it and when '-device cpu' support comes it will keep cpu_index stable regardless of order cpus are created so it won't break migration. Within this series it will be used for internal conversion from storing cpu_index based NUMA node bitmaps to property based mapping with possible_cpus, And will allow map cpu_index to a CPU entry in possible_cpus array. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Message-Id: <1493816238-33120-5-git-send-email-imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
for now precalculate and store mp_afinity in possible_cpus as ARM cpus don't have socket/core/thread-id properties yet. In follow patches possible_cpus will be used for storing and setting NUMA node mapping and replace legacy bitmap based numa_info[node_id].node_cpu/numa_get_node_for_cpu() For the lack of better idea, this patch cannibalizes possible_cpus.cpus[x].props.thread_id so that *_cpu_index_to_props() callback could return addressable by props CPU which will be used by machine_set_cpu_numa_node() in follow up patches to assign a CPU to node. But cannibalizing is fine for now as that thread_id isn't exposed to users (no hotpluggable_cpus callback support for ARM yet) and it will be used only internally until 'device_add cpu' is supported where we can decide on which properties to use. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1493816238-33120-4-git-send-email-imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1493816238-33120-3-git-send-email-imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Laurent Vivier 提交于
When there are more nodes than available memory to put the minimum allowed memory by node, all the memory is put on the last node. This is because we put (ram_size / nb_numa_nodes) & ~((1 << mc->numa_mem_align_shift) - 1); on each node, and in this case the value is 0. This is particularly true with pseries, as the memory must be aligned to 256MB. To avoid this problem, this patch uses an error diffusion algorithm [1] to distribute equally the memory on nodes. We introduce numa_auto_assign_ram() function in MachineClass to keep compatibility between machine type versions. The legacy function is used with pseries-2.9, pc-q35-2.9 and pc-i440fx-2.9 (and previous), the new one with all others. Example: qemu-system-ppc64 -S -nographic -nodefaults -monitor stdio -m 1G -smp 8 \ -numa node -numa node -numa node \ -numa node -numa node -numa node Before: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 0 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 0 MB node 4 cpus: 4 node 4 size: 0 MB node 5 cpus: 5 node 5 size: 1024 MB After: (qemu) info numa 6 nodes node 0 cpus: 0 6 node 0 size: 0 MB node 1 cpus: 1 7 node 1 size: 256 MB node 2 cpus: 2 node 2 size: 0 MB node 3 cpus: 3 node 3 size: 256 MB node 4 cpus: 4 node 4 size: 256 MB node 5 cpus: 5 node 5 size: 256 MB [1] https://en.wikipedia.org/wiki/Error_diffusionSigned-off-by: NLaurent Vivier <lvivier@redhat.com> Message-Id: <20170502162955.1610-2-lvivier@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> [ehabkost: s/ram_size/size/ at numa_default_auto_assign_ram()] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 He Chen 提交于
This patch is going to add SLIT table support in QEMU, and provides additional option `dist` for command `-numa` to allow user set vNUMA distance by QEMU command. With this patch, when a user wants to create a guest that contains several vNUMA nodes and also wants to set distance among those nodes, the QEMU command would like: ``` -numa node,nodeid=0,cpus=0 \ -numa node,nodeid=1,cpus=1 \ -numa node,nodeid=2,cpus=2 \ -numa node,nodeid=3,cpus=3 \ -numa dist,src=0,dst=1,val=21 \ -numa dist,src=0,dst=2,val=31 \ -numa dist,src=0,dst=3,val=41 \ -numa dist,src=1,dst=2,val=21 \ -numa dist,src=1,dst=3,val=31 \ -numa dist,src=2,dst=3,val=21 \ ``` Signed-off-by: NHe Chen <he.chen@linux.intel.com> Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndrew Jones <drjones@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 11 5月, 2017 10 次提交
-
-
由 Christoph Hellwig 提交于
Signed-off-by: NKeith Busch <keith.busch@intel.com> [hch: ported over from qemu-nvme.git to mainline] Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Gerd Hoffmann 提交于
vga display update mis-calculated the region for the dirty bitmap snapshot in case the scanlines are padded. This can triggere an assert in cpu_physical_memory_snapshot_get_dirty(). Fixes: fec5e8c9Reported-by: NKevin Wolf <kwolf@redhat.com> Reported-by: N李强 <liqiang6-s@360.cn> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20170509104839.19415-1-kraxel@redhat.com
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20170509111928.30935-1-kraxel@redhat.com
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 1494449551-20227-3-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 1494449551-20227-2-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Philippe Voinov 提交于
This patch refactors ui/input.c to support absolute axis minimum values other than 0. All dependent calls to qemu_input_queue_abs have been updated to explicitly supply 0 as the axis minimum value. Signed-off-by: NPhilippe Voinov <philippevoinov@gmail.com> Message-id: 20170505133952.29885-1-philippevoinov@gmail.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 David Gibson 提交于
Logic in spapr_populate_pa_features() enables the bit advertising Hardware Transactional Memory (HTM) in the guest's device tree only when KVM advertises its availability with the KVM_CAP_PPC_HTM feature. However, this assumes that the HTM bit is off in the base template used for the device tree value. That is true for POWER8, but not for POWER9. It looks like that was accidentally changed in 9fb4541f "spapr: Enable ISA 3.0 MMU mode selection via CAS". Fixes: 9fb4541fSigned-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NThomas Huth <thuth@redhat.com>
-
由 Suraj Jitindar Singh 提交于
Now that we have added all the infrastructure we can enable a pseries TCG guest to use radix. In order to do this we have to add the appropriate bits to the ibm,arch-vec-5-platform-support vector to represent that we support both hash and radix mmu models. A radix guest can now be booted in pseries tcg mode by specifying: -cpu POWER9 Note that we assume hash, that is we allocate a hpt, until a guest tells us otherwise via a H_REGISTER_PROCESS_TABLE call with radix specified - in which case we free the hpt. If we were right and the guest is hash then there's nothing for us to do. Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
The UPRT and GTSE bits are set when a guest calls H_REGISTER_PROCESS_TABLE to choose determine how address translation is performed. Currently these bits in the LPCR are only set for the cpu which handles the H_CALL, however they need to be set for all cpus for that guest as address translation cannot be performed differently on a per cpu basis. Update the H_CALL handler to set these bits in the LPCR correctly for all cpus of the guest. Note it is the reponsibility of the guest to ensure that any secondary cpus are suspended when the H_CALL is made and thus we can safely update these values here. Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Mark Cave-Ayland 提交于
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-