Re: [PATCH v2 1/2] Revert "vhost-user: fix lost reconnect"

2024-05-13 Thread Michael S. Tsirkin
On Mon, May 13, 2024 at 03:10:47PM +0800, Li Feng wrote: > This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. > include subject of reverted commit and motivation for the revert pls. > Signed-off-by: Li Feng > --- > hw/block/vhost-user-blk.c | 2 +- >

[PULL 6/7] vhost-user-blk: simplify and fix vhost_user_blk_handle_config_change

2024-04-09 Thread Michael S. Tsirkin
e guest unconditionally. So, no reason to create extra branches in the logic. Signed-off-by: Vladimir Sementsov-Ogievskiy Acked-by: Raphael Norwitz Message-Id: <20240329183758.3360733-2-vsement...@yandex-team.ru> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- h

Re: [PATCH-for-9.1 v2 0/3] rdma: Remove RDMA subsystem and pvrdma device

2024-03-29 Thread Michael S. Tsirkin
On Thu, Mar 28, 2024 at 02:02:52PM +0100, Philippe Mathieu-Daudé wrote: > Since v1: > - split in 3 (Thomas) > - justify gluster removal Reviewed-by: Michael S. Tsirkin > Philippe Mathieu-Daudé (3): > hw/rdma: Remove pvrdma device and rdmacm-mux helper > migration: Re

Re: [PATCH-for-9.1] rdma: Remove RDMA subsystem and pvrdma device

2024-03-28 Thread Michael S. Tsirkin
On Thu, Mar 28, 2024 at 07:43:06AM +0100, Thomas Huth wrote: > On 27/03/2024 11.55, Philippe Mathieu-Daudé wrote: > > The whole RDMA subsystem was deprecated in commit e9a54265f5 > > ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") > > released in v8.2. Time to remove it. > > > >

Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

2024-03-18 Thread Michael S. Tsirkin
On Fri, Mar 15, 2024 at 04:59:49PM +0100, Kevin Wolf wrote: > VDUSE requires that virtqueues are first enabled before the DRIVER_OK > status flag is set; with the current API of the kernel module, it is > impossible to enable the opposite order in our block export code because > userspace is not

Re: [PATCH for-9.0 v3] vdpa-dev: Fix initialisation order to restore VDUSE compatibility

2024-03-18 Thread Michael S. Tsirkin
On Mon, Mar 18, 2024 at 12:31:26PM +0800, Jason Wang wrote: > On Fri, Mar 15, 2024 at 11:59 PM Kevin Wolf wrote: > > > > VDUSE requires that virtqueues are first enabled before the DRIVER_OK > > status flag is set; with the current API of the kernel module, it is > > impossible to enable the

[PULL 44/68] pcie_sriov: Reset SR-IOV extended capability

2024-03-12 Thread Michael S. Tsirkin
() with pcie_sriov_pf_reset(), which does not only disable VFs but also resets the capability. Signed-off-by: Akihiko Odaki Message-Id: <20240228-reuse-v8-3-282660281...@daynix.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Reviewed-by: Sriram Yagnaraman --- include/hw/pci/pcie_sriov.

[PULL 42/68] hw/nvme: Use pcie_sriov_num_vfs()

2024-03-12 Thread Michael S. Tsirkin
pport for the Virtualization Management command") Suggested-by: Michael S. Tsirkin Signed-off-by: Akihiko Odaki Message-Id: <20240228-reuse-v8-1-282660281...@daynix.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/nvme/ctrl.c | 26 --

[PULL 46/68] hw/pci: Always call pcie_sriov_pf_reset()

2024-03-12 Thread Michael S. Tsirkin
From: Akihiko Odaki Call pcie_sriov_pf_reset() from pci_do_device_reset() just as we do for msi_reset() and msix_reset() to prevent duplicating code for each SR-IOV PF. Signed-off-by: Akihiko Odaki Message-Id: <20240228-reuse-v8-5-282660281...@daynix.com> Reviewed-by: Michael S. T

Re: [PATCH v6 3/3] hw/nvme: Add SPDM over DOE support

2024-03-12 Thread Michael S. Tsirkin
On Mon, Mar 11, 2024 at 11:15:37AM +1000, Alistair Francis wrote: > From: Wilfred Mallawa > > Setup Data Object Exchance (DOE) as an extended capability for the NVME > controller and connect SPDM to it (CMA) to it. > > Signed-off-by: Wilfred Mallawa > Signed-off-by: Alistair Francis >

Re: [PATCH v8 00/15] hw/pci: SR-IOV related fixes and improvements

2024-03-12 Thread Michael S. Tsirkin
v: Do not manually unrealize". > - Restored patch "pcie_sriov: Release VFs failed to realize" that was > missed in v5. > - Link to v5: > https://lore.kernel.org/r/20240218-reuse-v5-0-e4fc1c19b...@daynix.com > > Changes in v5: > - Added patch "hw/pci: Always

Re: [PATCH v6 08/15] pcie_sriov: Reuse SR-IOV VF device instances

2024-03-12 Thread Michael S. Tsirkin
On Tue, Feb 20, 2024 at 09:24:43PM +0900, Akihiko Odaki wrote: > Disable SR-IOV VF devices by reusing code to power down PCI devices > instead of removing them when the guest requests to disable VFs. This > allows to realize devices and report VF realization errors at PF > realization time. > >

