BALATON Zoltan [Tue, 7 Nov 2023 18:40:17 +0000 (19:40 +0100)]
hw/ppc: Add emulation of AmigaOne XE board
The AmigaOne is a rebranded MAI Teron board that uses U-Boot firmware
with patches to support AmigaOS and is very similar to pegasos2 so can
be easily emulated sharing most code with pegasos2. The reason to
emulate it is that AmigaOS comes in different versions for AmigaOne
and PegasosII which only have drivers for one machine and firmware so
these only run on the specific machine. Adding this board allows
another AmigaOS version to be used reusing already existing peagasos2
emulation. (The AmigaOne was the first of these boards so likely most
widespread which then inspired Pegasos that was later replaced with
PegasosII due to problems with Articia S, so these have a lot of
similarity. Pegasos mainly ran MorphOS while the PegasosII version of
AmigaOS was added later and therefore less common than the AmigaOne
version.)
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Rene Engel <ReneEngel80@emailn.de> Acked-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-ID: <804935e7a5921548d630576159ae2c758fe6e275.1699382232.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
BALATON Zoltan [Fri, 27 Oct 2023 11:54:49 +0000 (13:54 +0200)]
hw/pci-host: Add emulation of Mai Logic Articia S
The Articia S is a generic chipset supporting several different CPUs
that were among others used on some PPC boards. This is a minimal
emulation of the parts needed for emulating the AmigaOne board.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Rene Engel <ReneEngel80@emailn.de> Acked-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-ID: <83822787431701cf4d460298d3e3845f362e5da1.1698406922.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (63 commits)
acpi/tests/avocado/bits: enable console logging from bits VM
acpi/tests/avocado/bits: enforce 32-bit SMBIOS entry point
hw/cxl: Add tunneled command support to mailbox for switch cci.
hw/cxl: Add dummy security state get
hw/cxl/type3: Cleanup multiple CXL_TYPE3() calls in read/write functions
hw/cxl/mbox: Add Get Background Operation Status Command
hw/cxl: Add support for device sanitation
hw/cxl/mbox: Wire up interrupts for background completion
hw/cxl/mbox: Add support for background operations
hw/cxl: Implement Physical Ports status retrieval
hw/pci-bridge/cxl_downstream: Set default link width and link speed
hw/cxl/mbox: Add Physical Switch Identify command.
hw/cxl/mbox: Add Information and Status / Identify command
hw/cxl: Add a switch mailbox CCI function
hw/pci-bridge/cxl_upstream: Move defintion of device to header.
hw/cxl/mbox: Generalize the CCI command processing
hw/cxl/mbox: Pull the CCI definition out of the CXLDeviceState
hw/cxl/mbox: Split mailbox command payload into separate input and output
hw/cxl/mbox: Pull the payload out of struct cxl_cmd and make instances constant
hw/cxl: Fix a QEMU_BUILD_BUG_ON() in switch statement scope issue.
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu:
ui: Replacing pointer in function
ui/cocoa: add zoom-to-fit display option
ui/gtk-egl: apply scale factor when calculating window's dimension
ui/gtk-egl: Check EGLSurface before doing scanout
ui/gtk: force realization of drawing area
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 7 Nov 2023 10:57:40 +0000 (18:57 +0800)]
Merge tag 'pull-xenfv.for-upstream-20231107' of git://git.infradead.org/users/dwmw2/qemu into staging
Xen PV guest support for 8.2
Add Xen PV console and network support, the former of which enables the
Xen "PV shim" to be used to support PV guests.
Also clean up the block support and make it work when the user passes
just 'drive file=IMAGE,if=xen' on the command line.
Update the documentation to reflect all of these, taking the opportunity
to simplify what it says about q35 by making unplug work for AHCI.
Ignore the VCPU_SSHOTTMR_future timer flag, and advertise the 'fixed'
per-vCPU upcall vector support, as newer upstream Xen do.
# -----BEGIN PGP SIGNATURE-----
#
# iQJIBAABCAAyFiEEvgfZ/VSAmrLEsP9fY3Ys2mfi81kFAmVJ/7EUHGR3bXcyQGlu
# ZnJhZGVhZC5vcmcACgkQY3Ys2mfi81k+/xAAswivVR4+nwz3wTSN7EboGogS3hy+
# ZsTpvbJnfprGQJAK8vv8OP4eunaCJkO/dy3M/33Dh270msmV6I/1ki0E1RIPG45D
# n5wKM1Zxk0ABvjIgdp3xiLwITTdruJ+k9aqV8U9quhjgNFdOa7yjBOG8MD32GEPZ
# KHbavJ++huOu7+DZHJRNRq4gI/fREIULoPGHVg7WuEiRDYokOOmMROXqmTHTaUkV
# yFhkofzWxlpYhh7qRQx6/A80CSf7xwCof8krjdMCOYj3XGzYVZND0z5ZfHQYEwqt
# fowhargA8gH4V3d21S/MWCaZ+QrswFXZhcnl5wuGgWakV4ChvFETKs+fz2mODWUx
# 2T13trqeFJ5ElTrSpH1iWCoSEy6KCeLecvx7c/6HPSkDYQ3w5q8dXPpqgEtXY24S
# Wcmw4PkQ+HrLX7wbSU7QLyTZjvCQLFZ3Sb0uTf2zwsJZyeCCiT2lqAaogoMm6Kg0
# m/jG1JzE+9AC3j0Upp1lS3EK1qdxIuLdBuIcaEBEjy7Am+Y14PlZYoU2c751KbRF
# kqnIOYMoijX0PJDomPqCQtYNE0mrtogo0AbcFFIu+4k25vGbkl7xS5p2du9qw2Rd
# ++IdqQYzdzrUcIwmxocFQqFBJQ2dcbOGB1d7+VJ+A1Uj3yY2/DnFG5WqSaqS0KJi
# ZhBdFs3OTlPnRoM=
# =Dg79
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 07 Nov 2023 17:13:21 HKT
# gpg: using RSA key BE07D9FD54809AB2C4B0FF5F63762CDA67E2F359
# gpg: issuer "dwmw2@infradead.org"
# gpg: Good signature from "David Woodhouse <dwmw2@infradead.org>" [unknown]
# gpg: aka "David Woodhouse <dwmw2@exim.org>" [unknown]
# gpg: aka "David Woodhouse <david@woodhou.se>" [unknown]
# gpg: aka "David Woodhouse <dwmw2@kernel.org>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: BE07 D9FD 5480 9AB2 C4B0 FF5F 6376 2CDA 67E2 F359
* tag 'pull-xenfv.for-upstream-20231107' of git://git.infradead.org/users/dwmw2/qemu:
docs: update Xen-on-KVM documentation
xen-platform: unplug AHCI disks
hw/i386/pc: support '-nic' for xen-net-device
hw/xen: update Xen PV NIC to XenDevice model
hw/xen: only remove peers of PCI NICs on unplug
hw/xen: add support for Xen primary console in emulated mode
hw/xen: update Xen console to XenDevice model
hw/xen: do not repeatedly try to create a failing backend device
hw/xen: add get_frontend_path() method to XenDeviceClass
hw/xen: automatically assign device index to block devices
hw/xen: populate store frontend nodes with XenStore PFN/port
i386/xen: advertise XEN_HVM_CPUID_UPCALL_VECTOR in CPUID
include: update Xen public headers to Xen 4.17.2 release
hw/xen: Clean up event channel 'type_val' handling to use union
i386/xen: Ignore VCPU_SSHOTTMR_future flag in set_singleshot_timer()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
build-sys: drop needless warning pragmas for old pixman
Since commit 236f282c1c7 ("configure: check for pixman-1 version"), QEMU
requires >= 0.21.8.
Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
David Woodhouse [Thu, 19 Oct 2023 14:30:23 +0000 (15:30 +0100)]
docs: update Xen-on-KVM documentation
Add notes about console and network support, and how to launch PV guests.
Clean up the disk configuration examples now that that's simpler, and
remove the comment about IDE unplug on q35/AHCI now that it's fixed.
Update the -initrd option documentation to explain how to quote commas
in module command lines, and reference it when documenting PV guests.
Also update stale avocado test filename in MAINTAINERS.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Thu, 19 Oct 2023 11:56:42 +0000 (12:56 +0100)]
xen-platform: unplug AHCI disks
To support Xen guests using the Q35 chipset, the unplug protocol needs
to also remove AHCI disks.
Make pci_xen_ide_unplug() more generic, iterating over the children
of the PCI device and destroying the "ide-hd" devices. That works the
same for both AHCI and IDE, as does the detection of the primary disk
as unit 0 on the bus named "ide.0".
Then pci_xen_ide_unplug() can be used for both AHCI and IDE devices.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Tue, 17 Oct 2023 16:53:58 +0000 (17:53 +0100)]
hw/i386/pc: support '-nic' for xen-net-device
The default NIC creation seems a bit hackish to me. I don't understand
why each platform has to call pci_nic_init_nofail() from a point in the
code where it actually has a pointer to the PCI bus, and then we have
the special cases for things like ne2k_isa.
If qmp_device_add() can *find* the appropriate bus and instantiate
the device on it, why can't we just do that from generic code for
creating the default NICs too?
But that isn't a yak I want to shave today. Add a xenbus field to the
PCMachineState so that it can make its way from pc_basic_device_init()
to pc_nic_init() and be handled as a special case like ne2k_isa is.
Now we can launch emulated Xen guests with '-nic user'.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Mon, 16 Oct 2023 15:00:23 +0000 (16:00 +0100)]
hw/xen: add support for Xen primary console in emulated mode
The primary console is special because the toolstack maps a page into
the guest for its ring, and also allocates the guest-side event channel.
The guest's grant table is even primed to export that page using a known
grant ref#. Add support for all that in emulated mode, so that we can
have a primary console.
For reasons unclear, the backends running under real Xen don't just use
a mapping of the well-known GNTTAB_RESERVED_CONSOLE grant ref (which
would also be in the ring-ref node in XenStore). Instead, the toolstack
sets the ring-ref node of the primary console to the GFN of the guest
page. The backend is expected to handle that special case and map it
with foreignmem operations instead.
We don't have an implementation of foreignmem ops for emulated Xen mode,
so just make it map GNTTAB_RESERVED_CONSOLE instead. This would probably
work for real Xen too, but we can't work out how to make real Xen create
a primary console of type "ioemu" to make QEMU drive it, so we can't
test that; might as well leave it as it is for now under Xen.
Now at last we can boot the Xen PV shim and run PV kernels in QEMU.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Mon, 16 Oct 2023 09:28:17 +0000 (10:28 +0100)]
hw/xen: do not repeatedly try to create a failing backend device
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code from recreating duplicates
of devices which already exist, is the fact that xen_device_realize()
sets the backend state to XenbusStateInitWait. If the attempt to create
the device doesn't get *that* far, that's when it will keep getting
retried.
My first thought was to handle errors by setting the backend state to
XenbusStateClosed, but that doesn't work for XenConsole which wants to
*ignore* any device of type != "ioemu" completely.
So, make xen_backend_device_create() *keep* the XenBackendInstance for a
failed device, and provide a new xen_backend_exists() function to allow
xen_bus_type_enumerate() to check whether one already exists before
creating a new one.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Sat, 14 Oct 2023 15:53:23 +0000 (16:53 +0100)]
hw/xen: add get_frontend_path() method to XenDeviceClass
The primary Xen console is special. The guest's side is set up for it by
the toolstack automatically and not by the standard PV init sequence.
Accordingly, its *frontend* doesn't appear in …/device/console/0 either;
instead it appears under …/console in the guest's XenStore node.
To allow the Xen console driver to override the frontend path for the
primary console, add a method to the XenDeviceClass which can be used
instead of the standard xen_device_get_frontend_path()
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Mon, 16 Oct 2023 12:01:39 +0000 (13:01 +0100)]
hw/xen: automatically assign device index to block devices
There's no need to force the user to assign a vdev. We can automatically
assign one, starting at xvda and searching until we find the first disk
name that's unused.
This means we can now allow '-drive if=xen,file=xxx' to work without an
explicit separate -driver argument, just like if=virtio.
Rip out the legacy handling from the xenpv machine, which was scribbling
over any disks configured by the toolstack, and didn't work with anything
but raw images.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Thu, 12 Oct 2023 09:59:45 +0000 (10:59 +0100)]
hw/xen: populate store frontend nodes with XenStore PFN/port
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
David Woodhouse [Wed, 2 Aug 2023 16:04:49 +0000 (17:04 +0100)]
hw/xen: Clean up event channel 'type_val' handling to use union
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need for the XenEvtchnPort to be so simplistic. We can
use a union for the pirq/virq/interdomain information, which lets us
keep a separate bit for the 'remote domain' in interdomain ports. A
single bit is enough since the only possible targets are loopback or
qemu itself.
So now we can ditch PORT_INFO_TYPEVAL_REMOTE_QEMU and the horrid
manual masking, although the in-memory representation is identical
so there's no change in the saved state ABI.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org>
Ani Sinha [Fri, 27 Oct 2023 03:21:19 +0000 (08:51 +0530)]
acpi/tests/avocado/bits: enable console logging from bits VM
Console logs from the VM can be useful for debugging when things go wrong.
Other avocado tests enables them. This change enables console logging with the
following changes:
- point to the newer bios bits image that actually enabled VM console.
- change the bits test to drain the console logs from the VM and write the
logs.
- wait for SHUTDOWN event from QEMU so that console logs can be drained out
of the socket before it is closed as a part of vm.wait().
Additionally, following two cosmetic changes have been made:
- Removed VM QEMU command line logging as avocado framework already logs it.
This is a minor cleanup along the way.
- Update my email to my work email in the avocado acpi bios bits test.
CC: jsnow@redhat.com Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-Id: <20231027032120.6012-3-anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Ani Sinha [Fri, 27 Oct 2023 03:21:18 +0000 (08:51 +0530)]
acpi/tests/avocado/bits: enforce 32-bit SMBIOS entry point
QEMU defaults to 64-bit entry point since the following commit bf376f3020 ("hw/i386/pc: Default to use SMBIOS 3.0 for newer machine models")
The above change is applicable for all newer machine versions from version 8.1
and newer. i440fx and q35 machine versions 8.0 and older still use 32-bit entry
points.
Unfortunately, bits currently does not recognize 64-bit entry points and hence
is not able to parse SMBIOS tables. Therefore, we need to enforce 32-bit
SMBIOS entry point in QEMU command line so that bits is able to parse the
SMBIOS tables.
Once we implement the support in bits to parse 64-bit entry points, we can
remove the extra command line that is passed to enforce a 32-bit entry point.
The support can be added to the following smbios test script:
tests/avocado/acpi-bits/bits-tests/smbios.py2 in QEMU repository.
CC: jusual@redhat.com CC: imammedo@redhat.com Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-Id: <20231027032120.6012-2-anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:08:06 +0000 (17:08 +0100)]
hw/cxl: Add tunneled command support to mailbox for switch cci.
This implementation of tunneling makes the choice that our Type 3 device is
a Logical Device (LD) of a Multi-Logical Device (MLD) that just happens to
only have one LD for now.
Tunneling is supported from a Switch Mailbox CCI (and shortly via MCTP over
I2C connected to the switch MCTP CCI) via an outer level to the FM owned LD
in the MLD Type 3 device. From there an inner tunnel may be used to access
particular LDs.
Protocol wise, the following is what happens in a real system but we
don't emulate the transports - just the destinations and the payloads.
( Host -> Switch Mailbox CCI - in band FM-API mailbox command
or
Host -> Switch MCTP CCI - MCTP over I2C using the CXL FM-API
MCTP Binding.
)
then (if a tunnel command)
Switch -> Type 3 FM Owned LD - MCTP over PCI VDM using the
CXL FM-API binding (addressed by switch port)
then (if unwrapped command also a tunnel command)
Type 3 FM Owned LD to LD0 via internal transport
(addressed by LD number)
or (added shortly)
Host to Type 3 FM Owned MCTP CCI - MCTP over I2C using the
CXL FM-API MCTP Binding.
then (if unwrapped comand is a tunnel comamnd)
Type 3 FM Owned LD to LD0 via internal transport.
(addressed by LD number)
It is worth noting that the tunneling commands over PCI VDM
presumably use the appropriate MCTP binding depending on opcode.
This may be the CXL FMAPI binding or the CXL Memory Device Binding.
Additional commands will need to be added to make this
useful beyond testing the tunneling works.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-18-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:08:05 +0000 (17:08 +0100)]
hw/cxl: Add dummy security state get
Needed to allow the santize comamnds to be tested with proposed Linux Kernel
support. Default value + no control of the security state will work for now.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-17-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Gregory Price [Mon, 23 Oct 2023 16:08:04 +0000 (17:08 +0100)]
hw/cxl/type3: Cleanup multiple CXL_TYPE3() calls in read/write functions
Call CXL_TYPE3 once at top of function to avoid multiple invocations.
Signed-off-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-16-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:08:03 +0000 (17:08 +0100)]
hw/cxl/mbox: Add Get Background Operation Status Command
For now, provide this command on type 3 main mailbox only.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-15-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Davidlohr Bueso [Mon, 23 Oct 2023 16:08:02 +0000 (17:08 +0100)]
hw/cxl: Add support for device sanitation
Make use of the background operations through the sanitize command, per CXL
3.0 specs. Traditionally run times can be rather long, depending on the
size of the media.
Estimate times based on:
https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-14-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Davidlohr Bueso [Mon, 23 Oct 2023 16:08:01 +0000 (17:08 +0100)]
hw/cxl/mbox: Wire up interrupts for background completion
Notify when the background operation is done. Note that for now background
commands are only supported on the main Type 3 mailbox.
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-13-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Davidlohr Bueso [Mon, 23 Oct 2023 16:08:00 +0000 (17:08 +0100)]
hw/cxl/mbox: Add support for background operations
Support background commands in the mailbox, and update
cmd_infostat_bg_op_sts() accordingly. This patch does not implement mbox
interrupts upon completion, so the kernel driver must rely on polling to
know when the operation is done.
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-12-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:59 +0000 (17:07 +0100)]
hw/cxl: Implement Physical Ports status retrieval
Add this command for both the Switch CCI in switch upstream ports.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-11-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:58 +0000 (17:07 +0100)]
hw/pci-bridge/cxl_downstream: Set default link width and link speed
Without these being set the PCIE Link Capabilities register has
invalid values in these two fields.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-10-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:56 +0000 (17:07 +0100)]
hw/cxl/mbox: Add Information and Status / Identify command
Add this command that is only available via out of band CCIs. It replicates
information that can be discovered inband via PCI config space.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-8-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:55 +0000 (17:07 +0100)]
hw/cxl: Add a switch mailbox CCI function
CXL switch CCIs were added in CXL r3.0. They are a PCI function,
identified by class code that provides a CXL mailbox (identical
to that previously defined for CXL type 3 memory devices) over which
various FM-API commands may be used. Whilst the intent of this
feature is enable switch control from a BMC attached to a switch
upstream port, it is also useful to allow emulation of this feature
on the upstream port connected to a host using the CXL devices as
this greatly simplifies testing.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-7-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:54 +0000 (17:07 +0100)]
hw/pci-bridge/cxl_upstream: Move defintion of device to header.
To avoid repetition of switch upstream port specific data in the
CXLDeviceState structure it will be necessary to access the switch USP
specific data from mailbox callbacks. Hence move it to cxl_device.h so it
is no longer an opaque structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023160806.13206-6-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:53 +0000 (17:07 +0100)]
hw/cxl/mbox: Generalize the CCI command processing
By moving the parts of the mailbox command handling that are CCI type
specific out to the caller, make the main handling code generic. Rename it
to cxl_process_cci_message() to reflect this new generality.
Change the type3 mailbox handling (reused shortly for the switch
mailbox CCI) to take a snapshot of the mailbox input data rather
than operating on it in place. This reduces the chance of bugs
due to aliasing going forwars.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:52 +0000 (17:07 +0100)]
hw/cxl/mbox: Pull the CCI definition out of the CXLDeviceState
Enables having multiple CCIs per devices. Each CCI (mailbox) has it's own
state and command list, so they can't share a single structure.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-4-Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:51 +0000 (17:07 +0100)]
hw/cxl/mbox: Split mailbox command payload into separate input and output
New CCI types that will be supported shortly do not have a single buffer
used in both directions. As such, split it up. To avoid the complexities
of implementing all commands to handle potential aliasing, take a copy of
the input before use.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023160806.13206-3-Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 16:07:50 +0000 (17:07 +0100)]
hw/cxl/mbox: Pull the payload out of struct cxl_cmd and make instances constant
Putting the pointer in the structure for command handling puts a single
variable element inside an otherwise constant structure. Move it out as
a directly passed variable and take the cxl_cmd structures constant.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023160806.13206-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 14:02:10 +0000 (15:02 +0100)]
hw/cxl: Fix a QEMU_BUILD_BUG_ON() in switch statement scope issue.
As _Static_assert is a declaration, it can't follow a label until C23.
Some older versions of GCC trip up on this one.
This check has no obvious purpose so just remove it.
Reported-by: Jeongtae Park <jtp.park@samsung.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20231023140210.3089-6-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 14:02:09 +0000 (15:02 +0100)]
hw/cxl: Line length reductions
Michael Tsirkin observed that there were some unnecessarily
long lines in the CXL code in a recent review.
This patch is intended to rectify that where it does not
hurt readability.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023140210.3089-5-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 14:02:08 +0000 (15:02 +0100)]
hw/cxl: CXLDVSECPortExtensions renamed to CXLDVSECPortExt
Done to reduce line lengths where this is used.
Ext seems sufficiently obvious that it need not be spelt out
fully.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023140210.3089-4-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 14:02:07 +0000 (15:02 +0100)]
hw/cxl: Use switch statements for read and write of cachemem registers
Establishing that only register accesses of size 4 and 8 can occur
using these functions requires looking at their callers. Make it
easier to see that by using switch statements.
Assertions are used to enforce that the register storage is of the
matching size, allowing fixed values to be used for divisors of
the array indices.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023140210.3089-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jonathan Cameron [Mon, 23 Oct 2023 14:02:06 +0000 (15:02 +0100)]
hw/cxl: Use a switch to explicitly check size in caps_reg_read()
Bring this read function inline with the others that do
check for unexpected size values.
Also reduces line lengths to sub 80 chars.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Fan Ni <fan.ni@samsung.com>
Message-Id: <20231023140210.3089-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20231023094635.1588282-17-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:34 +0000 (17:46 +0800)]
tests: bios-tables-test: Add test for smbios type4 thread count2
This tests the commit 7298fd7de5551 ("hw/smbios: Fix thread count in
type4").
In smbios_build_type_4_table() (hw/smbios/smbios.c), if the number of
threads in the socket is more than 255, then smbios type4 table encodes
threads per socket into the thread count2 field.
So for the topology in this case, there're the following considerations:
1. threads per socket should be more than 255 to ensure we could cover
the thread count2 field.
2. The original bug was that threads per socket was miscalculated, so
now we should configure as many topology levels as possible (multiple
dies, no module since x86 hasn't supported it) to cover more general
topology scenarios, to ensure that the threads per socket encoded in
the thread count2 field is correct.
3. For the more general topology, we should also add "cpus" (presented
threads for machine) and "maxcpus" (total threads for machine) to
make sure that configuring unpluged CPUs in smp (cpus < maxcpus)
does not affect the correctness of threads per socket for thread
count2 field.
Note we don't consider the topology with multiple sockets since this
topology would create too many vCPUs (more than 255 threads per socket
with at least 2 sockets, which may cause the failure "Number of
hotpluggable cpus requested (*) exceeds the maximum cpus supported by
KVM (*) socket_accept failed: Resource temporarily unavailable"), and
the calculation of threads per socket has already been covered by
"thread count" test case.
Based on these considerations, select the topology as the follow:
The expected thread count2 = threads per socket = threads (2)
* cores (65) * dies (2) = 260.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20231023094635.1588282-16-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:33 +0000 (17:46 +0800)]
tests: bios-tables-test: Prepare the ACPI table change for smbios type4 thread count2 test
Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 1 - 3.
List the ACPI tables that will be added to test the thread count2 field
of smbios type4 table.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-15-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-14-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:31 +0000 (17:46 +0800)]
tests: bios-tables-test: Add test for smbios type4 thread count
This tests the commit 7298fd7de5551 ("hw/smbios: Fix thread count in
type4").
In smbios_build_type_4_table() (hw/smbios/smbios.c), if the number of
threads in the socket is not more than 255, then smbios type4 table
encodes threads per socket into the thread count field.
So for the topology in this case, there're the following considerations:
1. threads per socket should be not more than 255 to ensure we could
cover the thread count field.
2. The original bug was that threads per socket was miscalculated, so
now we should configure as many topology levels as possible (multiple
sockets & dies, no module since x86 hasn't supported it) to cover
more general topology scenarios, to ensure that the threads per
socket encoded in the thread count field is correct.
3. For the more general topology, we should also add "cpus" (presented
threads for machine) and "maxcpus" (total threads for machine) to
make sure that configuring unpluged CPUs in smp (cpus < maxcpus)
does not affect the correctness of threads per socket for thread
count field.
Based on these considerations, select the topology as the follow:
The expected thread count = threads per socket = threads (3) * cores (3)
* dies (3) = 27.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-13-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:30 +0000 (17:46 +0800)]
tests: bios-tables-test: Prepare the ACPI table change for smbios type4 thread count test
Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 1 - 3.
List the ACPI tables that will be added to test the thread count field
of smbios type4 table.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-12-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-11-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:28 +0000 (17:46 +0800)]
tests: bios-tables-test: Extend smbios core count2 test to cover general topology
The commit 196ea60a734c3 ("hw/smbios: Fix core count in type4") fixed
the miscalculation of cores per socket.
The original core count2 test (with the topology configured by
"-smp 275") didn't recognize that topology-related but because it just
created a special topology with only one socket and one die by default,
ignoring the effect of more topology levels (between socket and core) on
the cores per socket calculation.
So for the topology in this case, there're the following considerations:
1. cores per socket should be more than 255 to ensure we could cover
the core count2 field.
2. The original bug was that cores per socket was miscalculated, so now
we should include as many topology levels as possible (multiple
sockets or dies, no module since x86 hasn't supported it) to cover
more general topology scenarios, to ensure that the cores per socket
encoded in the core count2 field is correct.
Based on these considerations, select the topology with multiple dies:
-smp 260,dies=2,cores=130,threads=1
Note, here we doesn't configure multiple sockets to avoid the error
("kvm_init_vcpu: kvm_get_vcpu failed (*): Too many open files") if user
uses the default ulimit seeting on his machine.
And the cores per socket calculation for multiple sockets has already
been covered by the core count test case, so that only multiple dies
configuration is enough.
The expected core count2 = cores per socket = cores (130) * dies (2) =
260.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-10-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:27 +0000 (17:46 +0800)]
tests: bios-tables-test: Prepare the ACPI table change for smbios type4 core count2 test
Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 1 - 3.
List the ACPI tables that will be changed about the type 4 core count2
test case.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-9-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-8-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:25 +0000 (17:46 +0800)]
tests: bios-tables-test: Add test for smbios type4 core count
This tests the commit 196ea60a734c3 ("hw/smbios: Fix core count in
type4").
In smbios_build_type_4_table() (hw/smbios/smbios.c), if the number of
cores in the socket is not more than 255, then smbios type4 table
encodes cores per socket into the core count field.
So for the topology in this case, there're the following considerations:
1. cores per socket should be not more than 255 to ensure we could cover
the core count field.
2. The original bug was that cores per socket was miscalculated, so now
we should include as many topology levels as possible (mutiple
sockets & dies, no module since x86 hasn't supported it) to cover
more general topology scenarios, to ensure that the cores per socket
encoded in the core count field is correct.
Based on these considerations, select the topology with multiple sockets
and dies:
-smp 54,sockets=2,dies=3,cores=3,threads=3
The expected core count = cores per socket = cores (3) * dies (3) = 9.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-7-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:24 +0000 (17:46 +0800)]
tests: bios-tables-test: Prepare the ACPI table change for smbios type4 core count test
Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 1 - 3.
List the ACPI tables that will be added to test the type 4 core count
field.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-6-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:22 +0000 (17:46 +0800)]
tests: bios-tables-test: Add test for smbios type4 count
This tests the commit d79a284a44bb7 ("hw/smbios: Fix smbios_smp_sockets
calculation").
In smbios_get_tables() (hw/smbios/smbios.c), smbios type4 table is built
for each socket, so the count of type4 tables should be equal to the
number of sockets.
Thus for the topology in this case, there're the following considerations:
1. The topology should include multiple sockets to ensure smbios could
create type4 tables for each socket.
2. In addition to sockets, for the more general topology, we should also
configure as many topology levels as possible (multiple dies, no
module since x86 hasn't supported it), to ensure that smbios is able
to exclude the effect of other topology levels to create the type4
tables only for sockets.
3. The original miscalculation bug also misused "smp.cpus", so it's
necessary to configure "cpus" (presented threads for machine) and
"maxcpus" (total threads for machine) as well to make sure that
configuring unpluged CPUs in smp (cpus < maxcpus) does not affect
the correctness of the count of type4 tables.
Based on these considerations, select the topology as the follow:
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-4-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhao Liu [Mon, 23 Oct 2023 09:46:21 +0000 (17:46 +0800)]
tests: bios-tables-test: Prepare the ACPI table change for smbios type4 count test
Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 1 - 3.
List the ACPI tables that will be added to test the type 4 count.
Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-3-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Test the commit a1d027be95bc3 ("machine: Add helpers to get cores/
threads per socket").
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20231023094635.1588282-2-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hawkins Jiawei [Wed, 25 Oct 2023 01:08:06 +0000 (09:08 +0800)]
vdpa: Allow VIRTIO_NET_F_RSS in SVQ
Enable SVQ with VIRTIO_NET_F_RSS feature.
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <626449eb303207de408126b3dc7c155cd72b028b.1698195059.git.yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hawkins Jiawei [Wed, 25 Oct 2023 01:08:05 +0000 (09:08 +0800)]
vdpa: Restore receive-side scaling state
This patch reuses vhost_vdpa_net_load_rss() with some
refactorings to restore the receive-side scaling state
at device's startup.
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <cf5b78a16ed0318982ceffb195f2227f6aad4ac1.1698195059.git.yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hawkins Jiawei [Wed, 25 Oct 2023 01:08:04 +0000 (09:08 +0800)]
vdpa: Add SetSteeringEBPF method for NetClientState
At present, to enable the VIRTIO_NET_F_RSS feature, eBPF must
be loaded for the vhost backend.
Given that vhost-vdpa is one of the vhost backend, we need to
implement the SetSteeringEBPF method to support RSS for vhost-vdpa,
even if vhost-vdpa calculates the rss hash in the hardware device
instead of in the kernel by eBPF.
Although this requires QEMU to be compiled with `--enable-bpf`
configuration even if the vdpa device does not use eBPF to
calculate the rss hash, this can avoid adding the specific
conditional statements for vDPA case to enable the VIRTIO_NET_F_RSS
feature, which reduces code maintainbility.
Suggested-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <280e20ddce55b6de60f1552ba0865bffffe909b2.1698195059.git.yin31149@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hawkins Jiawei [Wed, 25 Oct 2023 01:02:25 +0000 (09:02 +0800)]
vdpa: Allow VIRTIO_NET_F_HASH_REPORT in SVQ
Enable SVQ with VIRTIO_NET_F_HASH_REPORT feature.
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <d66b0aee501cdad7954231900c35a11cad1e13db.1698194366.git.yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hawkins Jiawei [Wed, 25 Oct 2023 01:02:24 +0000 (09:02 +0800)]
vdpa: Restore hash calculation state
This patch introduces vhost_vdpa_net_load_rss() to restore
the hash calculation state at device's startup.
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Message-Id: <dbf699acff8c226596136a55a6abe35ebfeac8b0.1698194366.git.yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This commit adds basic documentation for using virtio-snd.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <e7fb941cf7636fdff40cbdcdcd660dec5f15ca3c.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
To perform audio capture we duplicate the TX logic of the previous
commit with the following difference: we receive data from the QEMU
audio backend and write it in the virt queue IO buffers the guest sends
to QEMU. When they are full (i.e. they have `period_bytes` amount of
data) or when recording stops in QEMU's audio backend, the buffer is
returned to the guest by notifying it.
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <e56a17741a24ccadfbbea19d3c60c9406b795b23.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Handle output IO messages in the transmit (TX) virtqueue.
It allocates a VirtIOSoundPCMBuffer for each IO message and copies the
data buffer to it. When the IO buffer is written to the host's sound
card, the guest will be notified that it has been consumed.
The lifetime of an IO message is:
1. Guest sends IO message to TX virtqueue.
2. QEMU adds it to the appropriate stream's IO buffer queue.
3. Sometime later, the host audio backend calls the output callback,
virtio_snd_pcm_out_cb(), which is defined with an AUD_open_out()
call. The callback gets an available number of bytes the backend can
receive. Then it writes data from the IO buffer queue to the backend.
If at any time a buffer is exhausted, it is returned to the guest as
completed.
4. If the guest releases the stream, its buffer queue is flushed by
attempting to write any leftover data to the audio backend and
releasing all IO messages back to the guest. This is how according to
the spec the guest knows the release was successful.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <b7c6fc458c763d09a4abbcb620ae9b220afa5b8f.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Handle the PCM release control request, which is necessary for flushing
pending sound IO. No IO is handled yet so currently it only replies to
the request.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <ae0afa16461429df1a2f268313d5bfcca27479ec.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Handles the PCM prepare control request. It initializes a PCM stream
when the guests asks for it.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <c6a9c437ef48e45f083fc957dcf7fe18a028e657.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Handle the set parameters control request. It reconfigures a stream
based on a guest's preference if the values are valid and supported.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <d0d19928691f9375bfd83388806786cb7b161301.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Handle the start and stop control messages for a stream_id. This request
does nothing at the moment except for replying to it. Audio playback
or capture will be started/stopped here in follow-up commits.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <9657dbfe3cb4a48ceb033ceb5977dc08669dfefd.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Respond to the VIRTIO_SND_R_PCM_INFO control request with the parameters
of each requested PCM stream.
Based-on: https://github.com/OpenSynergy/qemu/commit/5a2f350eec5d157b90d9c7b40a8e603f4da92471 Signed-off-by: Igor Skalkin <Igor.Skalkin@opensynergy.com> Signed-off-by: Anton Yakovlev <Anton.Yakovlev@opensynergy.com> Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <5ecea6ba2fb0e3957d7d90bc4dbac521a3d1f678.1698062525.git.manos.pitsidianakis@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
projects / qemu-xen.git / log