On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 08:58:58AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 30, 2023 at 04:43:34PM +0300, Arseniy Krasnov wrote:
> >
> >
> > On 30.11.2023
On 01.12.2023 11:27, Stefano Garzarella wrote:
> On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
>> On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
>>> On Thu, Nov 30, 2023 at 08:58:58AM -0500, Michael S. Tsirkin wrote:
>>> > On Thu, Nov 30, 2023 at 04:43:
On Tue Nov 28, 2023 at 9:14 AM CET, Vikash Garodia wrote:
>
> On 11/24/2023 9:26 PM, Luca Weiss wrote:
> > On Fri Nov 24, 2023 at 2:35 PM CET, Vikash Garodia wrote:
> >>
> >>
> >> On 11/24/2023 6:23 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 24 Nov 2023 at 14:30, Vikash Garodia
> >>> wrote:
>
Devices with Qualcomm firmware (compared to ChromeOS firmware) need some
changes in the venus driver and dts layout so that venus can initialize.
Do these changes, similar to sc7180.
Signed-off-by: Luca Weiss
---
Changes in v3:
- Move 0x2184 iommu from sc7280.dtsi to sc7280-chrome-common.dtsi si
Not all SC7280 devices ship with ChromeOS firmware. Other devices need
PAS for image authentication. That requires the predefined virtual
address ranges to be passed via scm calls. Define them to enable Venus
on non-CrOS SC7280 devices.
Reviewed-by: Konrad Dybcio
Reviewed-by: Bryan O'Donoghue
Re
If the video-firmware node is present, the venus driver assumes we're on
a system that doesn't use TZ for starting venus, like on ChromeOS
devices.
Move the video-firmware node to chrome-common.dtsi so we can use venus
on a non-ChromeOS devices. We also need to move the secure SID 0x2184
for iommu
Enable the venus node so that the video encoder/decoder will start
working.
Reviewed-by: Konrad Dybcio
Reviewed-by: Bryan O'Donoghue
Reviewed-by: Vikash Garodia
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff --
On Fri, Dec 01, 2023 at 11:35:56AM +0300, Arseniy Krasnov wrote:
On 01.12.2023 11:27, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 08:58:58AM -0500, Mi
On 01.12.2023 12:48, Stefano Garzarella wrote:
> On Fri, Dec 01, 2023 at 11:35:56AM +0300, Arseniy Krasnov wrote:
>>
>>
>> On 01.12.2023 11:27, Stefano Garzarella wrote:
>>> On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano
Add support for resumable vqs in the driver. This is a firmware feature
that can be used for the following benefits:
- Full device .suspend/.resume.
- .set_map doesn't need to destroy and create new vqs anymore just to
update the map. When resumable vqs are supported it is enough to
suspend the
Necessary for checking if resumable vqs are supported by the hardware.
Actual support will be added in a downstream patch.
Signed-off-by: Dragos Tatulea
---
include/linux/mlx5/mlx5_ifc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include
mlx5_vdpa_destroy_mr contains more logic than _mlx5_vdpa_destroy_mr.
There is no reason for this to be the case. All the logic can go into
the unlocked variant.
Using the unlocked version is needed in a follow-up patch. And it also
makes it more consistent with mlx5_vdpa_create_mr.
Signed-off-by:
Add a bitmask variable that tracks hw vq field changes that
are supposed to be modified on next hw vq change command.
This will be useful to set multiple vq fields when resuming the vq.
The state needs to remain as a parameter as it doesn't make sense to
make it part of the vq struct: fw_state is
Implement vdpa vq and device resume if capability detected. Add support
for suspend -> ready state change.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 67 +++
1 file changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/vdpa/mlx5/ne
Addresses get set by .set_vq_address. hw vq addresses will be updated on
next modify_virtqueue.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 9 +
include/linux/mlx5/mlx5_ifc_vdpa.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5
.set_vq_state will set the indices and mark the fields to be modified in
the hw vq.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
include/linux/mlx5/mlx5_ifc_vdpa.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/d
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Signed-off-by: Dragos Tatu
Fifo head and tail index can be modified with wrong values from
untrusted remote procs. Glink smem is not validating these index
before using to read or write fifo. This can result in out of
bound memory access if head and tail have incorrect values.
Add check for validation of head and tail index
On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
>
> mlx5_vdpa_destroy_mr contains more logic than _mlx5_vdpa_destroy_mr.
> There is no reason for this to be the case. All the logic can go into
> the unlocked variant.
>
> Using the unlocked version is needed in a follow-up patch. And it also
Currently there seems to be three page frag implementions
which all try to allocate order 3 page, if that fails, it
then fail back to allocate order 0 page, and each of them
all allow order 3 page allocation to fail under certain
condition by using specific gfp bits.
The gfp bits for order 3 page
The page frag in vhost_net_page_frag_refill() uses the
'struct page_frag' from skb_page_frag_refill(), but it's
implementation is similar to page_frag_alloc_align() now.
This patch removes vhost_net_page_frag_refill() by using
'struct page_frag_cache' instead of 'struct page_frag',
and allocating
introduce vhost_net_test basing on virtio_test to test
vhost_net changing in the kernel.
Signed-off-by: Yunsheng Lin
---
tools/virtio/Makefile | 8 +-
tools/virtio/vhost_net_test.c | 441 ++
2 files changed, 446 insertions(+), 3 deletions(-)
create mode
When draining a page_frag_cache, most user are doing
the similar steps, so introduce an API to avoid code
duplication.
Signed-off-by: Yunsheng Lin
---
drivers/net/ethernet/google/gve/gve_main.c | 11 ++-
drivers/net/ethernet/mediatek/mtk_wed_wo.c | 17 ++---
drivers/nvme/host
On 11/29/23 15:58, Steven Rostedt wrote:
> On Wed, 29 Nov 2023 10:22:23 +0100
> Petr Pavlu wrote:
>
>> Yes, I believe this should address this potential race condition.
>>
>> An alternative would be instead to update
>> trace_event_buffer_lock_reserve() as follows:
>>
>> if (this_cpu_inc_ret
On Fri, 1 Dec 2023 15:17:35 +0100
Petr Pavlu wrote:
> Ok, keeping the current approach, my plan for v2 is to prepare the
> following patches:
>
> * Fix for the missing increment+decrement of trace_buffered_event_cnt
> on the current CPU in trace_buffered_event_disable().
>
> Replace smp_cal
On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
>
> Add a bitmask variable that tracks hw vq field changes that
> are supposed to be modified on next hw vq change command.
>
> This will be useful to set multiple vq fields when resuming the vq.
>
> The state needs to remain as a parameter as
On Fri, Dec 1, 2023 at 11:50 AM Dragos Tatulea wrote:
>
> Implement vdpa vq and device resume if capability detected. Add support
> for suspend -> ready state change.
>
> Signed-off-by: Dragos Tatulea
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 67 +
On Fri, Dec 1, 2023 at 11:50 AM Dragos Tatulea wrote:
>
> .set_vq_state will set the indices and mark the fields to be modified in
> the hw vq.
>
> Signed-off-by: Dragos Tatulea
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
> include/linux/mlx5/mlx5_ifc_vdpa
On 12/01, Eugenio Perez Martin wrote:
> On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
> >
> > Add a bitmask variable that tracks hw vq field changes that
> > are supposed to be modified on next hw vq change command.
> >
> > This will be useful to set multiple vq fields when resuming the vq
On Mon, Nov 20, 2023 at 05:11:41PM +0200, Andy Shevchenko wrote:
> A couple of patches are for get the string ops, used in the module,
> slightly harden. On top a few cleanups.
>
> Since the main part is rather hardening, I think the Kees' tree is
> the best fit for the series. It also possible to
On 11/27/2023 4:09 AM, Krishna chaitanya chundru wrote:
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_r
On Fri, 1 Dec 2023 10:01:33 -0700
Jeffrey Hugo wrote:
> > +DECLARE_EVENT_CLASS(mhi_process_event_ring,
> > +
> > + TP_PROTO(const char *name, void *rp, __le64 ptr,
> > +__le32 dword0, __le32 dword1),
> > +
> > + TP_ARGS(name, rp, ptr, dword0, dword1),
> > +
> > + TP_STRUCT__entr
On Mon, 20 Nov 2023 17:11:41 +0200, Andy Shevchenko wrote:
> A couple of patches are for get the string ops, used in the module,
> slightly harden. On top a few cleanups.
>
> Since the main part is rather hardening, I think the Kees' tree is
> the best fit for the series. It also possible to route
On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> >
> > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > Hi Mathieu,
> > > >
> > > > Please find my comments below.
On Fri, Dec 01, 2023 at 09:43:34AM -0800, Kees Cook wrote:
> On Mon, 20 Nov 2023 17:11:41 +0200, Andy Shevchenko wrote:
> > A couple of patches are for get the string ops, used in the module,
> > slightly harden. On top a few cleanups.
> >
> > Since the main part is rather hardening, I think the K
35 matches
Mail list logo
