On Tue, Mar 15, 2022 at 9:14 PM Eli Cohen wrote:
>
> Update man page to include information how to configure the max
> virtqueue pairs for a vdpa device when creating one.
>
> Signed-off-by: Eli Cohen
Acked-by: Jason Wang
> ---
> man/man8/vdpa-dev.8 | 6 ++
> 1 file changed, 6
On Wed, Mar 16, 2022 at 12:20:01PM -0700, Randy Dunlap wrote:
> There are a number of drivers that use "module_init(init)" and
> "module_exit(exit)", which are anonymous names and can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give
On Wed, Mar 16, 2022 at 12:20:07PM -0700, Randy Dunlap wrote:
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique
On Thu, Mar 17, 2022 at 3:25 AM Randy Dunlap wrote:
>
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
>
On Thu, Mar 17, 2022 at 3:24 AM Randy Dunlap wrote:
>
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
>
On Wed, 16 Mar 2022 12:20:10 -0700
Randy Dunlap wrote:
> Eliminate anonymous module_init() and module_exit(), which can lead to
> confusion or ambiguity when reading System.map, crashes/oops/bugs,
> or an initcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
On Thu, Mar 17, 2022 at 6:00 AM Si-Wei Liu wrote:
>
>
>
> On 3/16/2022 12:10 AM, Eli Cohen wrote:
> >> From: Si-Wei Liu
> >> Sent: Wednesday, March 16, 2022 8:52 AM
> >> To: Eli Cohen
> >> Cc: m...@redhat.com; jasow...@redhat.com;
> >> virtualization@lists.linux-foundation.org;
On Wed, Mar 16, 2022 at 11:33 PM Suwan Kim wrote:
>
> On Wed, Mar 16, 2022 at 10:02:13AM +0800, Jason Wang wrote:
> > On Tue, Mar 15, 2022 at 10:43 PM Suwan Kim wrote:
> > >
> > > On Tue, Mar 15, 2022 at 04:59:23PM +0800, Jason Wang wrote:
> > > > On Mon, Mar 14, 2022 at 8:33 PM Suwan Kim
> >
On 3/16/2022 12:10 AM, Eli Cohen wrote:
From: Si-Wei Liu
Sent: Wednesday, March 16, 2022 8:52 AM
To: Eli Cohen
Cc: m...@redhat.com; jasow...@redhat.com;
virtualization@lists.linux-foundation.org; epere...@redhat.com;
amore...@redhat.com;
lviv...@redhat.com; sgarz...@redhat.com; Parav
On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
>
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
There are a number of drivers that use "module_init(init)" and
"module_exit(exit)", which are anonymous names and can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.
Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.
Example 1: (System.map)
On Wed, Mar 16, 2022 at 05:36:20PM +0200, Max Gurtovoy wrote:
>
> On 3/16/2022 5:32 PM, Suwan Kim wrote:
> > On Wed, Mar 16, 2022 at 10:02:13AM +0800, Jason Wang wrote:
> > > On Tue, Mar 15, 2022 at 10:43 PM Suwan Kim wrote:
> > > > On Tue, Mar 15, 2022 at 04:59:23PM +0800, Jason Wang wrote:
> >
On Wed, Mar 16, 2022 at 5:06 PM Krzysztof Kozlowski
wrote:
...
> +int driver_set_override(struct device *dev, const char **override,
> + const char *s, size_t len)
> +{
> + const char *new, *old;
> + char *cp;
> + if (!dev || !override || !s)
> +
On Tue, Feb 22, 2022 at 11:18:18PM +, Matthew Wilcox wrote:
> On Tue, Feb 22, 2022 at 07:58:33AM +, David Woodhouse wrote:
> > On Tue, 2022-02-22 at 01:31 -0500, Michael S. Tsirkin wrote:
> > > On Mon, Feb 21, 2022 at 05:18:48PM +, David Woodhouse wrote:
> > > >
> > > > [dwoodhou@i7
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: Stefano Garzarella
[ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ]
virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock`
is not initialized.
Let's initialize it in vdev_info_init().
Signed-off-by: Stefano Garzarella
Link:
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ.
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: Stefano Garzarella
[ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ]
virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock`
is not initialized.
Let's initialize it in vdev_info_init().
Signed-off-by: Stefano Garzarella
Link:
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ.
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
From: Stefano Garzarella
[ Upstream commit 32f1b53fe8f03d962423ba81f8e92af5839814da ]
virtio_test hangs on __vring_new_virtqueue() because `vqs_list_lock`
is not initialized.
Let's initialize it in vdev_info_init().
Signed-off-by: Stefano Garzarella
Link:
From: Si-Wei Liu
[ Upstream commit 30c22f3816ffef8aa21a000e93c4ee1402a6ea65 ]
Per VIRTIO v1.1 specification, section 5.1.3.1 Feature bit requirements:
"VIRTIO_NET_F_MQ Requires VIRTIO_NET_F_CTRL_VQ".
There's assumption in the mlx5_vdpa multiqueue code that MQ must come
together with CTRL_VQ.
From: "Michael S. Tsirkin"
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ]
A common pattern for device reset is currently:
vdev->config->reset(vdev);
.. cleanup ..
reset prevents new interrupts from arriving and waits for interrupt
handlers to finish.
However if - as is common -
On 2022-03-14 22:42, Dmitry Osipenko wrote:
DRM API requires the DRM's driver to be backed with the device that can
be used for generic DMA operations. The VirtIO-GPU device can't perform
DMA operations if it uses PCI transport because PCI device driver creates
a virtual VirtIO-GPU device that
On Tue, Mar 15, 2022 at 10:55:04PM +0900, Suwan Kim wrote:
> On Mon, Mar 14, 2022 at 03:19:01PM +, Stefan Hajnoczi wrote:
> > On Sat, Mar 12, 2022 at 12:28:32AM +0900, Suwan Kim wrote:
> > > This patch supports polling I/O via virtio-blk driver. Polling
> > > feature is enabled based on
On Wed, Mar 16, 2022 at 07:25:07AM +, Krasnov Arseniy Vladimirovich wrote:
This adds two tests: for receive timeout and reading to invalid
buffer provided by user. I forgot to put both patches to main
patchset.
Arseniy Krasnov(2):
af_vsock: SOCK_SEQPACKET receive timeout test
af_vsock:
On Sat, Mar 12, 2022 at 02:28:53PM +0100, Krzysztof Kozlowski wrote:
> Use a helper to set driver_override to reduce amount of duplicated code.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Michael S. Tsirkin
feel free to merge with the rest of the patchset.
> ---
> drivers/vdpa/vdpa.c
On Wed, Mar 16, 2022 at 07:29:28AM +, Krasnov Arseniy Vladimirovich wrote:
Add test where sender sends two message, each with own
data pattern. Reader tries to read first to broken buffer:
it has three pages size, but middle page is unmapped. Then,
reader tries to read second message to
On Wed, Mar 16, 2022 at 07:27:45AM +, Krasnov Arseniy Vladimirovich wrote:
Test for receive timeout check: connection is established,
receiver sets timeout, but sender does nothing. Receiver's
'read()' call must return EAGAIN.
Signed-off-by: Arseniy Krasnov
---
v1 -> v2:
1) Check amount of
On 3/15/2022 2:10 AM, Eli Cohen wrote:
<...snip...>
Say you got a vdpa net device created with 4 data queue pairs and a
control vq. On boot some guest firmware may support just F_CTRL_VQ but
not F_MQ, then the index for the control vq in guest ends up with 2, as
in this case there's only a
43 matches
Mail list logo