Re: [PATCH v6 07/15] pcie_sriov: Do not manually unrealize

2024-03-12 Thread Michael S. Tsirkin
On Tue, Feb 20, 2024 at 09:24:42PM +0900, Akihiko Odaki wrote: > A device gets automatically unrealized when being unparented. > > Signed-off-by: Akihiko Odaki > --- > hw/pci/pcie_sriov.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c >

Re: [PATCH v8 07/15] pcie_sriov: Do not manually unrealize

2024-03-12 Thread Michael S. Tsirkin
On Wed, Feb 28, 2024 at 08:33:18PM +0900, Akihiko Odaki wrote: > A device gets automatically unrealized when being unparented. > > Signed-off-by: Akihiko Odaki I was bisecting and when I bisected to this commit I got a build error: ../hw/pci/pcie_sriov.c: In function ‘register_vf’:

Re: [PATCH v2] virtio-blk: iothread-vq-mapping coroutine pool sizing

2024-03-12 Thread Michael S. Tsirkin
: Boaz Ben Shabat > Reported-by: Joe Mario > Signed-off-by: Stefan Hajnoczi Looks reasonable. Reviewed-by: Michael S. Tsirkin if you want me to merge it, let me know pls. > --- > v2: > - State the the tighter bounds reflect the fact that threads may only > proc

Re: [PATCH v2 00/15] hw/southbridge: Extract ICH9 QOM container model

2024-03-12 Thread Michael S. Tsirkin
On Mon, Feb 26, 2024 at 12:13:59PM +0100, Philippe Mathieu-Daudé wrote: > Since v1 [1]: > - Rebased on top of Bernhard patches > - Rename files with 'ich9_' prefix (Bernhard) > > Hi, > > I have a long standing southbridge QOM rework branches. Since > Bernhard is actively working on the PIIX,

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

2024-03-12 Thread Michael S. Tsirkin
On Tue, Mar 12, 2024 at 10:33:51AM -0400, Jonah Palmer wrote: > > > On 3/11/24 11:47 AM, Michael S. Tsirkin wrote: > > On Mon, Mar 11, 2024 at 10:53:25AM -0400, Jonah Palmer wrote: > > > > > > > > > On 3/8/24 2:19 PM, Michael S. Tsirkin wrote: > &

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

2024-03-11 Thread Michael S. Tsirkin
On Mon, Mar 11, 2024 at 10:53:25AM -0400, Jonah Palmer wrote: > > > On 3/8/24 2:19 PM, Michael S. Tsirkin wrote: > > On Fri, Mar 08, 2024 at 12:45:13PM -0500, Jonah Palmer wrote: > > > > > > > > > On 3/8/24 12:36 PM, Eugenio Perez Martin wrote: > &g

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

2024-03-08 Thread Michael S. Tsirkin
On Fri, Mar 08, 2024 at 12:45:13PM -0500, Jonah Palmer wrote: > > > On 3/8/24 12:36 PM, Eugenio Perez Martin wrote: > > On Fri, Mar 8, 2024 at 6: 01 PM Michael S. Tsirkin > > wrote: > > On Mon, Mar 04, 2024 at 02: 46: 06PM -0500, Jonah Palmer > > wrote: > &g

