Make rx buf len configurable via sysfs
Signed-off-by: Jiang Wang
---
net/vmw_vsock/virtio_transport.c | 46 ++--
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index
Added test cases for vsock dgram types.
Signed-off-by: Jiang Wang
---
tools/testing/vsock/util.c | 105 +
tools/testing/vsock/util.h | 4 +
tools/testing/vsock/vsock_test.c | 195 +++
3 files changed, 304 insertions(+)
diff --git
This patch supports dgram on vhost side, including
tx and rx. The vhost send packets asynchronously.
Also, ignore vq errors when vq number is larger than 2,
so it will be comptaible with old versions.
Signed-off-by: Jiang Wang
---
drivers/vhost/vsock.c | 217
This patch add support for virtio dgram for the driver.
Implemented related functions for tx and rx, enqueue
and dequeue. Send packets synchronously to give sender
indication when the virtqueue is full.
Refactored virtio_transport_send_pkt_work() a little bit but
no functions changes for it.
When this feature is enabled, allocate 5 queues,
otherwise, allocate 3 queues to be compatible with
old QEMU versions.
Signed-off-by: Jiang Wang
---
drivers/vhost/vsock.c | 3 +-
include/linux/virtio_vsock.h | 9
include/uapi/linux/virtio_vsock.h | 2 +
This patchset implements support of SOCK_DGRAM for virtio
transport.
Datagram sockets are connectionless and unreliable. To avoid unfair contention
with stream and other sockets, add two more virtqueues and
a new feature bit to indicate if those two new queues exist or not.
Dgram does not use
On Thu, Sep 9, 2021 at 8:36 PM Eli Cohen wrote:
>
> Add code to register to hardware asynchronous events. Use this
> mechanism to track link status events coming from the device and update
> the config struct.
>
> After doing link status change, call the vdpa callback to notify of the
> link
On Thu, Sep 9, 2021 at 8:36 PM Eli Cohen wrote:
>
> A subesequent patch will use the same workqueue for executing other
> work not related to control VQ. Rename the workqueue and the work queue
> entry used to convey information to the workqueue.
>
> Signed-off-by: Eli Cohen
Acked-by: Jason
On Thu, Sep 9, 2021 at 2:37 PM Eli Cohen wrote:
>
> Avoid executing set_vq_ready() if the device has been reset. In such
> case, the features are cleared and cannot be used in conditional
> statements. Such reference happens is the function ctrl_vq_idx().
>
> Fixes: 9c90709cf8e7 ("vdpa/mlx5: Add
On Thu, Sep 9, 2021 at 2:37 PM Eli Cohen wrote:
>
> When clearing VQs ready indication for the data VQs, do the same for the
> control VQ.
>
> Fixes: 5262912ef3cf ("vdpa/mlx5: Add support for control VQ and MAC setting")
> Signed-off-by: Eli Cohen
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 2
On Mon, Sep 13, 2021 at 6:47 PM Michael S. Tsirkin wrote:
>
> A recent change checking of_device_is_compatible on probe broke some
> powerpc/pseries setups. Apparently there virtio devices do not have a
> "compatible" property - they are matched by PCI vendor/device ids.
>
> Let's just skip
在 2021/9/14 上午5:36, Thomas Gleixner 写道:
Jason,
On Mon, Sep 13 2021 at 13:53, Jason Wang wrote:
This patch tries to make sure the virtio interrupt handler for INTX
won't be called after a reset and before virtio_device_ready(). We
can't use IRQF_NO_AUTOEN since we're using shared interrupt
在 2021/9/13 下午3:48, Stefano Garzarella 写道:
On Mon, Sep 13, 2021 at 01:53:45PM +0800, Jason Wang wrote:
If an untrusted device neogitates BLK_F_MQ but advertises a zero
num_queues, the driver may end up trying to allocating zero size
buffers where ZERO_SIZE_PTR is returned which may pass the
在 2021/9/14 上午6:31, Thomas Gleixner 写道:
On Mon, Sep 13 2021 at 16:54, Michael S. Tsirkin wrote:
On Mon, Sep 13, 2021 at 09:38:30PM +0200, Thomas Gleixner wrote:
On Mon, Sep 13 2021 at 15:07, Jason Wang wrote:
On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote:
But doen't "irq is
On Mon, Sep 13 2021 at 16:54, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 09:38:30PM +0200, Thomas Gleixner wrote:
>> On Mon, Sep 13 2021 at 15:07, Jason Wang wrote:
>> > On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote:
>> >> > But doen't "irq is disabled" basically mean "we
On Mon, Sep 13 2021 at 18:01, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 11:36:24PM +0200, Thomas Gleixner wrote:
>> >From the interrupt perspective the sequence:
>>
>> disable_irq();
>> vp_dev->intx_soft_enabled = true;
>> enable_irq();
>>
>> is perfectly fine
On Thu, Sep 09, 2021 at 03:36:33PM +0300, Eli Cohen wrote:
> No need to save the mtu int the net device struct. We can save it in the
> config struct which cannot be modified.
>
> Moreover, move the initialization to. mlx5_vdpa_set_features() callback
> is not the right place to put it.
the
On Mon, Sep 13, 2021 at 11:36:24PM +0200, Thomas Gleixner wrote:
> >From the interrupt perspective the sequence:
>
> disable_irq();
> vp_dev->intx_soft_enabled = true;
> enable_irq();
>
> is perfectly fine as well. Any interrupt arriving during the disabled
> section will
Jason,
On Mon, Sep 13 2021 at 13:53, Jason Wang wrote:
> This patch tries to make sure the virtio interrupt handler for INTX
> won't be called after a reset and before virtio_device_ready(). We
> can't use IRQF_NO_AUTOEN since we're using shared interrupt
> (IRQF_SHARED). So this patch tracks the
On Mon, Sep 13, 2021 at 12:04:04PM -0500, Mike Christie wrote:
> I just realized I forgot to cc the virt list so adding now.
>
> Christian see the very bottom for a different fork patch.
>
> On 7/12/21 7:05 AM, Stefan Hajnoczi wrote:
> > On Fri, Jul 09, 2021 at 11:25:37AM -0500, Mike Christie
On Mon, Sep 13, 2021 at 04:23:57PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 06:47:52AM -0400, Michael S. Tsirkin wrote:
> > A recent change checking of_device_is_compatible on probe broke some
> > powerpc/pseries setups. Apparently there virtio devices do not have a
> >
On Mon, Sep 13, 2021 at 09:38:30PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 13 2021 at 15:07, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote:
> >> > But doen't "irq is disabled" basically mean "we told the hypervisor
> >> > to disable the irq"? What extractly
On Mon, Sep 13, 2021 at 06:47:46AM -0400, Michael S. Tsirkin wrote:
> A recent change checking of_device_is_compatible on probe broke some
> powerpc/pseries setups. Apparently there virtio devices do not have a
> "compatible" property - they are matched by PCI vendor/device ids.
>
> Let's just
On Mon, Sep 13, 2021 at 06:47:52AM -0400, Michael S. Tsirkin wrote:
> A recent change checking of_device_is_compatible on probe broke some
> powerpc/pseries setups. Apparently there virtio devices do not have a
> "compatible" property - they are matched by PCI vendor/device ids.
>
> Let's just
On Mon, Sep 13 2021 at 15:07, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote:
>> > But doen't "irq is disabled" basically mean "we told the hypervisor
>> > to disable the irq"? What extractly prevents hypervisor from
>> > sending the irq even if guest thinks it
I just realized I forgot to cc the virt list so adding now.
Christian see the very bottom for a different fork patch.
On 7/12/21 7:05 AM, Stefan Hajnoczi wrote:
> On Fri, Jul 09, 2021 at 11:25:37AM -0500, Mike Christie wrote:
>> Hi,
>>
>> The goal of this email is to try and figure how we want
On 9/13/21 9:14 AM, Joerg Roedel wrote:
> On Mon, Sep 13, 2021 at 09:02:38AM -0700, Dave Hansen wrote:
>> On 9/13/21 8:55 AM, Joerg Roedel wrote:
>>> This does not work under SEV-ES, because the hypervisor has no access
>>> to the vCPU registers and can't make modifications to them. So an
>>>
On Mon, Sep 13, 2021 at 07:49:07AM -0700, Guenter Roeck wrote:
> On Mon, Jul 26, 2021 at 10:21:45AM +0530, Viresh Kumar wrote:
> > Bind the virtio devices with their of_node. This will help users of the
> > virtio devices to mention their dependencies on the device in the DT
> > itself. Like GPIO
On Mon, Sep 13, 2021 at 09:02:38AM -0700, Dave Hansen wrote:
> On 9/13/21 8:55 AM, Joerg Roedel wrote:
> > This does not work under SEV-ES, because the hypervisor has no access
> > to the vCPU registers and can't make modifications to them. So an
> > SEV-ES guest needs to reset the vCPU itself and
On 9/13/21 8:55 AM, Joerg Roedel wrote:
> This does not work under SEV-ES, because the hypervisor has no access
> to the vCPU registers and can't make modifications to them. So an
> SEV-ES guest needs to reset the vCPU itself and park it using the
> AP-reset-hold protocol. Upon wakeup the guest
From: Joerg Roedel
When the AP Jump Table blob is installed the kernel can hand over the
APs from the old to the new kernel. Enable kexec when the AP Jump
Table blob has been installed.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/sev.h | 2 ++
From: Joerg Roedel
Move the code for MMIO handling in the #VC handler to sev-shared.c so
that it can be used in the decompressor code. The decompressor needs
to handle MMIO events for writing to the VGA framebuffer.
When the kernel is booted via UEFI the VGA console is not enabled that
early,
From: Joerg Roedel
To support kexec under SEV-ES the APs can't be parked with HLT. Upon
wakeup the AP needs to find its way to execute at the reset vector set
by the new kernel and in real-mode.
This is what the AP Jump Table blob provides, so stop the APs the
SEV-ES way by calling the
From: Joerg Roedel
Handle CLFLUSH instruction to MMIO memory in the #VC handler. The
instruction is ignored by the handler, as the Hypervisor is
responsible for cache management of emulated MMIO memory.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev-shared.c | 9 +
1 file
From: Joerg Roedel
The AP Jump Table under SEV-ES contains the reset vector where non-boot
CPUs start executing when coming out of reset. This means that a CPU
coming out of the AP-reset-hold VMGEXIT also needs to start executing at
the reset vector stored in the AP Jump Table.
The problem is
From: Joerg Roedel
GHCB protocol version 2 adds the MSR-based AP-reset-hold VMGEXIT which
does not need a GHCB. Use that to park APs in 16-bit protected mode on
the AP Jump Table.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/realmode.h| 3 +
arch/x86/kernel/sev.c |
From: Joerg Roedel
Save the results of the GHCB protocol negotiation into a data structure
and print information about versions supported and used to the kernel
log.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 2 +-
arch/x86/kernel/sev-shared.c | 22
From: Joerg Roedel
Check whether the hypervisor supports GHCB version 2 and use it if
available.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 10 --
arch/x86/include/asm/sev.h | 4 ++--
arch/x86/kernel/sev-shared.c | 17 ++---
3 files changed, 24
From: Joerg Roedel
Store the physical address of the AP Jump Table in kernel memory so
that it does not need to be fetched from the Hypervisor again.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff
From: Joerg Roedel
Hi,
here are changes to enable kexec/kdump in SEV-ES guests. The biggest
problem for supporting kexec/kdump under SEV-ES is to find a way to
hand the non-boot CPUs (APs) from one kernel to another.
Without SEV-ES the first kernel parks the CPUs in a HLT loop until
they get
From: Joerg Roedel
Allow a runtime opt-out of kexec support for architecture code in case
the kernel is running in an environment where kexec is not properly
supported yet.
This will be used on x86 when the kernel is running as an SEV-ES
guest. SEV-ES guests need special handling for kexec to
From: Joerg Roedel
Introduce the sev_get_ghcb_proto_ver() which will return the negotiated
GHCB protocol version and use it to set the version field in the GHCB.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 5 +
arch/x86/kernel/sev-shared.c | 5 -
From: Joerg Roedel
For now, kexec is not supported when running as an SEV-ES guest. Doing
so requires additional hypervisor support and special code to hand
over the CPUs to the new kernel in a safe way.
Until this is implemented, do not support kexec in SEV-ES guests.
Cc:
On Mon, Jul 26, 2021 at 10:21:45AM +0530, Viresh Kumar wrote:
> Bind the virtio devices with their of_node. This will help users of the
> virtio devices to mention their dependencies on the device in the DT
> itself. Like GPIO pin users can use the phandle of the device node, or
> the node may
Sorry about HTML (From phone)..
On Mon, 13 Sep 2021, 16:17 Michael S. Tsirkin, wrote:
> A recent change checking of_device_is_compatible on probe broke some
> powerpc/pseries setups. Apparently there virtio devices do not have a
> "compatible" property - they are matched by PCI vendor/device
On Mon, Sep 13, 2021 at 01:53:45PM +0800, Jason Wang wrote:
> If an untrusted device neogitates BLK_F_MQ but advertises a zero
> num_queues, the driver may end up trying to allocating zero size
> buffers where ZERO_SIZE_PTR is returned which may pass the checking
> against the NULL. This will lead
A recent change checking of_device_is_compatible on probe broke some
powerpc/pseries setups. Apparently there virtio devices do not have a
"compatible" property - they are matched by PCI vendor/device ids.
Let's just skip of_node setup but proceed with initialization like we
did previously.
On 13/09/2021 19:45, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 07:19:17PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 26/07/2021 14:51, Viresh Kumar wrote:
>>> Bind the virtio devices with their of_node. This will help users of the
>>> virtio devices to mention their dependencies
On Mon, Sep 13, 2021 at 07:19:17PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 26/07/2021 14:51, Viresh Kumar wrote:
> > Bind the virtio devices with their of_node. This will help users of the
> > virtio devices to mention their dependencies on the device in the DT
> > itself. Like GPIO pin
On 26/07/2021 14:51, Viresh Kumar wrote:
> Bind the virtio devices with their of_node. This will help users of the
> virtio devices to mention their dependencies on the device in the DT
> itself. Like GPIO pin users can use the phandle of the device node, or
> the node may contain more subnodes
On Mon, Sep 13, 2021 at 01:53:45PM +0800, Jason Wang wrote:
If an untrusted device neogitates BLK_F_MQ but advertises a zero
num_queues, the driver may end up trying to allocating zero size
buffers where ZERO_SIZE_PTR is returned which may pass the checking
against the NULL. This will lead
On Mon, Sep 13, 2021 at 3:02 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:45:38PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:41 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 02:36:54PM +0800, Jason Wang wrote:
> > > > On Mon, Sep 13, 2021 at 2:33 PM
On Mon, Sep 13, 2021 at 3:01 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:43:08PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:37 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> > > > On Mon, Sep 13, 2021 at 2:28 PM
On Mon, Sep 13, 2021 at 2:57 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:40:09PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:36 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 01:53:53PM +0800, Jason Wang wrote:
> > > > This patch validate the used
On Mon, Sep 13, 2021 at 2:50 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:37:42AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> > > On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Mon, Sep 13,
On Mon, Sep 13, 2021 at 02:45:38PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:41 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 02:36:54PM +0800, Jason Wang wrote:
> > > On Mon, Sep 13, 2021 at 2:33 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Mon, Sep 13, 2021
On Mon, Sep 13, 2021 at 02:43:08PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:37 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> > > On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Mon, Sep 13, 2021
On Mon, Sep 13, 2021 at 02:40:09PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:36 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 01:53:53PM +0800, Jason Wang wrote:
> > > This patch validate the used buffer length provided by the device
> > > before trying to use it. This
Hi Alexander,
On 12/09/2021 19:05, Alexander Potapenko wrote:
> Hi Laurent,
>
> Do you by any chance have an update on this?
I'm sorry I didn't have the time until now.
I try today.
Could you give more details how to reproduce this?
(kernel version, .config, tools to run?)
Thanks,
Laurent
>
On Mon, Sep 13, 2021 at 02:37:42AM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 02:08:02PM +0800, Jason Wang wrote:
> > > > On Mon, Sep 13, 2021 at
On Mon, Sep 13, 2021 at 2:41 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:36:54PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:33 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 01:53:51PM +0800, Jason Wang wrote:
> > > > This patch tries to make sure
On Mon, Sep 13, 2021 at 2:37 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 02:08:02PM +0800, Jason Wang wrote:
> > > > On Mon, Sep 13, 2021 at 2:04 PM
On Mon, Sep 13, 2021 at 02:36:54PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:33 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 01:53:51PM +0800, Jason Wang wrote:
> > > This patch tries to make sure the virtio interrupt handler for INTX
> > > won't be called after a reset
On Mon, Sep 13, 2021 at 2:36 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 01:53:53PM +0800, Jason Wang wrote:
> > This patch validate the used buffer length provided by the device
> > before trying to use it. This is done by record the in buffer length
> > in a new field in desc_state
On Mon, Sep 13, 2021 at 02:34:01PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 02:08:02PM +0800, Jason Wang wrote:
> > > On Mon, Sep 13, 2021 at 2:04 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Mon, Sep 13, 2021
On Mon, Sep 13, 2021 at 2:33 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 01:53:51PM +0800, Jason Wang wrote:
> > This patch tries to make sure the virtio interrupt handler for INTX
> > won't be called after a reset and before virtio_device_ready(). We
> > can't use IRQF_NO_AUTOEN
On Mon, Sep 13, 2021 at 01:53:53PM +0800, Jason Wang wrote:
> This patch validate the used buffer length provided by the device
> before trying to use it. This is done by record the in buffer length
> in a new field in desc_state structure during virtqueue_add(), then we
> can fail the
On Mon, Sep 13, 2021 at 2:28 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 02:08:02PM +0800, Jason Wang wrote:
> > On Mon, Sep 13, 2021 at 2:04 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 01:53:50PM +0800, Jason Wang wrote:
> > > > We used to synchronize pending
On Mon, Sep 13, 2021 at 02:08:02PM +0800, Jason Wang wrote:
> On Mon, Sep 13, 2021 at 2:04 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 01:53:50PM +0800, Jason Wang wrote:
> > > We used to synchronize pending MSI-X irq handlers via
> > > synchronize_irq(), this may not work for
On Mon, Sep 13, 2021 at 2:04 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 01:53:50PM +0800, Jason Wang wrote:
> > We used to synchronize pending MSI-X irq handlers via
> > synchronize_irq(), this may not work for the untrusted device which
> > may keep sending interrupts after reset
On Mon, Sep 13, 2021 at 01:53:50PM +0800, Jason Wang wrote:
> We used to synchronize pending MSI-X irq handlers via
> synchronize_irq(), this may not work for the untrusted device which
> may keep sending interrupts after reset which may lead unexpected
> results. Similarly, we should not enable
71 matches
Mail list logo
