Am 12.11.22 um 17:19 schrieb Dmitry Vyukov:
Hi,
The original email is from 2009, so I assume you don't have it in
your inboxes already. Here is the original email:
https://lore.kernel.org/all/200906190927.34831.borntrae...@de.ibm.com/
This patch introduces a prototype for a virtio_test
Am 19.10.22 um 13:50 schrieb Michael S. Tsirkin:
On Wed, Oct 19, 2022 at 12:59:58PM +0200, Christian Borntraeger wrote:
Michael,
as a heads-up.
I have not looked into any details yet but we do get the following during
reboot of a system on s390.
It seems to be new with 6.1-rc1 (over 6.0
Am 19.10.22 um 12:59 schrieb Christian Borntraeger:
Michael,
as a heads-up.
I have not looked into any details yet but we do get the following during
reboot of a system on s390.
It seems to be new with 6.1-rc1 (over 6.0)
Its not the reboot, its the boot with a kernel with debugging enabled
Michael,
as a heads-up.
I have not looked into any details yet but we do get the following during
reboot of a system on s390.
It seems to be new with 6.1-rc1 (over 6.0)
[8.532461] [ cut here ]
[8.532497] WARNING: CPU: 8 PID: 377 at
Am 27.09.22 um 07:35 schrieb Christian Borntraeger:
Am 26.09.22 um 20:22 schrieb Peter Zijlstra:
On Mon, Sep 26, 2022 at 08:06:46PM +0200, Peter Zijlstra wrote:
Let me go git-grep some to see if there's more similar fail.
I've ended up with the below...
Tested-by: Christian
Am 26.09.22 um 20:22 schrieb Peter Zijlstra:
On Mon, Sep 26, 2022 at 08:06:46PM +0200, Peter Zijlstra wrote:
Let me go git-grep some to see if there's more similar fail.
I've ended up with the below...
Tested-by: Christian Borntraeger
Kind of scary that nobody else has reported any
Am 26.09.22 um 15:37 schrieb Peter Zijlstra:
On Mon, Sep 26, 2022 at 03:23:10PM +0200, Christian Borntraeger wrote:
Am 26.09.22 um 14:55 schrieb Peter Zijlstra:
Could you please test with something like the below on? I can boot that
with KVM, but obviously I didn't suffer any weirdness
Am 26.09.22 um 15:37 schrieb Peter Zijlstra:
On Mon, Sep 26, 2022 at 03:23:10PM +0200, Christian Borntraeger wrote:
Am 26.09.22 um 14:55 schrieb Peter Zijlstra:
Could you please test with something like the below on? I can boot that
with KVM, but obviously I didn't suffer any weirdness
Am 26.09.22 um 14:55 schrieb Peter Zijlstra:
Could you please test with something like the below on? I can boot that
with KVM, but obviously I didn't suffer any weirdness to begin with :/
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4e6a6417211f..ef9ccfc3a8c0 100644
---
Am 26.09.22 um 12:55 schrieb Christian Borntraeger:
Am 26.09.22 um 10:06 schrieb Christian Borntraeger:
Am 23.09.22 um 09:53 schrieb Christian Borntraeger:
Am 23.09.22 um 09:21 schrieb Christian Borntraeger:
Peter,
as a heads-up. This commit (bisected and verified) triggers
Am 13.10.21 um 12:10 schrieb Michael S. Tsirkin:
On Mon, Oct 11, 2021 at 07:39:21AM +0200, Halil Pasic wrote:
The virtio specification virtio-v1.1-cs01 states: "Transitional devices
MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
been acknowledged by the driver."
Am 30.09.21 um 03:20 schrieb Halil Pasic:
This patch fixes a regression introduced by commit 82e89ea077b9
("virtio-blk: Add validation for block size in config space") and
enables similar checks in verify() on big endian platforms.
The problem with checking multi-byte config fields in the
Am 30.09.21 um 03:20 schrieb Halil Pasic:
This patch fixes a regression introduced by commit 82e89ea077b9
("virtio-blk: Add validation for block size in config space") and
enables similar checks in verify() on big endian platforms.
The problem with checking multi-byte config fields in the
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
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
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
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 +
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 ++
>
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 ++
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
&
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
+/*
>> + * 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
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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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"
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
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
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
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
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
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);
>>
>>>
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
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
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
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]
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.
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
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
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
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
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
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
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.
>>
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" };
> -
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
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
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
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.
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:
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
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
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
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
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:
>
>
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
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
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
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
/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 +
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
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
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
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:
>
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
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:
>>>>
>>>>
&
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
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
1 - 100 of 319 matches
Mail list logo