Re: [PATCH v1 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA

2024-03-08 Thread Michael S. Tsirkin
On Mon, Mar 04, 2024 at 02:46:06PM -0500, Jonah Palmer wrote: > Prevent ioeventfd from being enabled/disabled when a virtio-pci > device has negotiated the VIRTIO_F_NOTIFICATION_DATA transport > feature. > > Due to ioeventfd not being able to carry the extra data associated with > this feature,

Re: [PATCH v1 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support

2024-03-05 Thread Michael S. Tsirkin
On Wed, Mar 06, 2024 at 08:07:31AM +0100, Eugenio Perez Martin wrote: > On Wed, Mar 6, 2024 at 6:34 AM Jason Wang wrote: > > > > On Tue, Mar 5, 2024 at 3:46 AM Jonah Palmer wrote: > > > > > > The goal of these patches are to add support to a variety of virtio and > > > vhost devices for the

Re: [PATCH v5 02/11] pcie_sriov: Validate NumVFs

2024-02-18 Thread Michael S. Tsirkin
On Sun, Feb 18, 2024 at 01:56:07PM +0900, Akihiko Odaki wrote: > The guest may write NumVFs greater than TotalVFs and that can lead > to buffer overflow in VF implementations. > > Cc: qemu-sta...@nongnu.org > Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization > (SR/IOV)")

Re: [PATCH v5 05/11] vfio: Avoid inspecting option QDict for rombar

2024-02-18 Thread Michael S. Tsirkin
On Sun, Feb 18, 2024 at 01:56:10PM +0900, Akihiko Odaki wrote: > Use pci_rom_bar_explicitly_enabled() to determine if rombar is explicitly > enabled. > > Signed-off-by: Akihiko Odaki I see little point in all this reworks: QDict lookups are robust. But if Alex wants this change, I won't oppose

Re: [PATCH v4 9/9] hw/nvme: Refer to dev->exp.sriov_pf.num_vfs

2024-02-14 Thread Michael S. Tsirkin
On Thu, Feb 15, 2024 at 01:07:29AM +0900, Akihiko Odaki wrote: > On 2024/02/15 0:46, Michael S. Tsirkin wrote: > > On Wed, Feb 14, 2024 at 11:09:50PM +0900, Akihiko Odaki wrote: > > > On 2024/02/14 16:07, Michael S. Tsirkin wrote: > > > > On Wed, Feb 14, 2024 at 0

Re: [PATCH v4 5/9] pcie_sriov: Validate NumVFs

2024-02-14 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 06:53:43PM +0300, Michael Tokarev wrote: > Nope, I don't remember how to request a CVE ;) https://www.qemu.org/contribute/security-process/

Re: [PATCH v4 5/9] pcie_sriov: Validate NumVFs

2024-02-14 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 11:49:52PM +0900, Akihiko Odaki wrote: > On 2024/02/14 15:52, Michael S. Tsirkin wrote: > > On Wed, Feb 14, 2024 at 02:13:43PM +0900, Akihiko Odaki wrote: > > > The guest may write NumVFs greater than TotalVFs and that can lead > > > to buffer ove

Re: [PATCH v4 8/9] pcie_sriov: Do not reset NumVFs after unregistering VFs

2024-02-14 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 11:32:11PM +0900, Akihiko Odaki wrote: > On 2024/02/14 15:53, Michael S. Tsirkin wrote: > > On Wed, Feb 14, 2024 at 02:13:46PM +0900, Akihiko Odaki wrote: > > > I couldn't find such a behavior specified. > > > > Is it fixing a bug or

Re: [PATCH v4 9/9] hw/nvme: Refer to dev->exp.sriov_pf.num_vfs

2024-02-14 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 11:09:50PM +0900, Akihiko Odaki wrote: > On 2024/02/14 16:07, Michael S. Tsirkin wrote: > > On Wed, Feb 14, 2024 at 02:13:47PM +0900, Akihiko Odaki wrote: > > > NumVFs may not equal to the current effective number of VFs because VF > > > Enabl

[PULL 28/60] hw/block/fdc-isa: Implement relocation and enabling/disabling for TYPE_ISA_FDC

2024-02-14 Thread Michael S. Tsirkin
: <20240114123911.4877-8-shen...@gmail.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/block/fdc.h | 3 +++ hw/block/fdc-isa.c | 14 ++ 2 files changed, 17 insertions(+) diff --git a/include/hw/block/fdc.h b/include/hw/block/fdc.h index 3524

[PULL 22/60] hw/block/fdc-isa: Move portio_list from FDCtrl to FDCtrlISABus

2024-02-14 Thread Michael S. Tsirkin
From: Bernhard Beschow FDCtrl::portio_list isn't used inside FDCtrl context but only inside FDCtrlISABus context, so move it there. Signed-off-by: Bernhard Beschow Reviewed-by: BALATON Zoltan Message-Id: <20240114123911.4877-2-shen...@gmail.com> Reviewed-by: Michael S. Tsirkin Sign

[PULL 23/60] hw/block/fdc-sysbus: Move iomem from FDCtrl to FDCtrlSysBus

2024-02-14 Thread Michael S. Tsirkin
From: Bernhard Beschow FDCtrl::iomem isn't used inside FDCtrl context but only inside FDCtrlSysBus context, so move it there. Signed-off-by: Bernhard Beschow Reviewed-by: BALATON Zoltan Message-Id: <20240114123911.4877-3-shen...@gmail.com> Reviewed-by: Michael S. Tsirkin Sign

Re: [PATCH v4 7/9] pcie_sriov: Release VFs failed to realize

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:45PM +0900, Akihiko Odaki wrote: > Release VFs failed to realize just as we do in unregister_vfs(). > > Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization > (SR/IOV)") > Signed-off-by: Akihiko Odaki Is this fixing an old bug or a bug

Re: [PATCH v4 6/9] pcie_sriov: Reuse SR-IOV VF device instances

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:44PM +0900, Akihiko Odaki wrote: > Disable SR-IOV VF devices by reusing code to power down PCI devices > instead of removing them when the guest requests to disable VFs. This > allows to realize devices and report VF realization errors at PF > realization time. > >

Re: [PATCH v4 9/9] hw/nvme: Refer to dev->exp.sriov_pf.num_vfs

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:47PM +0900, Akihiko Odaki wrote: > NumVFs may not equal to the current effective number of VFs because VF > Enable is cleared, NumVFs is set after VF Enable is set, or NumVFs is > greater than TotalVFs. > > Fixes: 11871f53ef8e ("hw/nvme: Add support for the

Re: [PATCH v4 8/9] pcie_sriov: Do not reset NumVFs after unregistering VFs

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:46PM +0900, Akihiko Odaki wrote: > I couldn't find such a behavior specified. Is it fixing a bug or just removing unnecessary code? Is this guest visible at all? > Signed-off-by: Akihiko Odaki > --- > hw/pci/pcie_sriov.c | 1 - > 1 file changed, 1 deletion(-) > >

Re: [PATCH v4 5/9] pcie_sriov: Validate NumVFs

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:43PM +0900, Akihiko Odaki wrote: > The guest may write NumVFs greater than TotalVFs and that can lead > to buffer overflow in VF implementations. > > Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization > (SR/IOV)") > Signed-off-by: Akihiko

Re: [PATCH v4 2/9] hw/pci: Determine if rombar is explicitly enabled

2024-02-13 Thread Michael S. Tsirkin
On Wed, Feb 14, 2024 at 02:13:40PM +0900, Akihiko Odaki wrote: > vfio determines if rombar is explicitly enabled by inspecting QDict. > Inspecting QDict is not nice because QDict is untyped and depends on the > details on the external interface. Add an infrastructure to determine if > rombar is

Re: [PATCH 0/9] hw/ide/ahci: Housekeeping

2024-02-13 Thread Michael S. Tsirkin
On Tue, Feb 13, 2024 at 09:11:51AM +0100, Philippe Mathieu-Daudé wrote: > - Split 'ahci.h' as sysbus / pci > - Inline ahci_get_num_ports() > - Directly use AHCIState::ports instead of SysbusAHCIState::num_ports PC part: Reviewed-by: Michael S. Tsirkin feel free to merge with rest o

Re: [PATCH v3 6/7] pcie_sriov: Reuse SR-IOV VF device instances

2024-02-13 Thread Michael S. Tsirkin
On Mon, Feb 12, 2024 at 07:20:34PM +0900, Akihiko Odaki wrote: > Disable SR-IOV VF devices by reusing code to power down PCI devices > instead of removing them when the guest requests to disable VFs. This > allows to realize devices and report VF realization errors at PF > realization time. > >

Re: [PATCH v3 5/7] pcie_sriov: Validate NumVFs

2024-02-13 Thread Michael S. Tsirkin
On Mon, Feb 12, 2024 at 07:20:33PM +0900, Akihiko Odaki wrote: > The guest may write NumVFs greater than TotalVFs and that can lead > to buffer overflow in VF implementations. > > Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization > (SR/IOV)") > Signed-off-by: Akihiko

Re: [PATCH v3 2/7] hw/pci: Determine if rombar is explicitly enabled

2024-02-13 Thread Michael S. Tsirkin
On Mon, Feb 12, 2024 at 07:20:30PM +0900, Akihiko Odaki wrote: > vfio determines if rombar is explicitly enabled by inspecting QDict. > Inspecting QDict is not nice because QDict is untyped and depends on the > details on the external interface. Add an infrastructure to determine if > rombar is

Re: [PATCH v2 0/5] virtio-blk: iothread-vq-mapping cleanups

2024-02-06 Thread Michael S. Tsirkin
u.git. This series consists of code cleanups that Hanna identified. > > There are no functional changes or bug fixes that need to be backported to the > stable tree here, but it may make sense to backport them in the future to > avoid > conflicts. Reviewed-by: Michael S.

Re: [PATCH] virtio-blk: do not use C99 mixed declarations

2024-02-06 Thread Michael S. Tsirkin
On Tue, Feb 06, 2024 at 09:04:09AM -0500, Stefan Hajnoczi wrote: > QEMU's coding style generally forbids C99 mixed declarations. > > Signed-off-by: Stefan Hajnoczi Acked-by: Michael S. Tsirkin or maybe it's time we moved on? > --- > hw/block/virtio-blk.c | 25 ++-

Re: [PATCH v5 00/11] hw/isa/vt82c686: Implement relocation and toggling of SuperI/O functions

2024-01-14 Thread Michael S. Tsirkin
On Sun, Jan 14, 2024 at 12:52:53PM +, Bernhard Beschow wrote: > > > Am 14. Januar 2024 12:39:00 UTC schrieb Bernhard Beschow : > >This series implements relocation of the SuperI/O functions of the VIA south > > > >bridges which resolves some FIXME's. It is part of my via-apollo-pro-133t > >

Re: [PATCH v9 00/11] virtio: cleanup vhost-user-generic and reduce c + vhost-user-input

2024-01-10 Thread Michael S. Tsirkin
On Wed, Jan 10, 2024 at 10:55:11AM +, Alex Bennée wrote: > Alex Bennée writes: > > > A lot of our vhost-user stubs are large chunks of boilerplate that do > > (mostly) the same thing. This series continues the cleanups by > > splitting the vhost-user-base and vhost-user-generic

Re: [PATCH v3 0/6] migration: check required entries and sections are loaded

2023-12-25 Thread Michael S. Tsirkin
gt; This series has a few preliminary fixes, add new checks that entries are > loaded once and required ones have been loaded, add some tests and > documentation update. > > thanks series: Reviewed-by: Michael S. Tsirkin merge through migration tree. > v3: > - rebased, drop RFC

[PULL 14/15] vhost-user: fix the reconnect error

2023-12-01 Thread Michael S. Tsirkin
l Norwitz Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/block/vhost-user-blk.c | 8 +++- hw/scsi/vhost-user-scsi.c | 3 ++- hw/virtio/vhost-user-gpio.c | 3 ++- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/block/vhost-user-blk.c b/hw/block/v

Re: [PATCH v8 0/7] virtio: cleanup vhost-user-generic and reduce c

2023-11-07 Thread Michael S. Tsirkin
On Tue, Nov 07, 2023 at 06:07:45PM +, Alex Bennée wrote: > A lot of our vhost-user stubs are large chunks of boilerplate that do > (mostly) the same thing. This series continues the cleanups by > splitting the vhost-user-base and vhost-user-generic implementations. > After adding a new vq_size

Re: [PATCH v7 7/7] docs/system: add a basic enumeration of vhost-user devices

2023-11-07 Thread Michael S. Tsirkin
On Tue, Nov 07, 2023 at 06:02:46PM +, Alex Bennée wrote: > Make it clear the vhost-user-device is intended for expert use only. > > Signed-off-by: Alex Bennée > Message-Id: <20231009095937.195728-7-alex.ben...@linaro.org> > > --- > v5 > - split vhost-user-device out of the table > -

Re: [PATCH v6 0/6] virtio: cleanup vhost-user-generic and reduce c

2023-11-07 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:09PM +, Alex Bennée wrote: > A lot of our vhost-user stubs are large chunks of boilerplate that do > (mostly) the same thing. This series continues the cleanups by > splitting the vhost-user-base and vhost-user-generic implementations. > After adding a new vq_size

Re: [PATCH v6 3/6] hw/virtio: derive vhost-user-gpio from vhost-user-base

2023-11-07 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:12PM +, Alex Bennée wrote: > -case CHR_EVENT_CLOSED: > -/* defer close until later to avoid circular close */ > -vhost_user_async_close(dev, >chardev, >vhost_dev, > - vu_gpio_disconnect, vu_gpio_event); I don't

Re: [PATCH v6 0/6] virtio: cleanup vhost-user-generic and reduce c

2023-11-07 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:09PM +, Alex Bennée wrote: > A lot of our vhost-user stubs are large chunks of boilerplate that do > (mostly) the same thing. This series continues the cleanups by > splitting the vhost-user-base and vhost-user-generic implementations. > After adding a new vq_size

Re: [PATCH v6 0/6] virtio: cleanup vhost-user-generic and reduce c

2023-11-07 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:09PM +, Alex Bennée wrote: > A lot of our vhost-user stubs are large chunks of boilerplate that do > (mostly) the same thing. This series continues the cleanups by > splitting the vhost-user-base and vhost-user-generic implementations. > After adding a new vq_size

Re: [PATCH v6 1/6] virtio: split into vhost-user-base and vhost-user-device

2023-11-07 Thread Michael S. Tsirkin
On Tue, Nov 07, 2023 at 08:03:16AM +, Alex Bennée wrote: > "Michael S. Tsirkin" writes: > > > On Mon, Nov 06, 2023 at 07:15:10PM +, Alex Bennée wrote: > >> Lets keep a cleaner split between the base class and the derived > >> vhost-user-device

Re: [PATCH v6 1/6] virtio: split into vhost-user-base and vhost-user-device

2023-11-06 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:10PM +, Alex Bennée wrote: > Lets keep a cleaner split between the base class and the derived > vhost-user-device which we can use for generic vhost-user stubs. This > includes an update to introduce the vq_size property so the number of > entries in a virtq can

Re: [PATCH v6 1/6] virtio: split into vhost-user-base and vhost-user-device

2023-11-06 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 07:15:10PM +, Alex Bennée wrote: > Lets keep a cleaner split between the base class and the derived > vhost-user-device which we can use for generic vhost-user stubs. This > includes an update to introduce the vq_size property so the number of > entries in a virtq can

Re: [PATCH v5 3/6] hw/virtio: derive vhost-user-gpio from vhost-user-base

2023-11-06 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 05:30:39PM +, Alex Bennée wrote: > "Michael S. Tsirkin" writes: > > > On Thu, Oct 19, 2023 at 10:56:07AM +0100, Alex Bennée wrote: > >> Now the new base class supports config handling we can take advantage > >> and make vh

Re: [PATCH v5 1/6] virtio: split into vhost-user-base and vhost-user-device

2023-11-06 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 05:40:10PM +, Alex Bennée wrote: > "Michael S. Tsirkin" writes: > > > On Thu, Oct 19, 2023 at 10:56:05AM +0100, Alex Bennée wrote: > >> Lets keep a cleaner split between the base class and the derived > >> vhost-user-device

Re: [PATCH v3 0/6] migration: check required entries and sections are loaded

2023-11-06 Thread Michael S. Tsirkin
On Mon, Nov 06, 2023 at 03:35:54PM +0400, marcandre.lur...@redhat.com wrote: > From: Marc-André Lureau > > Hi, > > Surprisingly, the migration code doesn't check that required migration entries > and subsections are loaded. Either optional or required sections are both > ignored when missing.

Re: [PATCH v5 1/6] virtio: split into vhost-user-base and vhost-user-device

2023-11-06 Thread Michael S. Tsirkin
On Thu, Oct 19, 2023 at 10:56:05AM +0100, Alex Bennée wrote: > Lets keep a cleaner split between the base class and the derived > vhost-user-device which we can use for generic vhost-user stubs. This > includes an update to introduce the vq_size property so the number of > entries in a virtq can

Re: [PATCH v5 3/6] hw/virtio: derive vhost-user-gpio from vhost-user-base

2023-11-06 Thread Michael S. Tsirkin
On Thu, Oct 19, 2023 at 10:56:07AM +0100, Alex Bennée wrote: > Now the new base class supports config handling we can take advantage > and make vhost-user-gpio a much simpler boilerplate wrapper. Also as > this doesn't require any target specific hacks we only need to build > the stubs once. > >

Re: [PATCH v5 0/6] virtio: cleanup vhost-user-generic and reduce c

2023-10-24 Thread Michael S. Tsirkin
On Tue, Oct 24, 2023 at 06:14:36PM +0100, Alex Bennée wrote: > > Alex Bennée writes: > > > A lot of our vhost-user stubs are large chunks of boilerplate that do > > (mostly) the same thing. This series continues the cleanups by > > splitting the vhost-user-base and vhost-user-generic

[PULL v3 55/62] vhost-user: fix lost reconnect

2023-10-22 Thread Michael S. Tsirkin
d. Fixes: 71e076a07d ("hw/virtio: generalise CHR_EVENT_CLOSED handling") Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-6-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost-user.h

[PULL v3 52/62] vhost: move and rename the conn retry times

2023-10-22 Thread Michael S. Tsirkin
From: Li Feng Multiple devices need this macro, move it to a common header. Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-3-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost.h

Re: [PATCH v5 5/6] hw/virtio: add vhost-user-snd and virtio-snd-pci devices

2023-10-20 Thread Michael S. Tsirkin
On Fri, Oct 20, 2023 at 09:16:03AM +0100, Alex Bennée wrote: > > Viresh Kumar writes: > > > On 19-10-23, 10:56, Alex Bennée wrote: > >> From: Manos Pitsidianakis > >> > >> Tested with rust-vmm vhost-user-sound daemon: > >> > >> RUST_LOG=trace cargo run --bin vhost-user-sound -- --socket

[PULL v2 71/78] vhost-user: fix lost reconnect

2023-10-19 Thread Michael S. Tsirkin
d. Fixes: 71e076a07d ("hw/virtio: generalise CHR_EVENT_CLOSED handling") Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-6-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost-user.h

[PULL v2 68/78] vhost: move and rename the conn retry times

2023-10-19 Thread Michael S. Tsirkin
From: Li Feng Multiple devices need this macro, move it to a common header. Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-3-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost.h

[PULL 76/83] vhost-user: fix lost reconnect

2023-10-18 Thread Michael S. Tsirkin
d. Fixes: 71e076a07d ("hw/virtio: generalise CHR_EVENT_CLOSED handling") Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-6-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost-user.h

[PULL 73/83] vhost: move and rename the conn retry times

2023-10-18 Thread Michael S. Tsirkin
From: Li Feng Multiple devices need this macro, move it to a common header. Signed-off-by: Li Feng Reviewed-by: Raphael Norwitz Message-Id: <20231009044735.941655-3-fen...@smartx.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/vhost.h

Re: [PATCH 4/4] qapi: introduce CONFIG_READ event

2023-10-18 Thread Michael S. Tsirkin
On Wed, Oct 18, 2023 at 12:36:10PM +0200, Markus Armbruster wrote: > > x- seems safer for management tool that doesn't know about "unstable" > > properties.. > > Easy, traditional, and unreliable :) > > But on the other hand, changing from x- to no-prefix is already done when > > the feature

Re: [PATCH v8 0/5] Implement reconnect for vhost-user-scsi

2023-10-18 Thread Michael S. Tsirkin
Queued. Thanks! On Wed, Oct 18, 2023 at 04:26:10PM +0800, Li Feng wrote: > Hello Guys, > > Ping… > > These patches have been waiting for a long time. Can they be merged? > > > Best Regards, > > li > > > On 9 Oct 2023, at 12:46 PM, Li Feng wrote: > > Changes for v8: > -

Re: [PATCH 0/7] hw: Few more QOM/QDev cleanups

2023-10-17 Thread Michael S. Tsirkin
On Tue, Oct 17, 2023 at 04:01:43PM +0200, Philippe Mathieu-Daudé wrote: > - Remove a pointless check, > - Use QOM cast macros, > - Declare QDev links statically using DEFINE_PROP_LINK() virtio things Reviewed-by: Michael S. Tsirkin > Philippe Mathieu-Daudé (7): > hw/vir

Re: vhost-user question about VHOST_USER_F_PROTOCOL_FEATURES

2023-10-12 Thread Michael S. Tsirkin
On Thu, Oct 12, 2023 at 09:20:28PM +0300, Vladimir Sementsov-Ogievskiy wrote: > Hi all! > > We now have a problem in downstream: > > We have a vhost-user server, which doesn't support > VHOST_USER_SET_VRING_ENABLE. As I understand, vhost-user specification allows > it. So the server behaves as

Re: [PATCH v6 1/5] vhost-user-common: send get_inflight_fd once

2023-10-08 Thread Michael S. Tsirkin
On Sun, Oct 08, 2023 at 04:49:05PM +0800, Li Feng wrote: > On Fri, Sep 29, 2023 at 8:55 AM Raphael Norwitz > wrote: > > > > > > > > > On Sep 22, 2023, at 7:46 AM, Li Feng wrote: > > > > > > Currently the get_inflight_fd will be sent every time the device is > > > started, and > > > the backend

Re: [PATCH v6 0/5] Implement reconnect for vhost-user-scsi

2023-10-08 Thread Michael S. Tsirkin
On Fri, Sep 22, 2023 at 07:46:10PM +0800, Li Feng wrote: > Changes for v6: > - [PATCH] vhost-user: fix lost reconnect > - Fix missing assign event_cb. Pls don't make vN+1 a reply to vN - start a new thread with each version please. > Changes for v5: > - No logic has been changed, just move

Re: [PATCH v2 0/2] virtio-blk: add iothread-vq-mapping parameter

2023-10-03 Thread Michael S. Tsirkin
JSON --device syntax is required for the iothread-vq-mapping > parameter because it's non-scalar. > > Based-on: 20230912231037.826804-1-stefa...@redhat.com ("[PATCH v3 0/5] > block-backend: process I/O in the current AioContext") Acked-by: Michael S. Tsirkin More of a bl

Re: [PATCH v3 2/2] vhost: Add Error parameter to vhost_scsi_common_start()

2023-10-01 Thread Michael S. Tsirkin
On Tue, Sep 12, 2023 at 04:32:59PM +0800, Li Feng wrote: > Please mention in the commit message that error messages improve, and > silent errors are now reported. > > Ack. Still waiting for v4 with the updated commit log. -- MST

Re: [PATCH v2 17/22] util/vhost-user-server: Clean up local variable shadowing

2023-09-22 Thread Michael S. Tsirkin
> Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin feel free to merge. > --- > util/vhost-user-server.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c > index cd17fb53

Re: [PATCH 0/4] virtio-blk: prepare for the multi-queue block layer

2023-09-15 Thread Michael S. Tsirkin
om ("[PATCH v3 0/5] > block-backend: process I/O in the current AioContext") virtio bits: Reviewed-by: Michael S. Tsirkin feel free to merge > Stefan Hajnoczi (4): > block/file-posix: set up Linux AIO and io_uring in the current thread > virtio-blk: add lock to protect

Re: [PATCH v3 0/4] virtio-blk: use blk_io_plug_call() instead of notification BH

2023-09-13 Thread Michael S. Tsirkin
a multi-queue > block layer configuration) compared to no completion batching. iodepth=1 > decreases by ~1% but this could be noise. Benchmark details are available > here: > https://gitlab.com/stefanha/virt-playbooks/-/tree/blk_io_plug-irqfd virtio things: Reviewed-by: Michael S. Tsirkin

Re: [Qemu-devel] [PATCH] ahci: enable pci bus master MemoryRegion before loading ahci engines

2023-09-05 Thread Michael S. Tsirkin
On Tue, Sep 10, 2019 at 10:08:20AM -0400, John Snow wrote: > > > On 9/10/19 9:58 AM, Michael S. Tsirkin wrote: > > On Tue, Sep 10, 2019 at 09:50:41AM -0400, John Snow wrote: > >> > >> > >> On 9/10/19 3:04 AM, Michael S. Tsirkin wrote: > >>&

Re: [PATCH v2 2/4] vhost-user-common: send get_inflight_fd once

2023-07-28 Thread Michael S. Tsirkin
On Tue, Jul 25, 2023 at 06:42:45PM +0800, Li Feng wrote: > Get_inflight_fd is sent only once. When reconnecting to the backend, > qemu sent set_inflight_fd to the backend. I don't understand what you are trying to say here. Should be: Currently ABCD. This is wrong/unnecessary because EFG. This

Re: [PATCH] vhost-user-scsi: support reconnect to backend

2023-07-24 Thread Michael S. Tsirkin
On Mon, Jul 24, 2023 at 05:21:37PM +, Raphael Norwitz wrote: > Very excited to see this. High level looks good modulo a few small things. > > My major concern is around existing vhost-user-scsi backends which don’t > support VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD. IMO we should hide the >

Re: [PATCH] hw/pci: Warn when ARI/SR-IOV device has non-zero Function number

2023-07-12 Thread Michael S. Tsirkin
On Wed, Jul 12, 2023 at 08:50:32PM +0900, Akihiko Odaki wrote: > On 2023/07/12 20:46, Michael S. Tsirkin wrote: > > On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote: > > > Current SR/IOV implementations assume that hardcoded Function numbers > >

Re: [PATCH] hw/pci: Warn when ARI/SR-IOV device has non-zero Function number

2023-07-12 Thread Michael S. Tsirkin
On Wed, Jul 12, 2023 at 08:27:32PM +0900, Akihiko Odaki wrote: > Current SR/IOV implementations assume that hardcoded Function numbers > are always available and will not conflict. It is somewhat non-trivial > to make the Function numbers to use controllable to avoid Function > number conflicts so

Re: [PATCH 4/4] pci: Compare function number and ARI next function number

2023-07-11 Thread Michael S. Tsirkin
On Tue, Jul 11, 2023 at 12:40:47PM +0530, Ani Sinha wrote: > > > > On 01-Jul-2023, at 12:31 PM, Akihiko Odaki wrote: > > > > The function number must be lower than the next function number > > advertised with ARI. > > > > Signed-off-by: Akihiko Odaki > > --- > > hw/pci/pci.c | 15

[PULL 56/66] pcie: Use common ARI next function number

2023-07-10 Thread Michael S. Tsirkin
From: Akihiko Odaki Currently the only implementers of ARI is SR-IOV devices, and they behave similar. Share the ARI next function number. Signed-off-by: Akihiko Odaki Reviewed-by: Ani Sinha Message-Id: <20230710153838.33917-2-akihiko.od...@daynix.com> Reviewed-by: Michael S. Tsirkin

Re: [PATCH v3 07/20] virtio: add vhost-user-base and a generic vhost-user-device

2023-07-10 Thread Michael S. Tsirkin
ie the refactoring in with new functionality. I applied but blocked creating these for now with: Subject: [PATCH] vhost-user-device: block creating instances Message-Id: block this until we are ready to commit to this command line. Signed-off-by: Michael S. Tsirkin --- hw/virtio/vhost-user-device.c | 1

Re: [PATCH v3 10/20] hw/virtio: add config support to vhost-user-device

2023-07-10 Thread Michael S. Tsirkin
On Mon, Jul 10, 2023 at 04:35:12PM +0100, Alex Bennée wrote: > To use the generic device the user will need to provide the config > region size via the command line. We also add a notifier so the guest > can be pinged if the remote daemon updates the config. > > With these changes: > > -device

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Michael S. Tsirkin
On Mon, Jul 10, 2023 at 03:44:04PM +0530, Ani Sinha wrote: > > > > On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin wrote: > > > > On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote: > >> > >> > >>> On 10-Jul-2023, at 2:46 PM, Michae

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Michael S. Tsirkin
On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote: > > > > On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote: > > > > On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote: > >> > >> > >>> On 05-Jul-2023, at 7:54 AM,

Re: [PATCH v5 2/2] pcie: Specify 0 for ARI next function numbers

2023-07-10 Thread Michael S. Tsirkin
On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote: > > > > On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote: > > > > The current implementers of ARI are all SR-IOV devices. The ARI next > > function number field is undefined for VF according to PCI Express Base > > Specification

Re: [PATCH v3 0/2] pcie: Fix ARI next function numbers

2023-07-02 Thread Michael S. Tsirkin
On Mon, Jul 03, 2023 at 12:17:16PM +0900, Akihiko Odaki wrote: > On 2023/07/02 21:43, Michael S. Tsirkin wrote: > > On Sun, Jul 02, 2023 at 09:02:25PM +0900, Akihiko Odaki wrote: > > > The ARI next function number field is undefined for VF. The PF should > > >

Re: [PATCH v2 1/4] docs: Fix next function numbers in SR/IOV documentation

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 08:19:43PM +0900, Akihiko Odaki wrote: > On 2023/07/02 19:40, Michael S. Tsirkin wrote: > > On Sun, Jul 02, 2023 at 06:46:25PM +0900, Akihiko Odaki wrote: > > > The ARI next function number field is undefined for VF so the PF should > > >

Re: [PATCH v3 0/2] pcie: Fix ARI next function numbers

2023-07-02 Thread Michael S. Tsirkin
t;[PATCH 0/4] pci: Compare function number and ARI next function number") Thanks! How was this patch tested? > V2 -> V3: > Moved the logic to PCI common infrastucture (Michael S. Tsirkin) > > V1 -> V2: > Fixed migration. (Michael S. Tsirkin) > Added a caveat comment

Re: [PATCH v2 1/4] docs: Fix next function numbers in SR/IOV documentation

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 06:46:25PM +0900, Akihiko Odaki wrote: > The ARI next function number field is undefined for VF so the PF should > end the linked list formed with the field by specifying 0. > > This also changes the value of the field for VF; it seems to imply the > value has some meaning

Re: [PATCH 3/3] igb: Fix ARI next function numbers

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 06:49:50PM +0900, Akihiko Odaki wrote: > On 2023/07/02 18:00, Michael S. Tsirkin wrote: > > On Sun, Jul 02, 2023 at 05:33:56PM +0900, Akihiko Odaki wrote: > > > The ARI next function number field is undefined for VF so the PF should > > >

Re: [PATCH v2 3/4] igb: Fix ARI next function numbers

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 06:46:27PM +0900, Akihiko Odaki wrote: > The ARI next function number field is undefined for VF so the PF should > end the linked list formed with the field by specifying 0. > > Fixes: 3a977deebe ("Intrdocue igb device emulation") > Signed-off-by: Akihiko Odaki > --- >

Re: [PATCH 3/3] igb: Fix ARI next function numbers

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 05:33:56PM +0900, Akihiko Odaki wrote: > The ARI next function number field is undefined for VF so the PF should > end the linked list formed with the field by specifying 0. > > Fixes: 3a977deebe ("Intrdocue igb device emulation") > Signed-off-by: Akihiko Odaki I would

Re: [PATCH 4/4] pci: Compare function number and ARI next function number

2023-07-02 Thread Michael S. Tsirkin
On Sun, Jul 02, 2023 at 04:55:48AM -0400, Michael S. Tsirkin wrote: > On Sun, Jul 02, 2023 at 05:46:38PM +0900, Akihiko Odaki wrote: > > On 2023/07/02 13:58, Michael S. Tsirkin wrote: > > > On Sat, Jul 01, 2023 at 04:01:22PM +0900, Akihiko Odaki wrote: > > > > The

  1   2   3   4   5   6   7   8   >