The callback sends a resume command to the DPU through
the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed, 22 insertions(+)
diff
> First up to 4k should not be a problem. Even jumbo frames e.g. 9k
> is highly likely to succeed. And a probe time which is often boot
> even 64k isn't a problem ...
>
> Hmm. We could allocate large buffers at probe time. Reuse them and
> copy data over.
>
> IOW reusing GOOD_COPY_LEN flow for
> > > Why the difference?
> > >
> >
> > Because the RING_SIZE < 4 case requires much more adjustments.
> >
> > * We may need to squeeze the virtio header into the headroom.
> > * We may need to squeeze the GSO header into the headroom, or block the
> > features.
>
> We alread do this though no?
> > At the moment, if a network device uses vrings with less than
> > MAX_SKB_FRAGS + 2 entries, the device won't be functional.
> >
> > The following condition vq->num_free >= 2 + MAX_SKB_FRAGS will always
> > evaluate to false, leading to TX timeouts.
> >
> > This patch introduces a new
> > +void virtio_block_feature(struct virtio_device *dev, unsigned int f)
> > +{
> > + BUG_ON(f >= 64);
> > + dev->blocked_features |= (1ULL << f);
> > +}
> > +EXPORT_SYMBOL_GPL(virtio_block_feature);
> > +
>
> Let's add documentation please. Also pls call it __virtio_block_feature
>
> > This patchset follows a discussion in the mailing list [1].
> >
> > This fixes only part of the bug, rings with less than 4 entries won't
> > work.
>
> Why the difference?
>
Because the RING_SIZE < 4 case requires much more adjustments.
* We may need to squeeze the virtio header into the
Stop ethtool from resizing a TX/RX ring to size less than
MAX_SKB_FRAGS + 2, if the ring was initialized with a bigger size.
We cannot convert a "normal" ring to a "small" ring in runtime.
Signed-off-by: Alvaro Karsz
---
drivers/net/virtio_net.c | 12
1 file ch
U size in small vring cases to be up to the
default one, 1500B.
Signed-off-by: Alvaro Karsz
---
drivers/net/virtio_net.c | 149 +--
1 file changed, 144 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8d803
-by: Alvaro Karsz
---
drivers/virtio/virtio.c | 73 ++---
include/linux/virtio.h | 3 ++
2 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 3893dc29eb2..eaad5b6a7a9 100644
--- a/drivers/virtio
to test XDP with my setup, maybe you can help with
that?
[1]
https://lore.kernel.org/lkml/20230416074607.292616-1-alvaro.ka...@solid-run.com/
Alvaro Karsz (3):
virtio: re-negotiate features if probe fails and features are blocked
virtio-net: allow usage of vrings smaller than MAX_SKB_FRAGS + 2
> > In the virtnet case, we'll decide which features to block based on the ring
> > size.
> > 2 < ring < MAX_FRAGS + 2 -> BLOCK GRO + MRG_RXBUF
> > ring < 2 -> BLOCK GRO + MRG_RXBUF + CTRL_VQ
>
> why MRG_RXBUF? what does it matter?
>
You're right, it should be blocked only when ring < 2.
Or
> > So, let's add some funky flags in virtio device to block out
> > features, have core compare these before and after,
> > detect change, reset and retry?
>
> In the virtnet case, we'll decide which features to block based on the ring
> size.
> 2 < ring < MAX_FRAGS + 2 -> BLOCK GRO +
> So, let's add some funky flags in virtio device to block out
> features, have core compare these before and after,
> detect change, reset and retry?
In the virtnet case, we'll decide which features to block based on the ring
size.
2 < ring < MAX_FRAGS + 2 -> BLOCK GRO + MRG_RXBUF
ring < 2 ->
> > > The rest of stuff can probably just be moved to after find_vqs without
> > > much pain.
> > >
> > Actually, I think that with a little bit of pain :)
> > If we use small vrings and a GRO feature bit is set, Linux will need to
> > allocate 64KB of continuous memory for every receive
We could add a new virtio_config_ops: peek_vqs.
We can call it during virtnet_validate, and then fixup the features in case of
small vrings.
If peek_vqs is not implemented by the transport, we can just fail probe later
in case of small vrings.
___
> Hmm. I was wrong. There is no way to disable CVQ feature bit.
>
> 1. Reset the device.
> 2. Set the ACKNOWLEDGE status bit: the guest OS has notice the device.
> 3. Set the DRIVER status bit: the guest OS knows how to drive the device.
> 4. Read device feature bits, and write the subset of
> Yes that makes sense, it's architetural. We can disable ctrl vq though.
The problem here is that we know the vring size after calling virtnet_find_vqs,
so the number of VQs already includes the control VQ.
Actually, many variables/settings that are initialized before we call
virtnet_find_vqs
> > Signed-off-by: Alvaro Karsz
>
> Acked-by: Jason Wang
>
Thanks Jason.
BTW, Michael, I see that you merged the first version into the mst tree.
___
Virtualization mailing list
Virtualization@lists.linux-found
> > I see your point.
> > Regardless, we'll need to fail probe in some cases.
> > ring size of 1 for example (if I'm not mistaken)
>
> Hmm. We can make it work if we increase hard header size, then
> there will always be room for vnet header.
>
> > control vq even needs a bigger ring.
>
> Why
> > So, what do you think, we should fix virtio-net to work with smaller rings?
> > we should fail probe?
> >
> > I think that since this never came up until now, there is no big demand to
> > such small rings.
>
> The worry is that once we start failing probe there's just a tiny chance
> hosts
Implement the kick_vq_with_data vDPA callback.
On kick, we pass the next available data to the DPU by writing it in
the kick offset.
Signed-off-by: Alvaro Karsz
---
Should be applied on top of:
https://lore.kernel.org/virtualization/20230413081855.36643-1-alvaro.ka...@solid-run.com/
drivers
> > > > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > > > and things will work, no?
> > > >
> > > > I think that this is not so simple, if I understand correctly, by
> > > > disabling NETIF_F_SG we will never receive a chained skbs to transmit,
> > > > but we still
> Why tx timeout without frags?
Please see my response to Michael.
> > * Guest GSO/big MTU (without VIRTIO_NET_F_MRG_RXBUF?), we can't chain page
> > size buffers anymore.
>
>
> Or, we disable the GUEST_GSO, HOST_GSO..
>
And disable VIRTIO_NET_F_MTU, quoting the spec:
"A driver SHOULD
> > > Actually, I think that all you need to do is disable NETIF_F_SG,
> > > and things will work, no?
> >
> > I think that this is not so simple, if I understand correctly, by disabling
> > NETIF_F_SG we will never receive a chained skbs to transmit, but we still
> > have more functionality to
> > Check vring size and fail probe if a transmit/receive vring size is
> > smaller than MAX_SKB_FRAGS + 2.
> >
> > At the moment, any vring size is accepted. This is problematic because
> > it may result in attempting to transmit a packet with more fragments
> > than there are descriptors in the
> > +static int virtnet_validate_vqs(struct virtnet_info *vi)
> > +{
> > + u32 i, min_size = roundup_pow_of_two(MAX_SKB_FRAGS + 2);
>
> why power of two?
The ring size is always a power of 2, so checking against MAX_SKB_FRAGS + 2 or
against roundup_pow_of_two will result in the same, and I
> Actually, I think that all you need to do is disable NETIF_F_SG,
> and things will work, no?
I think that this is not so simple, if I understand correctly, by disabling
NETIF_F_SG we will never receive a chained skbs to transmit, but we still have
more functionality to address, for example:
*
After further consideration, other virtio drivers need a minimum limit to the
vring size too.
Maybe this can be more general, for example a new virtio_driver callback that
is called (if implemented) during virtio_dev_probe, before drv->probe.
What do you think?
Thanks,
Alvaro
, it leads to an immediate bug:
The condition: (sq->vq->num_free >= 2 + MAX_SKB_FRAGS) in
virtnet_poll_cleantx and virtnet_poll_tx always evaluates to false,
so netif_tx_wake_queue is not called, leading to TX timeouts.
Signed-off-by: Alvaro Karsz
---
drivers/net/virtio_n
Hi Bobby,
> /* The feature bitmap for virtio vsock */
> #define VIRTIO_VSOCK_F_SEQPACKET 1 /* SOCK_SEQPACKET supported */
> +#define VIRTIO_VSOCK_F_DGRAM 2 /* Host support dgram vsock */
Seems that bit 2 is already taken by VIRTIO_VSOCK_F_NO_IMPLIED_STREAM.
support to the vDPA transport.
[1] https://lore.kernel.org/lkml/20230324195029.2410503-1-vik...@daynix.com/
[2]
https://lore.kernel.org/virtualization/20230409070706.3288876-1-alvaro.ka...@solid-run.com/
Alvaro Karsz (1):
virtio-vdpa: add VIRTIO_F_NOTIFICATION_DATA feature support
Viktor
.
Signed-off-by: Alvaro Karsz
---
drivers/virtio/virtio_vdpa.c | 23 +--
include/linux/vdpa.h | 9 +
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index d7f5af62dda..737c1f36d32 100644
From: Viktor Prutyanov
According to VirtIO spec v1.2, VIRTIO_F_NOTIFICATION_DATA feature
indicates that the driver passes extra data along with the queue
notifications.
In a split queue case, the extra data is 16-bit available index. In a
packed queue case, the extra data is 1-bit wrap counter
> Hmm. So it seems we need to first apply yours then this patch,
> is that right? Or the other way around? What is the right way to make it not
> break bisect?
> Do you mind including this patch with yours in a patchset
> in the correct order?
Ok, I'll create a patchset.
Thanks,
When suspend is called, the driver sends a suspend command to the DPU
through the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed
.
The mechanism can be used if the negotiated config version is 2 or
higher.
If the new mechanism is used when the config version is 1, it will call
snet_send_ctrl_msg_old, which is config 1 compatible.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun
access to control registers -
Patch 1.
v4:
- Rename struct snet_vq -> struct vdpa_vq_state from
inital_state to vq_state - Patch 1.
Alvaro Karsz (2):
vdpa/snet: support getting and setting VQ state
vdpa/snet: support the suspend vDPA callback
drivers/vdpa/solid
> While at this, how about implement resume as well?
I do intend to implement resume, but I'm not sure it will happen soon enough.
I could in the mean time add the vDPA part, which is identical to suspend, but
with a different opcode.
The DPU will return not supported error in the mean time.
> > struct snet_vq {
> > /* VQ callback */
> > struct vdpa_callback cb;
> > + /* VQ initial state */
> > + struct vdpa_vq_state inital_state;
>
>
> I guess you meant "initial_state" really here.
Yes, you're right, I'll fix it.
> Btw, who is used to initialize
When suspend is called, the driver sends a suspend command to the DPU
through the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed
.
The mechanism can be used if the negotiated config version is 2 or
higher.
If the new mechanism is used when the config version is 1, it will call
snet_send_ctrl_msg_old, which is config 1 compatible.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun
/virtualization/20230409091024.3437405-1-alvaro.ka...@solid-run.com/
Changelog:
v2:
- Remove wmb() from snet_ctrl_read_from_dpu - Patch 1.
v3:
- Usage of spinlocks to serialize access to control registers -
Patch 1.
Alvaro Karsz (2):
vdpa/snet: support getting and setting
> > In this case, I can just remove the wmb and that's it, right?
>
> But who or how to prevent the preemption?
We use a mutex to protect the control mechanism (snet->ctrl_lock).
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
- kick callback: most likely that the VQ is ready.
- interrupt handlers: most likely that the callback is not NULL.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_main.c
b
.
The mechanism can be used if the negotiated config version is 2 or
higher.
If the new mechanism is used when the config version is 1, it will call
snet_send_ctrl_msg_old, which is config 1 compatible.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun
When suspend is called, the driver sends a suspend command to the DPU
through the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed
() from snet_ctrl_read_from_dpu - Patch 1.
Alvaro Karsz (2):
vdpa/snet: support getting and setting VQ state
vdpa/snet: support the suspend vDPA callback
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun/snet_ctrl.c | 322 +
drivers/vdpa/solidrun
.
This patch needs to be applied on top of Viktor's patch.
[1] https://lore.kernel.org/lkml/20230324195029.2410503-1-vik...@daynix.com/
Signed-off-by: Alvaro Karsz
---
v2:
- clear the feature bit if kick_vq_with_data is not implemented.
- Fix kick_vq_with_data comment in include
> Hmm so I conclude that drivers without kick_vq_with_data
> should not accept VIRTIO_F_NOTIFICATION_DATA then?
Yes, vDPA drivers without kick_vq_with_data should not offer
VIRTIO_F_NOTIFICATION_DATA in the first place.
We can be more forgiving in such cases and clear the feature bit + print a
> > This function is used by virtio_vdpa as well
> > (drivers/virtio/virtio_vdpa.c:virtio_vdpa_finalize_features).
> > A vDPA device can offer this feature and it will be accepted, even though
> > VIRTIO_F_NOTIFICATION_DATA is not a thing for the vDPA transport at the
> > moment.
> >
> > I
> Statically allocated array of pointed to hwmon_channel_info can be made
> const for safety.
>
> Signed-off-by: Krzysztof Kozlowski
>
Thanks!
Reviewed-by: Alvaro Karsz
___
Virtualization mailing list
Virtualization@lists.linux-found
> > I meant that next_wrap is for packed VQs, but I see your point, it's no
> > clear from the comment.
> > I'll fix it in v2.
>
> next_wrap works for split as well, spec said
>
> "
> Without VIRTIO_F_RING_PACKED this is the most significant bit (bit 15)
> of the available index.
> "
You're
> > So it will arrive to the pci subsystem in program order, but the pci
> > subsystem may reorder, right?
>
> This is not what I read from the above doc. It said "to a particular
> device will arrive in program order".
In this case, I can just remove the wmb and that's it, right?
Thanks
> > + * @kick_vq_with_data: Kick the virtqueue and supply extra data
> > + * (only if VIRTIO_F_NOTIFICATION_DATA is
> > negotiated)
> > + * @vdev: vdpa device
> > + * @data: includes vqn, next_off and
> I'm not sure how a spinlock can help in this case.
> The entire control mechanism is protected by the spinlock snet->ctrl_lock, so
> multiple CPUs won't use it simultaneously.
Sorry, snet->ctrl_lock is a mutex, not a spinlock.
___
Virtualization
Hi Jason,
> > + /* Overwrite the control register with the new buffer size (in 4B
> > words) */
> > + snet_write_ctrl(regs, buf_words);
> > + /* Use a memory barrier, this must be written before the opcode
> > register. */
> > + wmb();
>
>
> At least you need to use
.
The mechanism can be used if the negotiated config version is 2 or
higher.
If the new mechanism is used when the config version is 1, it will call
snet_send_ctrl_msg_old, which is config 1 compatible.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun
When suspend is called, the driver sends a suspend command to the DPU
through the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed
Add more vDPA callbacks.
[s/g]et_vq_state is added in patch 1, including a new control mechanism
to read data from the DPU.
suspend is added in patch 2.
Alvaro Karsz (2):
vdpa/snet: support getting and setting VQ state
vdpa/snet: support the suspend vDPA callback
drivers/vdpa/solidrun
> tagged. in the future pls CC everyone on the cover letter too.
Ok, thanks.
I'm not getting responses, should I resend it?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Hi Viktor,
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 4c3bb0ddeb9b..f9c6604352b4 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -2752,6 +2752,23 @@ void vring_del_virtqueue(struct virtqueue *_vq)
> }
>
...@daynix.com/
Signed-off-by: Alvaro Karsz
---
drivers/virtio/virtio_vdpa.c | 20 ++--
include/linux/vdpa.h | 6 ++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index d7f5af62dda
ping
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
When suspend is called, the driver sends a suspend command to the DPU
through the control mechanism.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_ctrl.c | 6 ++
drivers/vdpa/solidrun/snet_main.c | 15 +++
drivers/vdpa/solidrun/snet_vdpa.h | 1 +
3 files changed
.
The mechanism can be used if the negotiated config version is 2 or
higher.
If the new mechanism is used when the config version is 1, it will call
snet_send_ctrl_msg_old, which is config 1 compatible.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/Makefile | 1 +
drivers/vdpa/solidrun
Add more vDPA callbacks.
[s/g]et_vq_state is added in patch 1, including a new control mechanism
to read data from the DPU.
suspend is added in patch 2.
Alvaro Karsz (2):
vdpa/snet: support getting and setting VQ state
vdpa/snet: support the suspend vDPA callback
drivers/vdpa/solidrun
> Is this too late to be changed?
>
> Thanks
You're right.
What do you suggest, dropping the patch or adding the unified struct without
deleting the existing ones?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Unify virtio_net_ctrl_coal_tx and virtio_net_ctrl_coal_rx structs into a
single struct, virtio_net_ctrl_coal, as they are identical.
This patch follows the VirtIO spec patch:
https://lists.oasis-open.org/archives/virtio-comment/202302/msg00431.html
Signed-off-by: Alvaro Karsz
---
drivers/net
o/vhost-vdpa.h | 3 +
> hw/virtio/vhost-shadow-virtqueue.c | 8 +-
> hw/virtio/vhost-vdpa.c | 128 +--
> hw/virtio/vhost.c | 3 +
> net/vhost-vdpa.c | 198 -
> hw/virtio/trace-events | 1 +
> 7 files changed, 273 insertions(+), 72 deletions(-)
>
> --
The migration works with SolidNET DPU.
Tested-by: Alvaro Karsz
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> +#define VIRTIO_NET_F_GUEST_HDRLEN 59 /* Guest provides the exact hdr_len
> value. */
> #define VIRTIO_NET_F_RSS 60/* Supports RSS RX steering */
> #define VIRTIO_NET_F_RSC_EXT 61/* extended coalescing info */
> #define VIRTIO_NET_F_STANDBY 62/* Act as standby for another device
> --
> 2.39.0
>
This indeed saves some cycles in our device.
Thanks!
Reviewed-by: Alvaro Karsz
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Hi,
Our device offers this feature bit as well.
I don't have concrete numbers, but this feature will save our device a
few cycles for every GSO packet.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Hi,
> The function vhost.c:vhost_dev_stop fetches the vring base so the vq
> state can be migrated to other devices. However, this is unreliable in
> vdpa, since we didn't signal the device to suspend the queues, making
> the value fetched useless.
>
> Suspend the device if possible before
Michael, never mind.
I just saw that you merged the commit with "virtio: vdpa: new SolidNET
DPU driver."
Thanks!
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Ping.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
The flag should be cleared on reset, otherwise, the DPU won't start
again after reset.
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vdpa/solidrun/snet_main.c
b/drivers/vdpa/solidrun/snet_main.c
index 0c13ccde4520
-vdpa,vhostdev=/dev/vhost-vdpa-0,id=hostnet0"
The destination VM with "-netdev
vhost-vdpa,vhostdev=/dev/vhost-vdpa-1,id=hostnet0"
- Boot the source VM, test the network by pinging.
- Migrate
- Test the destination VM network.
Everything worked fine.
Tes
device:
Unknown error 524
Suggested-by: Eugenio Perez Martin
Signed-off-by: Alvaro Karsz
---
v2:
- replace dev_err with dev_warn_once.
drivers/vhost/vdpa.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost
> > dev_warn then?
>
> dev_warn_once is ok.
Ok, thanks
I'll send a new version tomorrow.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
> I'm not sure this is a good idea. Userspace is not supposed to be
> able to trigger dev_err.
dev_warn then?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
device:
Unknown error 524
Suggested-by: Eugenio Perez Martin
Signed-off-by: Alvaro Karsz
---
drivers/vhost/vdpa.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 23db92388393..56287506aa0d 100644
Hi guys,
While trying to upstream the implementation of VIRTIO_BLK_F_LIFETIME
feature, many developers suggested that this feature should be
extended to include more cell types, since its current implementation
in virtio spec is relevant for MMC and UFS devices only.
The VIRTIO_BLK_F_LIFETIME
> Beautiful, nice threading, thanks! :)
Sure, thanks for noticing the indentation issue in the first place :)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
---
drivers/pci/quirks.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 285acc4aacc..809d03272c2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5343,6 +5343,14
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
Acked-by: Jason Wang
---
MAINTAINERS|4 +
drivers/vdpa/Kconfig | 18 +
drivers/vdpa
1.
- Wrap patch comment log to fill 75 columns - Patch 1 + 2.
Alvaro Karsz (3):
PCI: Add SolidRun vendor ID
PCI: Avoid FLR for SolidRun SNET DPU rev 1
virtio: vdpa: new SolidNET DPU driver.
MAINTAINERS|4 +
drivers/pci/quirks.c |8 +
dri
Add SolidRun vendor ID to pci_ids.h
The vendor ID is used in 2 different source files, the SNET vDPA driver
and PCI quirks.
Signed-off-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
---
include/linux/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci_ids.h b/include
Ok, I'll send a new version
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Thanks Bjorn.
> This should be indented with tabs instead of spaces so it matches the
> rest of the file.
Michael, sorry about all the versions..
Do you want me to fix it in a new version?
I could fix it with a patch directly to the pci maintainers after your
linux-next is merged, if this is ok
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
Acked-by: Jason Wang
---
MAINTAINERS|4 +
drivers/vdpa/Kconfig | 18 +
drivers/vdpa
-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
---
drivers/pci/quirks.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 285acc4aacc..809d03272c2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5343,6 +5343,14
Add SolidRun vendor ID to pci_ids.h
The vendor ID is used in 2 different source files,
the SNET vDPA driver and PCI quirks.
Signed-off-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
---
include/linux/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci_ids.h b/include
or 'psnet_create_hwmon'" when compiling
with W=1.
This was reported by kernel test robot - Patch 3.
v8:
- Fix the series versioning.
I updated the versions of every patch separately,
which seems to be wrong.
Alvaro Karsz (3):
PCI: Add SolidRun vendor ID
PCI: Avo
Hi Michael,
This patch was merged into:
[PATCH v7] virtio: vdpa: new SolidNET DPU driver.
So it can be ignored.
Thank you.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Hi Michael,
This patch was merged into:
[PATCH v7] virtio: vdpa: new SolidNET DPU driver.
So it can be ignored.
Thank you.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Hi Michael,
This patch was merged into:
[PATCH v7] virtio: vdpa: new SolidNET DPU driver.
So it can be ignored.
Thank you.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
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
Acked-by: Jason Wang
--
v2:
- Auto detect the BAR used for communication.
- When waiting for the DPU to write
on top of:
virtio: vdpa: new SolidNET DPU driver,
by Alvaro Karsz alvaro.ka...@solid-run.com
Signed-off-by: Alvaro Karsz
---
drivers/vdpa/solidrun/snet_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_main.c
b/drivers/vdpa/solidrun
-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
--
v2:
- Update patch subject to be more meaningful and similar to
previous quirks.
- Update the commit log to describe better what the patch does.
---
drivers/pci/quirks.c | 8
1 file changed, 8 insertions(+)
diff
Add SolidRun vendor ID to pci_ids.h
The vendor ID is used in 2 different source files,
the SNET vDPA driver and PCI quirks.
Signed-off-by: Alvaro Karsz
Acked-by: Bjorn Helgaas
--
v2:
- Semantics fixes in commit log.
- Move the vendor ID to the rigth place, sorted by vendor ID
Hi Bjorn,
> Hi Alvaro,
>
> On Mon, Dec 19, 2022 at 10:35:09AM +0200, Alvaro Karsz wrote:
> > The vendor id is used in 2 differrent source files,
> > the SNET vdpa driver and pci quirks.
>
> s/id/ID/ # both in subject and commit log
> s/diffe
1 - 100 of 179 matches
Mail list logo
