Commit Graph

12 Commits

Author SHA1 Message Date
Pierre Morel
c809bbc8e9 s390x/cpu topology: add topology entries on CPU hotplug
The topology information are attributes of the CPU and are
specified during the CPU device creation.

On hot plug we:
- calculate the default values for the topology for drawers,
  books and sockets in the case they are not specified.
- verify the CPU attributes
- check that we have still room on the desired socket

The possibility to insert a CPU in a mask is dependent on the
number of cores allowed in a socket, a book or a drawer, the
checking is done during the hot plug of the CPU to have an
immediate answer.

If the complete topology is not specified, the core is added
in the physical topology based on its core ID and it gets
defaults values for the modifier attributes.

This way, starting QEMU without specifying the topology can
still get some advantage of the CPU topology.

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Message-ID: <20231016183925.2384704-4-nsg@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-10-20 07:16:53 +02:00
Philippe Mathieu-Daudé
f5f9c6ea11 hw/s390x: Move KVM specific PV from hw/ to target/s390x/kvm/
Protected Virtualization (PV) is not a real hardware device:
it is a feature of the firmware on s390x that is exposed to
userspace via the KVM interface.

Move the pv.c/pv.h files to target/s390x/kvm/ to make this clearer.

Suggested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230624200644.23931-1-philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
2023-07-10 15:34:23 +02:00
Matthew Rosato
dd1d5fd968 s390x/pci: enable for load/store interpretation
If the ZPCI_OP ioctl reports that is is available and usable, then the
underlying KVM host will enable load/store intepretation for any guest
device without a SHM bit in the guest function handle.  For a device that
will be using interpretation support, ensure the guest function handle
matches the host function handle; this value is re-checked every time the
guest issues a SET PCI FN to enable the guest device as it is the only
opportunity to reflect function handle changes.

By default, unless interpret=off is specified, interpretation support will
always be assumed and exploited if the necessary ioctl and features are
available on the host kernel.  When these are unavailable, we will silently
revert to the interception model; this allows existing guest configurations
to work unmodified on hosts with and without zPCI interpretation support,
allowing QEMU to choose the best support model available.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20220902172737.170349-4-mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
2022-09-26 17:23:47 +02:00
Paolo Bonzini
7a523d96a0 virtio-ccw: move vhost_ccw_scsi to a separate file
Remove unecessary use of #ifdef CONFIG_VHOST_SCSI, instead just use a
separate file and a separate rule in meson.build.

Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-04-06 14:31:56 +02:00
Cho, Yu-Chen
1be53ca48c hw/s390x: only build tod-tcg from the CONFIG_TCG build
this will allow in later patches to remove unneeded stubs
in target/s390x.

Signed-off-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Cho, Yu-Chen <acho@suse.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210707105324.23400-5-acho@suse.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-07-07 14:01:54 +02:00
Cho, Yu-Chen
85f1b67d4b hw/s390x: rename tod-qemu.c to tod-tcg.c
we stop short of renaming the actual qom object though,
so type remains TYPE_QEMU_S390_TOD, ie "s390-tod-qemu".

Signed-off-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Cho, Yu-Chen <acho@suse.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210707105324.23400-3-acho@suse.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-07-07 14:01:53 +02:00
Gerd Hoffmann
adcf33a504 s390x: modularize virtio-gpu-ccw
Since the virtio-gpu-ccw device depends on the hw-display-virtio-gpu
module, which provides the type virtio-gpu-device, packaging the
hw-display-virtio-gpu module as a separate package that may or may not
be installed along with the qemu package leads to problems. Namely if
the hw-display-virtio-gpu is absent, qemu continues to advertise
virtio-gpu-ccw, but it aborts not only when one attempts using
virtio-gpu-ccw, but also when libvirtd's capability probing tries
to instantiate the type to introspect it.

Let us thus introduce a module named hw-s390x-virtio-gpu-ccw that
is going to provide the virtio-gpu-ccw device. The hw-s390x prefix
was chosen because it is not a portable device.

With virtio-gpu-ccw built as a module, the correct way to package a
modularized qemu is to require that hw-display-virtio-gpu must be
installed whenever the module hw-s390x-virtio-gpu-ccw.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Tested-by: Halil Pasic <pasic@linux.ibm.com>
Message-Id: <20210317095622.2839895-4-kraxel@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-03-26 09:33:50 +01:00
Halil Pasic
24056cbfd5 hw/s390x: fix build for virtio-9p-ccw
Commit  2c44220d05 ("meson: convert hw/arch*"), which migrated the old
Makefile.objs to meson.build  accidentally excluded virtio-ccw-9p.c and
thus the virtio-9p-ccw device from the build (and potentially also
included the file virtio-ccw-blk.c twice in the source set). And since
CONFIG_VIRTFS can't be used the way it was used here (see commit
2c9dce0196 ("meson: do not use CONFIG_VIRTFS")), the preconditions have
to be written differently.

Let's fix this!

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Fixes: 2c44220d05 ("meson: convert hw/arch*")
Reported-by: Jakob Naucke <jakob.naucke@ibm.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20210218034059.1096078-1-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-03-04 11:23:35 +01:00
Cornelia Huck
77280d33bc s390x: fix build for --without-default-devices
s390-pci-vfio.c calls into the vfio code, so we need it to be
built conditionally on vfio (which implies CONFIG_LINUX).

Fixes: cd7498d07f ("s390x/pci: Add routine to get the vfio dma available count")
Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Message-Id: <20201103123237.718242-1-cohuck@redhat.com>
Acked-by: Greg Kurz <groug@kaod.org>
Tested-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-11-05 13:04:07 +01:00
Matthew Rosato
cd7498d07f s390x/pci: Add routine to get the vfio dma available count
Create new files for separating out vfio-specific work for s390
pci. Add the first such routine, which issues VFIO_IOMMU_GET_INFO
ioctl to collect the current dma available count.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
[aw: Fix non-Linux build with CONFIG_LINUX]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-11-01 12:30:52 -07:00
Halil Pasic
bd0bbb9aba virtio: add vhost-user-fs-ccw device
Wire up the CCW device for vhost-user-fs.

Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Message-id: 20200901150019.29229-2-mhartmay@linux.ibm.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-09-23 13:41:58 +01:00
Marc-André Lureau
2c44220d05 meson: convert hw/arch*
Each architecture's sourceset is placed in an hw_arch dictionary, and picked up
from there when building the per-emulator static_library.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21 06:30:33 -04:00