Re: [PATCH V4 1/3] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN

2021-02-24 Thread Christian Borntraeger
On 23.02.21 07:19, Jason Wang wrote: > We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a > lot of confusion. E.g it may break various default configs which want > virtio devices. > > So this patch fixes this by hiding the prompot and documenting the > dependency. While at

Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

2020-10-20 Thread Christian Borntraeger
On 17.10.20 20:09, Alexander Graf wrote: > Hi Jason, > > On 17.10.20 15:24, Jason A. Donenfeld wrote: >> >> After discussing this offline with Jann a bit, I have a few general >> comments on the design of this. >> >> First, the UUID communicated by the hypervisor should be consumed by >> the

Re: [PATCH v12 0/2] s390: virtio: let arch validate VIRTIO features

2020-09-22 Thread Christian Borntraeger
Michael, are you going to pick this series? On 10.09.20 10:53, Pierre Morel wrote: > Hi all, > > The goal of the series is to give a chance to the architecture > to validate VIRTIO device features. > > I changed VIRTIO_F_IOMMU_PLATFORM to VIRTIO_F_ACCESS_PLATFORM > I forgot in

Re: [PATCH v12 2/2] s390: virtio: PV needs VIRTIO I/O device protection

2020-09-10 Thread Christian Borntraeger
s > the case. > > Signed-off-by: Pierre Morel > Reviewed-by: Cornelia Huck > Reviewed-by: Halil Pasic Acked-by: Christian Borntraeger Michael, I am fine if this patch goes via the virtio tree. > --- > arch/s390/Kconfig | 1 + > arch/s390/mm/init.c | 11 +

Re: [PATCH v12 1/2] virtio: let arch advertise guest's memory access restrictions

2020-09-10 Thread Christian Borntraeger
Signed-off-by: Pierre Morel > Reviewed-by: Cornelia Huck > Reviewed-by: Halil Pasic Acked-by: Christian Borntraeger > --- > drivers/virtio/Kconfig| 6 ++ > drivers/virtio/virtio.c | 15 +++ > include/linux/virtio_config.h | 10 ++ >

Re: [PATCH v7 2/2] s390: virtio: PV needs VIRTIO I/O device protection

2020-07-16 Thread Christian Borntraeger
ccess >>>> attempt. >>>> >>>> Signed-off-by: Pierre Morel >>>> Reviewed-by: Cornelia Huck >>>> Acked-by: Halil Pasic >>>> Acked-by: Christian Borntraeger >>>> --- >>>> arch/s390/mm/init.c | 28 ++

Re: [PATCH v6 2/2] s390: virtio: PV needs VIRTIO I/O device protection

2020-07-14 Thread Christian Borntraeger
not the case, preventing a host error on access > attempt. > > Signed-off-by: Pierre Morel > Reviewed-by: Cornelia Huck > Acked-by: Halil Pasic We will probably move this (and other related code) into a new file, but we can do that later. As for now: Acked-by: Christian Borntraeger &

Re: [PATCH v4 2/2] s390: virtio: PV needs VIRTIO I/O device protection

2020-07-07 Thread Christian Borntraeger
On 07.07.20 10:44, Pierre Morel wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. > > Signed-off-by: Pierre Morel > --- > arch/s390/kernel/uv.c | 25

Re: [PATCH v4 1/2] virtio: let arch validate VIRTIO features

