On Tue, Oct 12, 2021 at 02:43:13PM +0800, Jason Wang wrote:
> On Tue, Oct 12, 2021 at 2:35 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Oct 12, 2021 at 02:11:10PM +0800, Jason Wang wrote:
> > > On Tue, Oct 12, 2021 at 1:44 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Tue, Oct 12, 2021 a
On Tue, Oct 12, 2021 at 3:03 PM Michael S. Tsirkin wrote:
>
> On Tue, Oct 12, 2021 at 02:43:13PM +0800, Jason Wang wrote:
> > On Tue, Oct 12, 2021 at 2:35 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Oct 12, 2021 at 02:11:10PM +0800, Jason Wang wrote:
> > > > On Tue, Oct 12, 2021 at 1:44 PM M
From: Leon Romanovsky
Hi,
This is cleanup series of mlx5_* MR mkey management.
Thanks
Aharon Landau (7):
RDMA/mlx5: Don't set esc_size in user mr
RDMA/mlx5: Remove iova from struct mlx5_core_mkey
RDMA/mlx5: Remove size from struct mlx5_core_mkey
RDMA/mlx5: Remove pd from struct mlx5_co
From: Aharon Landau
reg_create() is used for user MRs only and should not set desc_size at
all. Attempt to set it causes to the following trace:
BUG: unable to handle page fault for address: 0008
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 5 PID: 890 Comm: ib_write_bw Not tainted 5.15.0
From: Aharon Landau
iova is already stored in ibmr->iova, no need to store it here.
Signed-off-by: Aharon Landau
Reviewed-by: Shay Drory
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 1 -
drivers/infiniband/hw/mlx5/mr.c | 16
From: Aharon Landau
There is no read of mkey->pd, only write. Remove it.
Signed-off-by: Aharon Landau
Reviewed-by: Shay Drory
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 1 -
drivers/infiniband/hw/mlx5/mr.c | 3 ---
drivers/net/ethernet/mell
From: Aharon Landau
In mlx5_core and vdpa there is no use of mlx5_core_mkey members except
for the key itself.
As preparation for moving mlx5_core_mkey to mlx5_ib, the occurrences of
struct mlx5_core_mkey in all modules except for mlx5_ib are replaced by
a u32 key.
Signed-off-by: Aharon Landau
From: Aharon Landau
mkey->size is already stored in ibmr->length, no need to store it here.
Signed-off-by: Aharon Landau
Reviewed-by: Shay Drory
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 1 -
drivers/infiniband/hw/mlx5/mr.c | 5 ++---
driv
From: Aharon Landau
Generalize the use of ndescs by adding it to mlx5_ib_mkey.
Signed-off-by: Aharon Landau
Reviewed-by: Shay Drory
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 10 --
drivers/infiniband/hw/mlx5/devx.h| 2 +-
drivers/infiniband/hw/mlx
From: Aharon Landau
Move mlx5_core_mkey struct to mlx5_ib, as the mlx5_core doesn't use it
at this point.
Signed-off-by: Aharon Landau
Reviewed-by: Shay Drory
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/hw/mlx5/devx.c| 2 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 25 ++
On Tue, Oct 12, 2021 at 01:26:28PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> This is cleanup series of mlx5_* MR mkey management.
>
> Thanks
Looks fine superficially
Acked-by: Michael S. Tsirkin
> Aharon Landau (7):
> RDMA/mlx5: Don't set esc_size in user mr
> R
On Tue, Oct 12, 2021 at 11:04:33AM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 12, 2021 at 04:57:16PM +0300, Aharon Landau wrote:
> >
> > On 10/12/2021 3:52 PM, Jason Gunthorpe wrote:
> > > On Tue, Oct 12, 2021 at 01:26:29PM +0300, Leon Romanovsky wrote:
> > > > From: Aharon Landau
> > > >
> > >
* Conference listed in CORE Ranking
** Google Scholar H5-Index = 23
*** Best papers selected for SCI/SSCI journals
--
WorldCIST'22 - 10th World Conference on Information Systems and Technol
* Conference listed in CORE Ranking
** Google Scholar H5-Index = 23
*** Best papers selected for SCI/SSCI journals
--
WorldCIST'22 - 10th World Conference on Information Systems and Technol
On Sun, Oct 10, 2021 at 3:11 PM Andi Kleen wrote:
>
>
> On 10/9/2021 1:39 PM, Dan Williams wrote:
> > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
> >> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> >>> From: Andi Kleen
> >>>
> >>> For Confidential VM g
I mean ... it's already wide spread.
I meant wide spread usage with confidential guests.
If we support it with TDX
it will be used with TDX.
It has some security trade offs. The main reason to use TDX is security.
Also when people take the VT-d tradeoffs they might be ok with the BIOS
The "better safe-than-sorry" argument is hard to build consensus
around. The spectre mitigations ran into similar problems where the
community rightly wanted to see the details and instrument the
problematic paths rather than blanket sprinkle lfence "just to be
safe".
But that was due to perf
On 10/11/2021 10:31 PM, Christoph Hellwig wrote:
On Mon, Oct 11, 2021 at 03:09:09PM -0400, Michael S. Tsirkin wrote:
The reason we have trouble is that it's not clear what does the API mean
outside the realm of TDX.
If we really, truly want an API that says "ioremap and it's a hardened
driver"
On 10/12/2021 11:36 AM, Reshetova, Elena wrote:
The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
others) in init functions that also register drivers (thanks Elena for
the number)
To provide more numbers on this. What I can see so far from a smatch-based
analysis, we have
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena
wrote:
>
>
> > I suspect the true number is even higher because that doesn't include IO
> > inside calls to other modules and indirect pointers, correct?
>
> Actually everything should be included. Smatch has cross-function db and
> I am using it f
On 10/12/2021 12:13 PM, Dan Williams wrote:
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena
wrote:
I suspect the true number is even higher because that doesn't include IO
inside calls to other modules and indirect pointers, correct?
Actually everything should be included. Smatch has cro
On Tue, Oct 12, 2021 at 10:55:20AM -0700, Andi Kleen wrote:
>
> > I mean ... it's already wide spread.
>
>
> I meant wide spread usage with confidential guests.
>
> > If we support it with TDX
> > it will be used with TDX.
>
> It has some security trade offs. The main reason to use TDX is secu
On Tue, Oct 12, 2021 at 06:36:16PM +, Reshetova, Elena wrote:
> > The 5.15 tree has something like ~2.4k IO accesses (including MMIO and
> > others) in init functions that also register drivers (thanks Elena for
> > the number)
>
> To provide more numbers on this. What I can see so far from a
On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen wrote:
>
>
> > The "better safe-than-sorry" argument is hard to build consensus
> > around. The spectre mitigations ran into similar problems where the
> > community rightly wanted to see the details and instrument the
> > problematic paths rather than b
Interesting. VT-d tradeoffs ... what are they?
The connection to the device is not encrypted and also not authenticated.
This is different that even talking to the (untrusted) host through
shared memory where you at least still have a common key.
Allowing hypervisor to write into BIOS lo
On Tue, Oct 12, 2021 at 02:14:44PM -0700, Dan Williams wrote:
> Especially in this case where the virtio use case being
> opted-in is *already* in a path that has been authorized by the
> device-filter policy engine.
That's a good point. Andi, how about setting a per-device flag
if its ID has been
On 10/12/2021 2:18 PM, Michael S. Tsirkin wrote:
On Tue, Oct 12, 2021 at 02:14:44PM -0700, Dan Williams wrote:
Especially in this case where the virtio use case being
opted-in is *already* in a path that has been authorized by the
device-filter policy engine.
That's a good point. Andi, how ab
But that was due to performance problems in hot paths. Nothing of this
applies here.
It applies because a new API that individual driver authors is being
proposed and that's an ongoing maintenance burden that might be
mitigated by hiding that implementation detail from leaf drivers.
Right no
On Tue, Oct 12, 2021 at 02:18:01PM -0700, Andi Kleen wrote:
>
> > Interesting. VT-d tradeoffs ... what are they?
>
> The connection to the device is not encrypted and also not authenticated.
>
> This is different that even talking to the (untrusted) host through shared
> memory where you at leas
On Tue, Oct 12, 2021 at 2:28 PM Andi Kleen wrote:
[..]
> >> But how do you debug the kernel then? Making early undebuggable seems
> >> just bad policy to me.
> > I am not proposing making the early undebuggable.
>
>
> That's the implication of moving the policy into initrd.
>
>
> If only initrd ca
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
Shadow virtqueue notifications forwarding is disabled when vhost_dev
stops, so code flow follows usual cleanup.
Also, host notifiers must be disabled at SVQ start,
Any reason for this?
and they will not
start if SVQ has been enabled when device is sto
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
We need to know it to switch to Shadow VirtQueue.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-vdpa.h | 2 ++
hw/virtio/vhost-vdpa.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/include/hw/virtio/vhost-vdpa.h b/include/
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
index 57a857444a..bc34de2439 100644
--- a/hw/virtio/vhost-vdpa.
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
This will make qemu aware of the device used buffers, allowing it to
write the guest memory with its contents if needed.
Since the use of vhost_virtqueue_start can unmasks and discard call
events, vhost_virtqueue_start should be modified in one of these way
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
This will make qemu aware of the device used buffers, allowing it to
write the guest memory with its contents if needed.
Since the use of vhost_virtqueue_start can unmasks and discard call
events, vhost_virtqueue_start should be modified in one of these way
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
It reports the shadow virtqueue address from qemu virtual address space
I think both the title and commit log needs to more tweaks. Looking at
the codes, what id does is actually introduce vring into svq.
Signed-off-by: Eugenio Pérez
---
hw/virti
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
Those are needed for SVQ: Host ones are needed to check if SVQ knows
how to talk with the device and for feature negotiation, and guest ones
to know if SVQ can talk with it.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-vdpa.h | 2 ++
hw/vir
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
Initial version of shadow virtqueue that actually forward buffers. There
are no iommu support at the moment, and that will be addressed in future
patches of this series. Since all vhost-vdpa devices uses forced IOMMU,
this means that SVQ is not usable at thi
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-shadow-virtqueue.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/vhost-shadow-virtqueue.c
b/hw/virtio/vhost-shadow-virtqueue.c
index df7e6fa3ec..775f8d36a0 1006
在 2021/10/1 下午3:06, Eugenio Pérez 写道:
Signed-off-by: Eugenio Pérez
Commit log please.
Thanks
---
hw/virtio/vhost-shadow-virtqueue.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/vhost-shadow-virtqueue.c
b/hw/virtio/vhost-shadow
在 2021/10/1 下午3:06, Eugenio Pérez 写道:
Use translations added in VhostIOVATree in SVQ.
Now every element needs to store the previous address also, so VirtQueue
can consume the elements properly. This adds a little overhead per VQ
element, having to allocate more memory to stash them. As a possib
41 matches
Mail list logo
