On Wed, Dec 21, 2022 at 04:21:52PM +0800, Jason Wang wrote:
> On Fri, Dec 16, 2022 at 5:53 PM Eugenio Perez Martin
> wrote:
> >
> > On Fri, Dec 16, 2022 at 8:29 AM Jason Wang wrote:
> > >
> > > On Thu, Dec 15, 2022 at 7:32 PM Eugenio Pérez wrote:
> > > >
> > > > Currently iova range is requested
On Tue, Dec 20, 2022 at 06:46:20PM +0200, Alvaro Karsz wrote:
> Hi Nathan,
>
> > This does not appear to be a false positive but what was the intent
> > here? Should the local name variables increase their length or should
> > the buffer length be reduced?
>
> You're right, the local name variabl
On Wed, Dec 21, 2022 at 01:58:11PM +0800, Cindy Lu wrote:
> On Wed, 21 Dec 2022 at 11:23, Jason Wang wrote:
> >
> > On Tue, Dec 20, 2022 at 10:02 PM Cindy Lu wrote:
> > >
> > > The input of vhost_vdpa_iotlb_unmap() was changed in 881ac7d2314f,
> > > But some function was not changed while callin
On Wed, Dec 21, 2022 at 11:23:09AM +0800, Jason Wang wrote:
> On Tue, Dec 20, 2022 at 10:02 PM Cindy Lu wrote:
> >
> > The input of vhost_vdpa_iotlb_unmap() was changed in 881ac7d2314f,
> > But some function was not changed while calling this function.
> > Add this change
> >
> > Cc: sta...@vger.
On Tue, Dec 20, 2022 at 01:49:04PM -0700, Nathan Chancellor wrote:
> On Tue, Dec 20, 2022 at 06:46:20PM +0200, Alvaro Karsz wrote:
> > Hi Nathan,
> >
> > > This does not appear to be a false positive but what was the intent
> > > here? Should the local name variables increase their length or shoul
On Tue, Dec 20, 2022 at 02:17:45PM +0100, Marek Szyprowski wrote:
> On 20.12.2022 11:54, Michael S. Tsirkin wrote:
> > On Tue, Dec 20, 2022 at 06:27:59PM +0800, Xuan Zhuo wrote:
> >> On Tue, 20 Dec 2022 14:51:54 +0530, Naresh Kamboju
> >> wrote:
> >>> The
correct type.
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 73cd5db0d7d5..dc577e8bfa30 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block
] error @@ got int status @@
Make sparse happy by using the correct type.
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 88d8410ecc5e..73cd5db0d7d5
a
I merged v2 already - squashed it in so Fixes isn't necessary.
I dropped Link: as well, probably going overboard for a fixup.
> ---
> Changes in v3:
> - Added a Fixes tag referencing the commit that revealed the warning
> messages (suggested by Bagas Sanjaya and Micha
the call to virtio_has_feature with a stub.
Tested-by: Anders Roxell
Signed-off-by: Michael S. Tsirkin
---
drivers/block/virtio_blk.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 88b3639f8536
On Tue, Dec 20, 2022 at 04:58:26PM +0700, Bagas Sanjaya wrote:
> Michael S. Tsirkin has asked me [1] to post my improv suggestions for
> now-applied virtio documentation [2], so here is the suggestion patch series.
> The original suggestion must be splitted since it contains three
fig.
>
> This option in your config file is indeed not opened.
>
>
> static int virtblk_probe(struct virtio_device *vdev){
> .
> virtblk_update_capacity(vblk, false);
> virtio_device_ready(vdev);
>
> if (virtio_has_feature(vdev, VIRTIO_BLK_F_ZONED))
On Tue, Dec 20, 2022 at 04:12:05PM +0530, Naresh Kamboju wrote:
> On Tue, 20 Dec 2022 at 16:04, Xuan Zhuo wrote:
> >
> > On Tue, 20 Dec 2022 14:51:54 +0530, Naresh Kamboju
> > wrote:
> > > The qemu-x86_64 and qemu-arm64 boot failed with Linux next-20221220 tag.
> > > It is always reproducible wi
On Tue, Dec 20, 2022 at 10:54:17AM +0100, Ricardo Cañuelo wrote:
> Hi Bagas,
>
> Thanks for the review, some comments below:
>
> On 20/12/22 10:12, Bagas Sanjaya wrote:> On Tue, Dec 20, 2022 at 08:37:09AM
> +0100, Ricardo Cañuelo wrote:
> > Describe the steps needed to fix both warnings above. I
On Tue, Dec 20, 2022 at 02:51:54PM +0530, Naresh Kamboju wrote:
> The qemu-x86_64 and qemu-arm64 boot failed with Linux next-20221220 tag.
> It is always reproducible with gcc-11/ gcc-12 and clang tool chains.
>
> Reported-by: Linux Kernel Functional Testing
>
> <6>[0.00] Booting Linux o
On Mon, Dec 19, 2022 at 01:32:22PM +0200, Alvaro Karsz wrote:
> Ok,
>
> > can be patch on top ...
>
> Just to be sure, you mean here to create a new patch adding a comment
> to the kconfig file, not a new version for this patch, right?
yes
___
Virtua
On Mon, Dec 19, 2022 at 12:55:02PM +0200, Alvaro Karsz wrote:
> > could we add a comment explaining this trick please?
> > can be patch on top ...
>
> Add a comment where?
> Do you mean adding a comment in the change log?
Right here in kconfig file where the trick is.
___
On Mon, Dec 19, 2022 at 03:38:11PM +0700, Bagas Sanjaya wrote:
> On 12/19/22 13:20, Michael S. Tsirkin wrote:
> > I think I agree with this comment. This seems minor enough so I applied
> > the patch for now. Bagas would you like to post your suggestion as a patch
> >
.7f4d9dcb760 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21955,6 +21955,10 @@ IFCVF VIRTIO DATA PATH ACCELERATOR
> R: Zhu Lingshan
> F: drivers/vdpa/ifcvf/
>
> +SNET DPU VIRTIO DATA PATH ACCELERATOR
> +R: Alvaro Karsz
> +F: drivers/vdpa/solidrun/
> +
>
On Mon, Dec 19, 2022 at 05:43:55AM -0500, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2022 at 10:35:11AM +0200, Alvaro Karsz wrote:
> > This commit includes:
> > 1) The driver to manage the controlplane over vDPA bus.
> > 2) A HW monitor device to read health values from the
On Mon, Dec 19, 2022 at 10:35:11AM +0200, Alvaro Karsz wrote:
> This commit includes:
> 1) The driver to manage the controlplane over vDPA bus.
> 2) A HW monitor device to read health values from the DPU.
>
> Signed-off-by: Alvaro Karsz
As far as I can tell patches 1,2 are upstream right?
So y
On Mon, Dec 19, 2022 at 12:13:06PM +0200, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for Virtio block devices.
>
> This commit introduces a new ioctl command, VIRTIO_BLK_IOCTL_GET_LIFETIME.
>
> VIRTIO_BLK_IOCTL_GET_LIFETIME ioctl asks for the block device to provide
> lifet
On Tue, Nov 29, 2022 at 11:37:09AM +0800, Jason Wang wrote:
> >
> >
> > Quite a lot of core work here. Jason are you still looking into
> > hardening?
>
> Yes, last time we've discussed a solution that depends on the first
> kick to enable the interrupt handler. But after some thought, it seems
>
On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
>
> This commit introduces a new ioctl command, VBLK_LIFETIME.
>
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIR
On Thu, Dec 01, 2022 at 05:01:58PM +0800, Jason Wang wrote:
> On Wed, Nov 23, 2022 at 6:24 PM Andrey Smetanin
> wrote:
> >
> > Fix possible virtqueue used buffers leak and corresponding stuck
> > in case of temporary -EIO from sendmsg() which is produced by
> > tun driver while backend device is n
On Mon, Dec 05, 2022 at 04:41:17PM +0800, Xie Yongji wrote:
> Export irq_create_affinity_masks() so that some modules
> can make use of it to implement interrupt affinity
> spreading mechanism.
>
> Signed-off-by: Xie Yongji
So this got nacked, what's the plan now?
> ---
> kernel/irq/affinity.c
On Fri, Oct 28, 2022 at 04:23:49PM -0700, Si-Wei Liu wrote:
> I can post a v3 that shows the code, it shouldn't be
> too hard.
I take it another version of this patchset is planned?
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-fou
On Mon, Nov 07, 2022 at 03:43:54PM +0800, Jason Wang wrote:
> On Wed, Oct 26, 2022 at 11:09 PM wrote:
> >
> > From: Sebastien Boeuf
> >
> > Implement resume operation for vdpa_sim devices, so vhost-vdpa will
> > offer that backend feature and userspace can effectively resume the
> > device.
> >
>
On Tue, Oct 11, 2022 at 10:46:43AM +0200, Ricardo Cañuelo wrote:
> >> +It's at this stage that the virtqueues will be allocated and configured
> >> +by calling the appropriate ``virtio_find`` helper function, such as
> >> +virtio_find_single_vq() or virtio_find_vqs(), which will end up
> >> +callin
On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote:
> On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote:
> > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enable
On Thu, Dec 15, 2022 at 09:47:57AM +0100, Stefano Garzarella wrote:
> On Thu, Dec 15, 2022 at 04:36:44AM +, Bobby Eshleman wrote:
> > This commit changes virtio/vsock to use sk_buff instead of
> > virtio_vsock_pkt. Beyond better conforming to other net code, using
> > sk_buff allows vsock to us
On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote:
> Commit a7766ef18b33("virtio_net: disable cb aggressively") enables
> virtqueue callback via the following statement:
>
> do {
>..
> } while (use_napi && kick &&
>unlikely(!virtqueue_enable_c
On Wed, Dec 14, 2022 at 11:20:34AM +0100, Wolfram Sang wrote:
> Hi Viresh,
>
> > I understand that it is okay to pass the maintainership, within the
> > company, for platform specific parts from one person to another, since
> > they have the best knowledge of the code and are the only one
> > inte
On Wed, Dec 14, 2022 at 04:26:42PM +0530, Viresh Kumar wrote:
> On 14-12-22, 11:20, Wolfram Sang wrote:
> > Dunno if this is really a rule, but if a maintainer steps out and makes
> > sure there is someone to pick up the work, this is more than welcome.
> > Way better than a stale entry in the MAIN
On Wed, Dec 14, 2022 at 01:36:31PM +0800, Conghui wrote:
> This updates the maintainer for virtio i2c drvier
I got that, but what is going on here exactly?
I generally expect a new maintainer to be active in the
project for a while first.
I don't see contributions or reviews for this driver or
for
Yes it's all going into the next pull, thanks!
On Tue, Dec 13, 2022 at 07:33:08AM +, Eli Cohen wrote:
> Michael?
>
> > -Original Message-
> > From: Eli Cohen
> > Sent: Thursday, 24 November 2022 8:34
> > To: m...@redhat.com; jasow...@redhat.com; linux-ker...@vger.kernel.org;
> > virtu
On Tue, Dec 13, 2022 at 03:12:23PM +0800, Jason Wang wrote:
> On Wed, Sep 7, 2022 at 4:11 PM Eli Cohen wrote:
> >
> > > From: Jason Wang
> > > Sent: Wednesday, 7 September 2022 9:53
> > > To: Eli Cohen
> > > Cc: m...@redhat.com; virtualization@lists.linux-foundation.org; linux-
> > > ker...@vger
On Tue, Dec 13, 2022 at 02:57:54PM +0800, Jason Wang wrote:
> On Tue, Dec 13, 2022 at 2:38 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Dec 13, 2022 at 11:43:36AM +0800, Jason Wang wrote:
> > > On Tue, Dec 13, 2022 at 11:38 AM Xuan Zhuo
> > > wrote:
> > &
On Tue, Dec 13, 2022 at 11:22:32AM +0100, Stefano Garzarella wrote:
> > + if (len <= GOOD_COPY_LEN && !skb_queue_empty_lockless(&vvs->rx_queue)) {
>
> Same here.
>
> If there are no major changes to be made, I think the next version is the
> final ones, though we are now in the merge window, so
On Tue, Dec 13, 2022 at 11:43:36AM +0800, Jason Wang wrote:
> On Tue, Dec 13, 2022 at 11:38 AM Xuan Zhuo wrote:
> >
> > On Mon, 12 Dec 2022 04:25:22 -0500, "Michael S. Tsirkin"
> > wrote:
> > > On Mon, Dec 12, 2022 at 05:10:29PM +0800, Jason Wang wrote:
On Tue, Dec 13, 2022 at 04:58:47AM +, Chaitanya Kulkarni wrote:
> Michael,
>
> On 12/7/22 12:28, Michael S. Tsirkin wrote:
> > On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> >> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
&
On Mon, Dec 12, 2022 at 05:10:29PM +0800, Jason Wang wrote:
> Commit a7766ef18b33("virtio_net: disable cb aggressively") enables
> virtqueue callback via the following statement:
>
> do {
>..
> } while (use_napi && kick &&
>unlikely(!virtqueue_enable_c
On Thu, Dec 08, 2022 at 04:02:52PM +0800, Jason Wang wrote:
> On Wed, Dec 7, 2022 at 1:12 PM Si-Wei Liu wrote:
> >
> >
> >
> > On 12/5/2022 7:14 PM, Jason Wang wrote:
> > > On Tue, Dec 6, 2022 at 9:43 AM Si-Wei Liu wrote:
> > >>
> > >>
> > >> On 12/4/2022 10:46 PM, Jason Wang wrote:
> > >>> On Th
On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> > Christoph you acked the spec patch adding this to virtio blk:
> >
> > Still not a fan of the encoding, but at least it i
On Wed, Dec 07, 2022 at 04:46:31PM +0300, Daniil Tatianin wrote:
> The if statement would erroneously check for > ULONG_MAX, which could
> never evaluate to true. Check for equality instead.
>
> Found by Linux Verification Center (linuxtesting.org) with the SVACE
> static analysis tool.
>
> Signe
On Wed, Dec 07, 2022 at 05:09:42AM +0100, Gupta, Pankaj wrote:
> +Cc [MST, virtualization-list]
>
> Hi Dan, MST,
>
> > This patch is reviewed and tested. Is there anything that needs to be
> > done from my side (e.g. sync with mainline)?
>
> If there are no further comments, Can we please merge
On Tue, Dec 06, 2022 at 11:35:31PM -0800, Christoph Hellwig wrote:
> This just seems like a horrible interface. And virtio-blk should be
> a simple passthrough and not grow tons of side-band crap like this.
>
> If you want to pass through random misc information use virtio-scsi
> or nvme with sha
64KB, g2h
> Before: 21.63 Gb/s
> After: 25.59 Gb/s (+18%)
>
> Test: 16B, g2h
> Before: 11.86 Mb/s
> After: 17.41 Mb/s (+46%)
>
> Test: 64KB, h2g
> Before: 2.15 Gb/s
> After: 3.6 Gb/s (+67%)
>
> Test: 16B, h2g
> Before: 14.38 Mb/s
> After: 18.43 Mb/s
On Tue, Dec 06, 2022 at 11:31:44AM -0500, Stefan Hajnoczi wrote:
> On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
>
> I don't like that the ioctl lifetime struct is passed through
> little-endian from the device to userspace. The point of this new ioctl
> is not to be a passthrough
On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
> On 12/5/22 11:36 AM, Alvaro Karsz wrote:
> > Hi,
> >
> >> Is this based on some spec? Because it looks pretty odd to me. There
> >> can be a pretty wide range of two/three/etc level cells with wildly
> >> different ranges of durability.
On Mon, Dec 05, 2022 at 05:30:34AM +, Chaitanya Kulkarni wrote:
> On 12/4/22 00:19, Alvaro Karsz wrote:
> > So, we could create a block-general lifetime ioctl with many reserved
> > bytes, or create a virtio block specific ioctl without reserved bytes
> > at all.
> > I think that we should keep
On Sun, Dec 04, 2022 at 04:37:28PM +0200, Alvaro Karsz wrote:
> > And now is this generic enough to disconnect from virtio and
> > make it a generic blk thing?
>
> It could be generic enough if we drop the virtio structs and pass
> single fields as elements.
> The point is, we can easily make it g
On Sun, Dec 04, 2022 at 02:00:25PM +0200, Alvaro Karsz wrote:
> > I don't see the connection. virtio would often pass through lifetime
> > info from the host. If other devices gain more info then it will make
> > sense to add that to virtio, too.
>
> > Depends. If we expect more types, then I thin
On Sun, Dec 04, 2022 at 10:19:38AM +0200, Alvaro Karsz wrote:
> So, we could create a block-general lifetime ioctl with many reserved
> bytes, or create a virtio block specific ioctl without reserved bytes
> at all.
I don't see the connection. virtio would often pass through lifetime
info from th
r Windows guests.
>
> Signed-off-by: Andrew Melnychenko
Acked-by: Michael S. Tsirkin
> ---
> include/uapi/linux/virtio_net.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index 6cb842ea8
On Thu, Dec 01, 2022 at 11:56:38PM +0200, Andrew Melnychenko wrote:
> Added new offloads for TUN devices TUN_F_USO4 and TUN_F_USO6.
> Technically they enable NETIF_F_GSO_UDP_L4
> (and only if USO4 & USO6 are set simultaneously).
> It allows the transmission of large UDP packets.
>
> UDP Segmentati
On Tue, Nov 29, 2022 at 08:07:45AM +, Eli Cohen wrote:
> Hi,
>
>
>
> This commit:
>
> commit 73bd56abe1709352ab123952c96cc3255d0cbeff
> Author: Michael S. Tsirkin m...@redhat.com
>
> Date: Mon Jan 10 00:47:51 2022 -0500
>
>
>
>
On Tue, Nov 29, 2022 at 04:28:54AM +, Chaitanya Kulkarni wrote:
> On 11/28/22 11:07, Stefan Hajnoczi wrote:
> > On Fri, Nov 25, 2022 at 12:09:45AM +0200, Alvaro Karsz wrote:
> >>> I suggest defining a separate UAPI struct for this ioctl.
> >>
> >> Sounds fine to me.
> >> I could use the followi
On Fri, Nov 25, 2022 at 12:09:45AM +0200, Alvaro Karsz wrote:
> > I suggest defining a separate UAPI struct for this ioctl.
>
> Sounds fine to me.
> I could use the following struct
>
> struct virtio_blk_lifetime_ioctl {
> u16 pre_eol_info;
> u16 device_lifetime_est_typ_a;
>
On Mon, Nov 28, 2022 at 09:20:21PM +0800, Longpeng (Mike, Cloud Infrastructure
Service Product Dept.) wrote:
>
>
> 在 2022/11/28 20:20, Michael S. Tsirkin 写道:
> > On Mon, Nov 28, 2022 at 07:59:33PM +0800, Longpeng (Mike, Cloud
> > Infrastructure Service
ote:
> > > > Add a limit to 'config->vq_num' which is user controlled data which
> > > > comes from an vduse_ioctl to prevent large memory allocations.
> > > >
> > > > This is found using static analysis with smatch.
> > >
On Mon, Nov 28, 2022 at 07:59:33PM +0800, Longpeng (Mike, Cloud Infrastructure
Service Product Dept.) wrote:
>
>
> 在 2022/11/28 18:19, Michael S. Tsirkin 写道:
> > On Mon, Nov 28, 2022 at 04:19:30PM +0800, Longpeng (Mike, Cloud
> > Infrastructure Service
On Mon, Nov 28, 2022 at 04:19:30PM +0800, Longpeng (Mike, Cloud Infrastructure
Service Product Dept.) wrote:
>
>
> 在 2022/11/28 12:05, Jason Wang 写道:
> > On Mon, Nov 28, 2022 at 10:56 AM Longpeng(Mike)
> > wrote:
> > >
> > > From: Longpeng
> > >
> > > Support doorbell mapping for vdpasim de
On Mon, Nov 28, 2022 at 10:10:01AM +0800, Li Zetao wrote:
> This patchset fixes similar issue, the root cause of the
> problem is that the virtqueues are not stopped on error
> handling path.
I've been thinking about this.
Almost all drivers are affected.
The reason really is that it used to be t
On Mon, Nov 28, 2022 at 10:10:04AM +0800, Li Zetao wrote:
> When doing the following test steps, an error was found:
> step 1: modprobe virtio_input succeeded
> # modprobe virtio_input <-- OK
>
> step 2: fault injection in input_allocate_device()
> # modprobe -r virtio_input <--
On Sun, Nov 27, 2022 at 08:16:24AM +0530, Harshit Mogalapalli wrote:
> Hi Micheal,
>
> On 27/11/22 4:52 am, Michael S. Tsirkin wrote:
> > On Fri, Nov 25, 2022 at 07:59:58PM -0800, Harshit Mogalapalli wrote:
> > > As 'dev->vq_num' is user-controlled data, i
On Fri, Nov 25, 2022 at 07:59:58PM -0800, Harshit Mogalapalli wrote:
> As 'dev->vq_num' is user-controlled data, if user tries to allocate
> memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it
> creates a stack trace and messes up dmesg with a warning.
>
> Call trace:
> -> vduse_ioctl
>
On Wed, Nov 23, 2022 at 10:22:26PM +, Chaitanya Kulkarni wrote:
>
> > +/* Get lifetime information from device */
> > +static int virtblk_ioctl_lifetime(struct virtio_blk *vblk, unsigned long
> > arg)
> > +{
> > + struct request_queue *q = vblk->disk->queue;
> > + struct request *req = NU
On Wed, Nov 23, 2022 at 10:41:46PM +, Chaitanya Kulkarni wrote:
>
> > +/* Get lifetime information from device */
> > +static int virtblk_ioctl_lifetime(struct virtio_blk *vblk, unsigned long
> > arg)
> > +{
> > + struct request_queue *q = vblk->disk->queue;
> > + struct request *req = NU
On Wed, Nov 23, 2022 at 11:32:27PM +0800, Dawei Li wrote:
> This commit includes changes below:
>
> 1 Since register_virtio_driver doesn't force probe & remove
> to be mandatory callback, so it's caller's job to make the
> sanity check before invocation.
What's the point of these checks? I do
vice on error handling path. This
> makes error handling follow the same order as normal device
> cleanup in virtnet_remove() which does: unregister, destroy
> failover, then reset. And that flow is better tested than
> error handling so we can be reasonably sure it works well.
>
, then reset - and that flow
is better tested than error handling so we can be reasonably
sure it works well.
-
I would thus probably also include this tag instead:
Fixes: 024650 ("virtio_net: fix use after free on allocation failure")
this is what introduced the difference i
On Sat, Nov 12, 2022 at 05:19:42PM +0100, Dmitry Vyukov wrote:
> I am looking for a test module that allows
> to create a transient virtio device that can be used to activate a virtio
> driver are communicate with it as if from the host.
> Does such thing exist already?
> Or how are virtio transpor
On Mon, Nov 14, 2022 at 06:44:30AM +, Eli Cohen wrote:
> > From: Jason Wang
> > Sent: Monday, 14 November 2022 6:39
> > To: Eli Cohen
> > Cc: m...@redhat.com; linux-ker...@vger.kernel.org;
> > virtualization@lists.linux-
> > foundation.org; si-wei@oracle.com; epere...@redhat.com;
> > l..
On Sun, Nov 13, 2022 at 01:56:00PM +, Eli Cohen wrote:
> > From: Michael S. Tsirkin
> > Sent: Sunday, 13 November 2022 15:52
> > To: Eli Cohen
> > Cc: jasow...@redhat.com; linux-ker...@vger.kernel.org;
> > virtualization@lists.linux-foundation.org; si
On Sun, Nov 13, 2022 at 03:44:35PM +0200, Eli Cohen wrote:
> This series is a resend of previously sent patch list. It adds a few
> fixes so I treat as a v0 of a new series.
>
> It adds a kernel config param CONFIG_MLX5_VDPA_STEERING_DEBUG that when
> eabled allows to read rx unicast and multicast
xed).
> > -Original Message-
> > From: Angus Chen
> > Sent: Wednesday, September 28, 2022 11:25 AM
> > To: Michael S. Tsirkin
> > Cc: jasow...@redhat.com; pbonz...@redhat.com; ax...@kernel.dk;
> > virtualization@lists.linux-foundation.org; linux-bl...@vge
On Tue, Nov 08, 2022 at 02:53:53PM +0200, Alvaro Karsz wrote:
> Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
>
> This commit introduces a new ioctl command, VBLK_LIFETIME.
>
> VBLK_LIFETIME ioctl asks for the block device to provide lifetime
> information by sending a VIR
On Fri, Nov 11, 2022 at 02:20:01PM +0200, Alvaro Karsz wrote:
> > + /* The virtio_blk_lifetime struct fields follow virtio spec.
> > +* There is no check/decode on values received from the device.
> > +* The data is sent as is to the user.
> > +*/
>
> After more thoug
On Fri, Nov 11, 2022 at 03:17:14PM +0800, Jason Wang wrote:
> On Thu, Nov 10, 2022 at 7:01 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Nov 10, 2022 at 03:58:21PM +0800, Jason Wang wrote:
> > > This patch allows device features to be provisioned via vdpa. This
> > &
On Thu, Nov 10, 2022 at 09:17:22AM -0800, Bobby Eshleman wrote:
> This commit changes virtio/vsock to use sk_buff instead of
> virtio_vsock_pkt. Beyond better conforming to other net code, using
> sk_buff allows vsock to use sk_buff-dependent features in the future
> (such as sockmap) and improves
On Thu, Nov 10, 2022 at 03:58:21PM +0800, Jason Wang wrote:
> This patch allows device features to be provisioned via vdpa. This
> will be useful for preserving migration compatibility between source
> and destination:
>
> # vdpa dev add name dev1 mgmtdev pci/:02:00.0 device_features 0x3000200
On Thu, Nov 10, 2022 at 02:11:11PM +0800, Xianting Tian wrote:
> As the comments of VIRTIO_PCI_VRING_ALIGN shows, we should use
> PAGE_SZIE not the hard code 4096.
>
> Signed-off-by: Xianting Tian
where does it show this?
what is the problem you are trying to solve?
PAGE_SIZE is generally not v
On Thu, Nov 10, 2022 at 03:30:59AM +, Angus Chen wrote:
> Hi Jason.
>
> > -Original Message-
> > From: Jason Wang
> > Sent: Wednesday, November 2, 2022 1:34 PM
> > To: Angus Chen
> > Cc: m...@redhat.com; virtualization@lists.linux-foundation.org;
> > linux-ker...@vger.kernel.org; lin
On Wed, Nov 09, 2022 at 04:42:13PM +0100, Stefano Garzarella wrote:
> Before commit 3d5698793897 ("vhost-vdpa: introduce asid based IOTLB")
> we call vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during the
> release to free all the resources allocated when processing user IOTLB
> messages throu
On Wed, Nov 09, 2022 at 09:18:23AM +0100, Stefano Garzarella wrote:
> On Wed, Nov 09, 2022 at 11:28:41AM +0800, Jason Wang wrote:
> > On Tue, Nov 8, 2022 at 6:34 PM Stefano Garzarella
> > wrote:
> > >
> > > vhost_iotlb_itree_first() requires `start` and `last` parameters
> > > to search for a ma
On Tue, Nov 08, 2022 at 05:13:50PM +0800, Jason Wang wrote:
> On Tue, Nov 8, 2022 at 4:56 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Nov 08, 2022 at 11:09:36AM +0800, Jason Wang wrote:
> > > On Tue, Nov 8, 2022 at 7:06 AM Michael S. Tsirkin wrote:
> > > >
&
On Tue, Nov 08, 2022 at 11:09:36AM +0800, Jason Wang wrote:
> On Tue, Nov 8, 2022 at 7:06 AM Michael S. Tsirkin wrote:
> >
> > On Mon, Nov 07, 2022 at 10:10:06PM +0100, Eric Auger wrote:
> > > Hi Michael,
> > > On 11/7/22 21:42, Michael S. Tsirkin wrote:
> >
On Mon, Nov 07, 2022 at 10:10:06PM +0100, Eric Auger wrote:
> Hi Michael,
> On 11/7/22 21:42, Michael S. Tsirkin wrote:
> > On Mon, Nov 07, 2022 at 09:34:31PM +0100, Eric Auger wrote:
> >> When the vhost iotlb is used along with a guest virtual iommu
> >> and the
On Mon, Nov 07, 2022 at 09:34:31PM +0100, Eric Auger wrote:
> When the vhost iotlb is used along with a guest virtual iommu
> and the guest gets rebooted, some MISS messages may have been
> recorded just before the reboot and spuriously executed by
> the virtual iommu after the reboot. Despite the
On Mon, Oct 24, 2022 at 03:40:32PM +0200, Igor Skalkin wrote:
> According to specification [1], "For the device-specific configuration
> space, the driver MUST use 8 bit wide accesses for 8 bit wide fields,
> 16 bit wide and aligned accesses for 16 bit wide fields and 32 bit wide
> and aligned acce
On Wed, Oct 19, 2022 at 02:11:37PM +0200, Christian Borntraeger wrote:
> 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
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)
>
> [8.532461] [ cut here
On Wed, Oct 19, 2022 at 12:27:46AM +, Angus Chen wrote:
> Hi sasha
>
> > -Original Message-
> > From: Sasha Levin
> > Sent: Tuesday, October 18, 2022 8:12 AM
> > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> > Cc: Angus Chen ; M
On Wed, Oct 19, 2022 at 05:36:17AM +, Eli Cohen wrote:
> > From: Michael S. Tsirkin
> > Sent: Wednesday, 19 October 2022 8:34
> > To: Eli Cohen
> > Cc: Si-Wei Liu ; jasow...@redhat.com; linux-
> > ker...@vger.kernel.org; virtualization@lists.linux-foundation.o
On Wed, Oct 19, 2022 at 05:31:48AM +, Eli Cohen wrote:
> > From: Si-Wei Liu
> > Sent: Tuesday, 18 October 2022 22:21
> > To: Eli Cohen ; m...@redhat.com; jasow...@redhat.com;
> > linux-ker...@vger.kernel.org; virtualization@lists.linux-foundation.org
> > Cc: epere...@redhat.com; l...@redhat.co
On Tue, Oct 18, 2022 at 07:57:57AM +, Boeuf, Sebastien wrote:
> > Not on list:
> >
> > $ b4 mbox cover.1666008238.git.sebastien.bo...@intel.com
> > Looking up
> > https://lore.kernel.org/r/cover.1666008238.git.sebastien.boeuf%40intel.com
> > That message-id is not known.
> > $
> >
> >
> > d
On Mon, Oct 17, 2022 at 02:06:19PM +0200, sebastien.bo...@intel.com wrote:
> From: Sebastien Boeuf
>
> This series introduces a new operation for vdpa devices. It allows them
> to be resumed after they have been suspended. A new feature bit is
> introduced for devices to advertise their ability t
On Mon, Oct 17, 2022 at 11:44:44AM +, Boeuf, Sebastien wrote:
> On Mon, 2022-10-17 at 13:05 +0200, Eugenio Perez Martin wrote:
> > On Mon, Oct 17, 2022 at 10:47 AM Boeuf, Sebastien
> > wrote:
> > >
> > > On Mon, 2022-10-17 at 15:26 +0800, Jason Wang wrote:
> > > > On Fri, Oct 14, 2022 at 7:15
On Mon, Oct 17, 2022 at 05:12:42PM -0700, Si-Wei Liu wrote:
> Hi,
>
> I don't know why but it looks that this series wasn't showing up in the list
> for some reason. Only the recipients in the To or Cc lines seemed able to
> get it. Would it be possible to fix the mail client or include me to the
801 - 900 of 3256 matches
Mail list logo
