On 10/15/23 10:42, Michael S. Tsirkin wrote:
> On Sat, Oct 14, 2023 at 09:06:09PM +0000, Vincent Jardin wrote:
>> On 10/14/23 18:37, Michael S. Tsirkin wrote:
>>> On Sat, Oct 14, 2023 at 06:22:34PM +0200, Vincent Jardin wrote:
>>>> Using interface's settings,
Do never set the link down when the vhost-user socket is disconnected.
XXX: currently, it cannot work. It is a reply commit to the former
one that was a RFC on virtio-net. Don't use it.
I do not understand how to get NetdevVhostUserOptions yet.
Signed-off-by: Vincent Jardin
---
net/
On 10/14/23 18:37, Michael S. Tsirkin wrote:
> On Sat, Oct 14, 2023 at 06:22:34PM +0200, Vincent Jardin wrote:
>> Using interface's settings, let's enforce an always on link up.
>>
>> Signed-off-by: Vincent Jardin
>
> What is going on here? Just don
Using interface's settings, let's enforce an always on link up.
Signed-off-by: Vincent Jardin
---
hw/net/virtio-net.c| 8
include/hw/virtio/virtio-net.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index
Let's close it. Sorry, it should be opened into:
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1556306
Title:
vhost-user: qemu stops processi
Correct, it is fixed in Qemu upstream. Just need to get it used into my
ubuntu.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1556306
Title:
vhost-user: qemu stops processing packets under high lo
for tracking,
http://git.qemu.org/?p=qemu.git;a=patch;h=5669655aafdb88a8797c74a989dd0c0ebb1349fa
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1556306
Title:
vhost-user: qemu stops processing p
Public bug reported:
Description of problem:
- qemu socket becomes full, causing qemu to send incomplete
SET_VRING_CALL messages to vhost-user backend (without proper fd set in
ancillary data).
- after some time, some interrupts are lost, causing the VM to stop
transmitting packets.
How reproduci
Tim,
cc-ing Paolo and qemu-devel@ again in order to get their take on it.
Did you make any progress in Qemu/KVM community?
We need to be sync'ed up with them to be sure we share the same goal.
I want also to avoid using a solution which doesn't fit with their plan.
Remember that we already had
Hi Cam,
FYI, David did implement a new server.
http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg04978.html
which is easier to maintain.
Please, could you review his patch? He'll be back from holiday within 1
week.
Best regards,
Vincent
PS: thanks for your comments
(resending, this email is missing at
http://lists.nongnu.org/archive/html/qemu-devel/2014-06/index.html)
> Fine, however Red Hat would also need a way to test ivshmem code, with
> proper quality assurance (that also benefits upstream, of course).
> With ivshmem this is not possible without the
Fine, however Red Hat would also need a way to test ivshmem code, with
proper quality assurance (that also benefits upstream, of course). With
ivshmem this is not possible without the out-of-tree packages.
You did not reply to my question: how to get the list of things that
are/will be disable
(+merging with Paolo's email because of overlaps)
see inline (I am not on all mailing list, please, keep the cc list).
1. ivshmem code needs work, but has no maintainer
See David's contributions:
http://patchwork.ozlabs.org/patch/358750/
We're grateful for David's patch for qemu-char.c
Markus,
see inline (I am not on all mailing list, please, keep the cc list).
> Sure! The reasons for my dislike range from practical to
> philosophical.
My practical concerns include:
1. ivshmem code needs work, but has no maintainer
See David's contributions:
http://patchwork.ozlabs.org/
On 12/06/2014 09:44, Henning Schild wrote:
It may be used, but that doesn't mean it's maintained, or robust
>against abuse. My advice is to steer clear of it.
Could you elaborate on why you advice against it?
+1 elaborate please.
beside the DPDK source code, some other common use cases:
-
On 10/06/2014 18:48, Henning Schild wrote:> Hi,
> In a first prototype i implemented a ivshmem[2] device for the
> hypervisor. That way we can share memory between virtual machines.
> Ivshmem is nice and simple but does not seem to be used anymore.
> And it
> does not define higher level devices,
16 matches
Mail list logo