2020-07-07 Thread Christian Borntraeger
+/* >> + * arch_needs_virtio_iommu_platform - provide arch specific hook when >> finalizing > > s/arch_needs_virtio_iommu_platform/arch_validate_virtio_features/ With the things from Conny fixed, Acked-by: Christian Borntraeger ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 1/1] s390: virtio: let arch accept devices without IOMMU feature

2020-06-16 Thread Christian Borntraeger
vices > without VIRTIO_F_IOMMU_PLATFORM. > > Signed-off-by: Pierre Morel Acked-by: Christian Borntraeger Shouldnt we maybe add a pr_warn if that happens to help the admins to understand what is going on? > --- > arch/s390/mm/init.c | 6 ++ > drivers/virtio/virtio

Re: [PATCH] vhost: do not enable VHOST_MENU by default

2020-04-14 Thread Christian Borntraeger
ST_MENU is > not set". So this patch tries to enable CONFIG_VHOST explicitly in > defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK. > > Cc: Thomas Bogendoerfer > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Heiko Carstens

Re: [PATCH v3 0/8] vhost: Reset batched descriptors on SET_VRING_BASE call

2020-04-01 Thread Christian Borntraeger
>> Would it be possible to investigate when qemu launches the offending ioctls? > > During guest reboot. This is obvious, no? > For example during reboot we do re-setup the virt queues: #1 0x010f3e7a in vhost_kernel_set_vring_base (dev=0x21f5f30, ring=0x3ff84d74e88) at

Re: [PATCH V9 1/9] vhost: refine vhost and vringh kconfig

2020-04-01 Thread Christian Borntraeger
On 01.04.20 17:57, Michael S. Tsirkin wrote: > On Wed, Apr 01, 2020 at 10:50:50PM +0800, Jason Wang wrote: >> >> On 2020/4/1 下午10:27, Michael S. Tsirkin wrote: >>> On Wed, Apr 01, 2020 at 10:13:29PM +0800, Jason Wang wrote: >>>> On 2020/4/1 下午9:02, Christian

Re: [PATCH v3 0/8] vhost: Reset batched descriptors on SET_VRING_BASE call

2020-04-01 Thread Christian Borntraeger
On 01.04.20 20:40, Eugenio Perez Martin wrote: > On Wed, Apr 1, 2020 at 9:19 AM Christian Borntraeger > wrote: >> >> On 31.03.20 21:27, Eugenio Pérez wrote: >>> Vhost did not reset properly the batched descriptors on SET_VRING_BASE >>> event. Because of th

Re: [PATCH V9 1/9] vhost: refine vhost and vringh kconfig

2020-04-01 Thread Christian Borntraeger
On 01.04.20 14:56, Christian Borntraeger wrote: > > On 01.04.20 14:50, Jason Wang wrote: >> >> On 2020/4/1 下午7:21, Christian Borntraeger wrote: >>> On 26.03.20 15:01, Jason Wang wrote: >>>> Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vho

Re: [PATCH V9 1/9] vhost: refine vhost and vringh kconfig

2020-04-01 Thread Christian Borntraeger
On 01.04.20 14:50, Jason Wang wrote: > > On 2020/4/1 下午7:21, Christian Borntraeger wrote: >> On 26.03.20 15:01, Jason Wang wrote: >>> Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is >>> not necessarily for VM since it's a generic userspac

Re: [PATCH V9 1/9] vhost: refine vhost and vringh kconfig

2020-04-01 Thread Christian Borntraeger
On 26.03.20 15:01, Jason Wang wrote: > Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is > not necessarily for VM since it's a generic userspace and kernel > communication protocol. Such dependency may prevent archs without > virtualization support from using vhost. > > To

Re: [PATCH v3 0/8] vhost: Reset batched descriptors on SET_VRING_BASE call

2020-04-01 Thread Christian Borntraeger
On 31.03.20 21:27, Eugenio Pérez wrote: > Vhost did not reset properly the batched descriptors on SET_VRING_BASE > event. Because of that, is possible to return an invalid descriptor to > the guest. > > This series ammend this, resetting them every time backend changes, and > creates a test to

Re: [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call

2020-03-30 Thread Christian Borntraeger
On 30.03.20 09:18, Eugenio Perez Martin wrote: > On Mon, Mar 30, 2020 at 9:14 AM Christian Borntraeger > wrote: >> >> >> On 29.03.20 13:33, Eugenio Pérez wrote: >>> Vhost did not reset properly the batched descriptors on SET_VRING_BASE >>> eve

Re: [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call

2020-03-30 Thread Christian Borntraeger
On 29.03.20 13:33, Eugenio Pérez wrote: > Vhost did not reset properly the batched descriptors on SET_VRING_BASE event. > Because of that, is possible to return an invalid descriptor to the guest. I guess this could explain my problems that I have seen during reset? > > This series ammend

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-03-27 Thread Christian Borntraeger
On 27.03.20 12:08, Eugenio Pérez wrote: > Hi Christian. > > Sorry for the late response. Could we try this one over > eccb852f1fe6bede630e2e4f1a121a81e34354ab, and see if you still > can reproduce the bug? To much time has passed and too many things have changed on that system. I have trouble

Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h

2020-02-20 Thread Christian Borntraeger
On 20.02.20 17:31, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote: >> >From a users perspective it makes absolutely perfect sense to use the >> bounce buffers when they are NEEDED. >> Forcing the user to specify iommu_p

Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h

2020-02-20 Thread Christian Borntraeger
On 20.02.20 17:11, Christoph Hellwig wrote: > On Thu, Feb 20, 2020 at 05:06:05PM +0100, Halil Pasic wrote: >> Currently force_dma_unencrypted() is only used by the direct >> implementation of the DMA API, and thus resides in dma-direct.h. But >> there is nothing dma-direct specific about it: if

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-14 Thread Christian Borntraeger
On 14.02.20 13:26, Eugenio Pérez wrote: > On Fri, 2020-02-14 at 13:22 +0100, Christian Borntraeger wrote: >> >> On 14.02.20 13:17, Eugenio Pérez wrote: >>> Can you try the inlined patch over 52c36ce7f334 ("vhost: use batched >>> version by default")? M

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-14 Thread Christian Borntraeger
On 14.02.20 13:17, Eugenio Pérez wrote: > Can you try the inlined patch over 52c36ce7f334 ("vhost: use batched version > by default")? My intention is to check if > "strange VHOST_SET_VRING_BASE" line appears. In previous tests, it appears > very fast, but maybe it takes some time for > it to

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
repro On 14.02.20 08:43, Christian Borntraeger wrote: > > > On 14.02.20 08:40, Eugenio Perez Martin wrote: >> Hi. >> >> Were the vhost and vhost_net modules loaded with dyndbg='+plt'? I miss >> all the others regular debug traces on that one. > > I

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
plt' > control but apparently it did not work...me hates dynamic debug. > > Thanks! > > On Fri, Feb 14, 2020 at 8:34 AM Christian Borntraeger > wrote: >> >> I did >> ping -c 20 -f ... ; reboot >> twice >> >> The ping afte

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
I did ping -c 20 -f ... ; reboot twice The ping after the first reboot showed ...E this was on the host console [ 55.951885] CPU: 34 PID: 1908 Comm: CPU 0/KVM Not tainted 5.5.0+ #21 [ 55.951891] Hardware name: IBM 3906 M04 704 (LPAR) [ 55.951892] Call Trace: [ 55.951902]

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
On 13.02.20 17:29, Eugenio Pérez wrote: > Can we try with this traces? Does not apply on eccb852f1fe6bede630e2e4f1a121a81e34354ab, can you double check? > > From b793b4106085ab1970bdedb340e49f37843ed585 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Eugenio=20P=C3=A9rez?= > Date: Thu, 13 Feb

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
On 13.02.20 11:47, Eugenio Pérez wrote: > > Can we try tracing last_avail_idx with the attached patch? Can you enable > also line and thread id (dyndbg='+plt')? [ 326.584446] [2127] 1648: VHOST_SET_VRING_BASE [vq=36fdfcb7][vq->last_avail_idx=0][vq->avail_idx=0] [ 326.584457]

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-13 Thread Christian Borntraeger
On 12.02.20 17:34, Eugenio Pérez wrote: > On Tue, 2020-02-11 at 14:13 +0100, Christian Borntraeger wrote: >> >> On 11.02.20 14:04, Eugenio Pérez wrote: >>> On Mon, 2020-02-10 at 12:01 +0100, Christian Borntraeger wrote: >>>> On 10.02.20 10:47, Eugenio Pe

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-11 Thread Christian Borntraeger
On 11.02.20 14:04, Eugenio Pérez wrote: > On Mon, 2020-02-10 at 12:01 +0100, Christian Borntraeger wrote: >> >> On 10.02.20 10:47, Eugenio Perez Martin wrote: >>> Hi Christian. >>> >>> I'm not able to reproduce the failure with >>> eccb852f1fe

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-11 Thread Christian Borntraeger
On 11.02.20 10:56, Christian Borntraeger wrote: > > > On 11.02.20 10:33, Eugenio Pérez wrote: >> On Mon, 2020-02-10 at 12:01 +0100, Christian Borntraeger wrote: >>> >>> On 10.02.20 10:47, Eugenio Perez Martin wrote: >>>> Hi Christian. &g

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-11 Thread Christian Borntraeger
On 11.02.20 10:33, Eugenio Pérez wrote: > On Mon, 2020-02-10 at 12:01 +0100, Christian Borntraeger wrote: >> >> On 10.02.20 10:47, Eugenio Perez Martin wrote: >>> Hi Christian. >>> >>> I'm not able to reproduce the failure with >>> eccb852f1fe

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-10 Thread Christian Borntraeger
On 10.02.20 10:47, Eugenio Perez Martin wrote: > Hi Christian. > > I'm not able to reproduce the failure with > eccb852f1fe6bede630e2e4f1a121a81e34354ab commit. Could you add more data? > Your configuration (libvirt or qemu line), and host's dmesg output if any? > > Thanks! If it was not

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-10 Thread Christian Borntraeger
e both problems go away. > > Thanks! > > On Fri, Feb 7, 2020 at 9:13 AM Christian Borntraeger <mailto:borntrae...@de.ibm.com>> wrote: > > > > On 07.02.20 08:58, Michael S. Tsirkin wrote: > > On Fri, Feb 07, 2020 at 08:47:14AM +0100, Chri

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-07 Thread Christian Borntraeger
On 07.02.20 08:58, Michael S. Tsirkin wrote: > On Fri, Feb 07, 2020 at 08:47:14AM +0100, Christian Borntraeger wrote: >> Also adding Cornelia. >> >> >> On 06.02.20 23:17, Michael S. Tsirkin wrote: >>> On Thu, Feb 06, 2020 at 04:12:21P

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-06 Thread Christian Borntraeger
Also adding Cornelia. On 06.02.20 23:17, Michael S. Tsirkin wrote: > On Thu, Feb 06, 2020 at 04:12:21PM +0100, Christian Borntraeger wrote: >> >> >> On 06.02.20 15:22, epere...@redhat.com wrote: >>> Hi Christian. >>> >>> Could you try this p

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-02-06 Thread Christian Borntraeger
On 06.02.20 15:22, epere...@redhat.com wrote: > Hi Christian. > > Could you try this patch on top of ("38ced0208491 vhost: use batched version > by default")? > > It will not solve your first random crash but it should help with the lost of > network connectivity. > > Please let me know

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-01-22 Thread Christian Borntraeger
On 20.01.20 07:27, Michael S. Tsirkin wrote: > On Tue, Jan 07, 2020 at 01:16:50PM +0100, Christian Borntraeger wrote: >> On 07.01.20 12:55, Michael S. Tsirkin wrote: >> >>> >>> I pushed batched-v3 - same head but bisect should wo

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-01-07 Thread Christian Borntraeger
On 07.01.20 12:55, Michael S. Tsirkin wrote: > > I pushed batched-v3 - same head but bisect should work now. > With commit 38ced0208491103b50f1056f0d1c8f28e2e13d08 (HEAD) Author: Michael S. Tsirkin AuthorDate: Wed Dec 11 12:19:26 2019 -0500 Commit: Michael S. Tsirkin CommitDate: Tue

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-01-07 Thread Christian Borntraeger
On 07.01.20 10:39, Michael S. Tsirkin wrote: > On Tue, Jan 07, 2020 at 09:59:16AM +0100, Christian Borntraeger wrote: >> >> >> On 06.01.20 11:50, Michael S. Tsirkin wrote: >>> On Wed, Dec 18, 2019 at 04:59:02PM +0100, Christian Borntraeger wrote: >>>> O

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2020-01-07 Thread Christian Borntraeger
On 06.01.20 11:50, Michael S. Tsirkin wrote: > On Wed, Dec 18, 2019 at 04:59:02PM +0100, Christian Borntraeger wrote: >> On 18.12.19 16:10, Michael S. Tsirkin wrote: >>> On Wed, Dec 18, 2019 at 03:43:43PM +0100, Christian Borntraeger wrote: >>>> Michae

Re: vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2019-12-18 Thread Christian Borntraeger
On 18.12.19 16:10, Michael S. Tsirkin wrote: > On Wed, Dec 18, 2019 at 03:43:43PM +0100, Christian Borntraeger wrote: >> Michael, >> >> with >> commit db7286b100b503ef80612884453bed53d74c9a16 >> (refs/bisect/skip-db7286b100b503ef80612884453bed53d74c9a16)

vhost changes (batched) in linux-next after 12/13 trigger random crashes in KVM guests after reboot

2019-12-18 Thread Christian Borntraeger
Michael, with commit db7286b100b503ef80612884453bed53d74c9a16 (refs/bisect/skip-db7286b100b503ef80612884453bed53d74c9a16) vhost: use batched version by default plus commit 6bd262d5eafcdf8cdfae491e2e748e4e434dcda6 (HEAD, refs/bisect/bad) Revert "vhost/net: add an option to test new code"

Re: [PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h

2019-11-11 Thread Christian Borntraeger
On 08.11.19 20:57, Arnd Bergmann wrote: > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon wrote: >> >> In preparation for allowing architectures to define their own >> implementation of the 'READ_ONCE()' macro, move the generic >> '{READ,WRITE}_ONCE()' definitions out of the unwieldy

Re: [PATCH 1/1] virtio/s390: fix race on airq_areas[]

2019-07-24 Thread Christian Borntraeger
On 24.07.19 10:34, Cornelia Huck wrote: > On Wed, 24 Jul 2019 08:44:19 +0200 > Christian Borntraeger wrote: > >> On 24.07.19 00:58, Halil Pasic wrote: >>> The access to airq_areas was racy ever since the adapter interrupts got >>> introduced to virtio-c

Re: [PATCH 1/1] virtio/s390: fix race on airq_areas[]

2019-07-24 Thread Christian Borntraeger
On 24.07.19 00:58, Halil Pasic wrote: > The access to airq_areas was racy ever since the adapter interrupts got > introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390: > make airq summary indicators DMA") this became an issue in practice as > well. Namely before that commit the

Re: [PATCH v3 5/8] virtio/s390: use cacheline aligned airq bit vectors

2019-06-03 Thread Christian Borntraeger
erfect sense. Reviewed-by: Christian Borntraeger > > Signed-off-by: Halil Pasic > Signed-off-by: Michael Mueller > --- > drivers/s390/virtio/virtio_ccw.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/s390/virtio/virtio_ccw.c > b/d

Re: [PATCH 01/10] virtio/s390: use vring_create_virtqueue

2019-05-07 Thread Christian Borntraeger
On 05.05.19 13:15, Cornelia Huck wrote: > On Sat, 4 May 2019 16:03:40 +0200 > Halil Pasic wrote: > >> On Fri, 3 May 2019 16:04:48 -0400 >> "Michael S. Tsirkin" wrote: >> >>> On Fri, May 03, 2019 at 11:17:24AM +0200, Cornelia Huck wrote: On Fri, 26 Apr 2019 20:32:36 +0200 Halil

Re: [PATCH 04/10] s390/mm: force swiotlb for protected virtualization

2019-04-29 Thread Christian Borntraeger
On 29.04.19 15:59, Halil Pasic wrote: > On Fri, 26 Apr 2019 12:27:11 -0700 > Christoph Hellwig wrote: > >> On Fri, Apr 26, 2019 at 08:32:39PM +0200, Halil Pasic wrote: >>> +EXPORT_SYMBOL_GPL(set_memory_encrypted); >> >>> +EXPORT_SYMBOL_GPL(set_memory_decrypted); >> >>>

Re: [PATCH v3 1/3] virtio-balloon: tweak config_changed implementation

2019-01-09 Thread Christian Borntraeger
On 09.01.2019 15:52, Michael S. Tsirkin wrote: > On Wed, Jan 09, 2019 at 01:07:16PM +0100, Christian Borntraeger wrote: >> On 09.01.2019 11:35, Wei Wang wrote: >>> On 01/08/2019 04:46 PM, Christian Borntraeger wrote: >>>> >>>> On 08.01.2019 06:35, We

Re: [PATCH v1 2/2] virtio: don't allocate vqs when names[i] = NULL

2019-01-09 Thread Christian Borntraeger
Cc: sta...@vger.kernel.org Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") On 28.12.2018 03:26, Wei Wang wrote: > Some vqs may not need to be allocated when their related feature bits > are disabled. So callers may pass in such vqs with "names = NULL". > Then we skip such

Re: [PATCH v3 1/3] virtio-balloon: tweak config_changed implementation

2019-01-09 Thread Christian Borntraeger
On 09.01.2019 11:35, Wei Wang wrote: > On 01/08/2019 04:46 PM, Christian Borntraeger wrote: >> >> On 08.01.2019 06:35, Wei Wang wrote: >>> On 01/07/2019 09:49 PM, Christian Borntraeger wrote: >>>> On 07.01.2019 08:01, Wei Wang wrote: >>>>> vir

Re: [PATCH v1 1/2] virtio_pci: use queue idx instead of array idx to set up the vq

2019-01-09 Thread Christian Borntraeger
Cc: sta...@vger.kernel.org Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT") On 28.12.2018 03:26, Wei Wang wrote: > When find_vqs, there will be no vq[i] allocation if its corresponding > names[i] is NULL. For example, the caller may pass in names[i] (i=4) > with names[2]

Re: [PATCH] vhost/vsock: fix vhost vsock cid hashing inconsistent

2019-01-09 Thread Christian Borntraeger
Adding Peter, is this the same problem that you reported me today? Can you test Zha Bins patch? Christian On 08.01.2019 09:07, Zha Bin wrote: > The vsock core only supports 32bit CID, but the Virtio-vsock spec define > CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as > zero.

Re: [PATCH v3 1/3] virtio-balloon: tweak config_changed implementation

2019-01-08 Thread Christian Borntraeger
On 08.01.2019 06:35, Wei Wang wrote: > On 01/07/2019 09:49 PM, Christian Borntraeger wrote: >> >> On 07.01.2019 08:01, Wei Wang wrote: >>> virtio-ccw has deadlock issues with reading the config space inside the >>> interrupt context, so we tweak the v

Re: [PATCH v3 0/3] virtio-balloon: tweak config_changed

2019-01-07 Thread Christian Borntraeger
On 07.01.2019 14:45, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 03:01:03PM +0800, Wei Wang wrote: >> Since virtio-ccw doesn't work with accessing to the config space >> inside an interrupt context, this patch series avoids that issue by >> moving the config register accesses to the

Re: [PATCH v3 1/3] virtio-balloon: tweak config_changed implementation

2019-01-07 Thread Christian Borntraeger
tmap is used as a flag to the workqueue callbacks > about the related config fields that need to be read. > > The cmd_id_received is also renamed to cmd_id_received_cache, and > the value should be obtained via virtio_balloon_cmd_id_received. > > Reported-by: Christian Borntrae

Re: [PATCH v3 0/3] virtio-balloon: tweak config_changed

2019-01-07 Thread Christian Borntraeger
Can you please cc stable? Right now 4.20 does not work under KVM. On 07.01.2019 08:01, Wei Wang wrote: > Since virtio-ccw doesn't work with accessing to the config space > inside an interrupt context, this patch series avoids that issue by > moving the config register accesses to the related

Re: [PATCH v37 1/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

2018-12-28 Thread Christian Borntraeger
On 28.12.2018 04:12, Wei Wang wrote: > On 12/27/2018 08:03 PM, Christian Borntraeger wrote: >> On 27.08.2018 03:32, Wei Wang wrote: >>>   static int init_vqs(struct virtio_balloon *vb) >>>   { >>> -    struct virtqueue *vqs[3]; >>> -    vq_callbac

Re: [PATCH v1 0/2] Virtio: fix some vq allocation issues

2018-12-27 Thread Christian Borntraeger
On 28.12.2018 03:26, Wei Wang wrote: > Some vqs don't need to be allocated when the related feature bits are > disabled. Callers notice the vq allocation layer by setting the related > names[i] to be NULL. > > This patch series fixes the find_vqs implementations to handle this case. So the

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

2018-12-27 Thread Christian Borntraeger
On 27.12.2018 12:59, Christian Borntraeger wrote: > On 27.12.2018 12:31, Christian Borntraeger wrote: >> This patch triggers random crashes in the guest kernel on s390 early during >> boot. >> No migration and no setting of the balloon is involved. >>

Re: [PATCH v37 1/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

2018-12-27 Thread Christian Borntraeger
On 27.08.2018 03:32, Wei Wang wrote: > static int init_vqs(struct virtio_balloon *vb) > { > - struct virtqueue *vqs[3]; > - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request > }; > - static const char * const names[] = { "inflate", "deflate", "stats" }; > -

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

2018-12-27 Thread Christian Borntraeger
On 27.12.2018 12:31, Christian Borntraeger wrote: > This patch triggers random crashes in the guest kernel on s390 early during > boot. > No migration and no setting of the balloon is involved. > Adding Conny and Halil, As the QEMU provides no PAGE_HINT feature yet, this quic

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

2018-12-27 Thread Christian Borntraeger
This patch triggers random crashes in the guest kernel on s390 early during boot. No migration and no setting of the balloon is involved. On 27.08.2018 03:32, Wei Wang wrote: > The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this > series enables the virtio-balloon driver to

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

2018-12-20 Thread Christian Borntraeger
On 20.12.2018 18:23, Willem de Bruijn wrote: > On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel wrote: >> >> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote: >>> On 20.12.2018 10:12, Ido Schimmel wrote: >>>> +Willem >>>&g

Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

2018-12-20 Thread Christian Borntraeger
On 20.12.2018 10:12, Ido Schimmel wrote: > +Willem > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: >> Folks, >> >> I got this warning today. I cant tell when and why this happened, so I do >> not know yet how to reproduce.

4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

2018-12-19 Thread Christian Borntraeger
Folks, I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. Maybe someone has a quick idea. [85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318 [85109.572036] Modules linked in:

Re: [PATCH 0/1] vhost: add vhost_blk driver

2018-11-05 Thread Christian Borntraeger
On 11/05/2018 04:00 AM, Jason Wang wrote: > > On 2018/11/3 上午2:21, Vitaly Mayatskikh wrote: >> vhost_blk is a host-side kernel mode accelerator for virtio-blk. The >> driver allows VM to reach a near bare-metal disk performance. See IOPS >> numbers below (fio --rw=randread --bs=4k). >> >> This

Re: [PATCH 0/1] vhost: add vhost_blk driver

2018-11-05 Thread Christian Borntraeger
On 11/02/2018 07:26 PM, Michael S. Tsirkin wrote: > On Fri, Nov 02, 2018 at 06:21:22PM +, Vitaly Mayatskikh wrote: >> vhost_blk is a host-side kernel mode accelerator for virtio-blk. The >> driver allows VM to reach a near bare-metal disk performance. See IOPS >> numbers below (fio

Re: [PATCH 0/2] virtio/s390: fix some races in virtio-ccw

2018-09-24 Thread Christian Borntraeger
Can you consider adding stable tags to the (final version of the) fixes? On 09/21/2018 02:46 PM, Halil Pasic wrote: > The trigger for the series is this bug report: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 > > Changelog: > RFC -> v1: > * do mutual exclusion on a per device

Re: virtio-gpu: Hang on shutdown after suspend/resume with virtio

2018-03-13 Thread Christian Borntraeger
Also add David and dri list. Short summary, suspend/resume breaks with virtio-gpu as there are no freeze/restore callbacks that put the device back into working state. On 03/13/2018 02:32 PM, Christian Borntraeger wrote: > > > On 03/13/2018 01:41 PM, Christian Borntraeger wrote

Re: virtio-gpu: Hang on shutdown after suspend/resume with virtio

2018-03-13 Thread Christian Borntraeger
On 03/13/2018 01:41 PM, Christian Borntraeger wrote: > Gerd, > > another thing with virtio-gpu. > > I can successfully do suspend/resume (echo disk > /sys/power/state) on my > system. As soon as I have a > virtio-gpu the system hangs on reboot/shutdown: > >

Re: [PULL v2 1/1] virtio/s390: implement PM operations for virtio_ccw

2018-02-12 Thread Christian Borntraeger
Michael, Conny, it seems that this patch did not make it into 4.16-rc1. On 12/18/2017 05:21 PM, Cornelia Huck wrote: > From: Christian Borntraeger <borntrae...@de.ibm.com> > > Suspend/Resume to/from disk currently fails. Let us wire > up the necessary callbacks. This is most

Re: [PATCH] virtio/s390: fixup for implement PM operations for virtio_ccw

2017-12-18 Thread Christian Borntraeger
On 12/18/2017 09:52 AM, Thomas Huth wrote: > On 18.12.2017 09:37, Christian Borntraeger wrote: >> We need to disable the pm callbacks if CONFIG_PM is not set. >> >> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> >> --- >> Cornelia, you migh

[PATCH] virtio/s390: fixup for implement PM operations for virtio_ccw

2017-12-18 Thread Christian Borntraeger
We need to disable the pm callbacks if CONFIG_PM is not set. Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- Cornelia, you might want to squash this into the original commit. drivers/s390/virtio/virtio_ccw.c | 4 1 file changed, 4 insertions(+) diff --git a/driver

[PATCH 1/1] virtio/s390: implement PM operations for virtio_ccw

2017-12-07 Thread Christian Borntraeger
ed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- drivers/s390/virtio/virtio_ccw.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index b18fe201..330b3fa 100644 --- a/drivers

[PATCH 0/1] suspend/resume for virtio_ccw

2017-12-07 Thread Christian Borntraeger
/00 3832/02 yes 80 80 ff 0.3.ffba 0.3. /00 3832/05 yes 80 80 ff [root@test power]# Christian Borntraeger (1): virtio/s390: implement PM operations for virtio_ccw drivers/s390/virtio/virtio_ccw.c | 25 +

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 09:21 PM, Jens Axboe wrote: > On 11/21/2017 01:19 PM, Christian Borntraeger wrote: >> >> On 11/21/2017 09:14 PM, Jens Axboe wrote: >>> On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 09:14 PM, Jens Axboe wrote: > On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 08:30 PM, Jens Axboe wrote: >>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 08:30 PM, Jens Axboe wrote: > On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 07:39 PM, Jens Axboe wrote: >>> On 11/21/2017 11:27 AM, Jens Axboe wrote: >>>> On 11/21/2017 11:12 AM, Christian Borntraeger wrote

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 07:39 PM, Jens Axboe wrote: > On 11/21/2017 11:27 AM, Jens Axboe wrote: >> On 11/21/2017 11:12 AM, Christian Borntraeger wrote: >>> >>> >>> On 11/21/2017 07:09 PM, Jens Axboe wrote: >>>> On 11/21/2017 10:27 AM, Jens Axboe wrote: >

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 07:09 PM, Jens Axboe wrote: > On 11/21/2017 10:27 AM, Jens Axboe wrote: >> On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >>> Bisect points to >>> >>> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >>> co

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 10:50 AM, Christian Borntraeger wrote: > > > On 11/21/2017 09:35 AM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 09:52 PM, Jens Axboe wrote: >>> On 11/20/2017 01:49 PM, Christian Borntraeger wrote: >>>> >>>> &

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk

2017-11-21 Thread Christian Borntraeger
On 11/21/2017 09:35 AM, Christian Borntraeger wrote: > > > On 11/20/2017 09:52 PM, Jens Axboe wrote: >> On 11/20/2017 01:49 PM, Christian Borntraeger wrote: >>> >>> >>> On 11/20/2017 08:42 PM, Jens Axboe wrote: >>>> On 11/20/2017 12:29 PM

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk

2017-11-21 Thread Christian Borntraeger
On 11/20/2017 09:52 PM, Jens Axboe wrote: > On 11/20/2017 01:49 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:42 PM, Jens Axboe wrote: >>> On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk

2017-11-20 Thread Christian Borntraeger
On 11/20/2017 08:20 PM, Bart Van Assche wrote: > On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >> This is >> >> b7a71e66d (Jens Axboe2017-08-01 09:28:24 -0600 1141) * >> are mapped to it. >> b7a71e66d (Jens Axboe

4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk

2017-11-17 Thread Christian Borntraeger
When doing cpu hotplug in a KVM guest with virtio blk I get warnings like 747.652408] [ cut here ] [ 747.652410] WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 __blk_mq_run_hw_queue+0xd4/0x100 [ 747.652410] Modules linked in: dm_multipath [ 747.652412] CPU: 4 PID:

Re: [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default

2017-09-26 Thread Christian Borntraeger
On 09/26/2017 12:40 PM, Heiko Carstens wrote: > On Mon, Sep 25, 2017 at 08:37:36PM +0200, Christian Borntraeger wrote: >> >> On 09/25/2017 07:54 PM, Halil Pasic wrote: >>> >>> >>> On 09/25/2017 04:45 PM, Thomas Huth wrote: >>>> There is no

Re: [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default

2017-09-26 Thread Christian Borntraeger
On 09/25/2017 04:45 PM, Thomas Huth wrote: > There is no recent user space application available anymore which still > supports this old virtio transport, so let's disable this by default. > > Signed-off-by: Thomas Huth thanks applied. > --- > arch/s390/Kconfig | 2 +- > 1

Re: [PATCH] KVM: s390: Disable CONFIG_S390_GUEST_OLD_TRANSPORT by default

2017-09-25 Thread Christian Borntraeger
e them among the recipients. FWIW as the original author of that transport Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> I can pick this up for Martins/Heikos tree if you want. > > Regards, > Halil > >> --- >> arch/s390/Kconfig | 2 +- >> 1 file ch

Re: [PATCH net] Revert "vhost: cache used event for better performance"

2017-07-26 Thread Christian Borntraeger
On 07/26/2017 10:03 AM, Jason Wang wrote: > This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it > was reported to break vhost_net. We want to cache used event and use > it to check for notification. We try to valid cached used event by > checking whether or not it was ahead of

Re: [PATCH 0/1] Change email address

2017-07-04 Thread Christian Borntraeger
request tomorrow so I'll include this too. Ok, Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> > > Paolo > >> Cornelia Huck (1): >> Update my email address >> >> MAINTAINERS | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >

Re: [PATCH v11 4/6] mm: function to offer a page block on the free list

2017-06-21 Thread Christian Borntraeger
On 06/20/2017 06:49 PM, David Hildenbrand wrote: > On 20.06.2017 18:44, Rik van Riel wrote: >> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote: >> >>> The hypervisor is going to throw away the contents of these pages, >>> right? As soon as the spinlock is released, someone can allocate a >>>

Re: [PATCH 1/1] s390/virtio: change maintainership

2017-04-20 Thread Christian Borntraeger
On 03/02/2017 05:08 PM, Christian Borntraeger wrote: > Halil is doing a lot more work in the virtio area on s390 than I > do. Let's reflect the reality in the maintainers file. > > Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> > Acked-by: Halil Pasic <

[PATCH 0/1] virtio-ccw maintainership

2017-03-02 Thread Christian Borntraeger
Michael, Jason, Halil is doing more work on virtio-ccw and virtio in general than I do. I seem to be busy enough with the KVM/s390 maintainership. So it is time to reflect reality in the maintainer file. Lets start with the kernel. Christian Borntraeger (1): s390/virtio: change maintainership

[PATCH 1/1] s390/virtio: change maintainership

2017-03-02 Thread Christian Borntraeger
Halil is doing a lot more work in the virtio area on s390 than I do. Let's reflect the reality in the maintainers file. Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> Acked-by: Halil Pasic <pa...@linux.vnet.ibm.com> Acked-by: Cornelia Huck <cornelia.

Re: packed ring layout proposal v2

2017-02-09 Thread Christian Borntraeger
On 02/09/2017 06:43 PM, Michael S. Tsirkin wrote: [...] >> [...] >>> Note: should this proposal be accepted and approved, one or more >>> claims disclosed to the TC admin and listed on the Virtio TC >>> IPR page https://www.oasis-open.org/committees/virtio/ipr.php >>> might

Re: packed ring layout proposal v2

2017-02-08 Thread Christian Borntraeger
On 02/08/2017 04:20 AM, Michael S. Tsirkin wrote: [...] > * Prototype > > A partial prototype can be found under > tools/virtio/ringtest/ring.c > > Test run: > [mst@tuck ringtest]$ time ./ring > real0m0.399s > user0m0.791s > sys 0m0.000s > [mst@tuck ringtest]$ time ./virtio_ring_0_9

  1   2   3   4   >