On 2017年04月08日 03:17, Jean-Philippe Brucker wrote:
This is the initial proposal for a paravirtualized IOMMU device using
virtio transport. It contains a description of the device, a Linux driver,
and a toy implementation in kvmtool. With this prototype, you can
translate DMA to guest memory
On 2019/1/30 上午3:02, Michael S. Tsirkin wrote:
On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote:
Fixing address of powerpc mailing list.
Thiago Jung Bauermann writes:
Hello,
With Christoph's rework of the DMA API that recently landed, the patch
below is the only
On 2019/1/30 上午10:36, Michael S. Tsirkin wrote:
On Wed, Jan 30, 2019 at 10:24:01AM +0800, Jason Wang wrote:
On 2019/1/30 上午3:02, Michael S. Tsirkin wrote:
On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote:
Fixing address of powerpc mailing list.
Thiago Jung Bauermann
On 2019/1/10 下午9:44, Joerg Roedel wrote:
Hi,
there is a problem with virtio-blk driven devices when
virtio-ring uses SWIOTLB through the DMA-API. This happens
for example in AMD-SEV enabled guests, where the guest RAM
is mostly encrypted and all emulated DMA has to happen
to/from the SWIOTLB
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
all virtio devices under AMD-SEV guests?
Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture
On 2019/10/15 下午3:35, Christoph Hellwig wrote:
On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
From: Thiago Jung Bauermann
Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
be set by both device and guest driver. However, as a hack, when DMA API
returns
On 2020/2/24 下午9:56, Halil Pasic wrote:
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
That's better.
How about attached?
Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU
. This patch fixes this.
Signed-off-by: Jason Wang
---
hw/net/virtio-net.c | 3 +++
hw/virtio/vhost.c | 4 +---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 3627bb1717..0d50e8bd34 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio
On 2020/2/24 下午3:48, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFORM flag for each virtio device to make the guest
linux use the DMA API, which in turn handles the
On 2020/2/21 上午10:59, David Gibson wrote:
On Thu, Feb 20, 2020 at 05:13:09PM +0100, Christoph Hellwig wrote:
On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 867c7ebd3f10..fafc8f924955 100644
---
On 2020/4/30 下午6:07, Michael S. Tsirkin wrote:
On Thu, Apr 30, 2020 at 03:32:55PM +0530, Srivatsa Vaddagiri wrote:
The Type-1 hypervisor we are dealing with does not allow for MMIO transport.
How about PCI then?
Or maybe you can use virtio-vdpa.
Thanks
- Original Message -
> Hi Jason
>
> On Wed, Sep 09, 2020 at 04:34:32PM +0800, Jason Wang wrote:
> > Commit 61363c1474b1 ("iommu/vt-d: Enable ATS only if the device uses
> > page aligned address.") disables ATS for device that can do unaligned
> > p
On 2020/9/14 下午9:31, Jean-Philippe Brucker wrote:
If it's possible, I would suggest a generic uAPI instead of a VFIO specific
one.
A large part of this work is already generic uAPI, in
include/uapi/linux/iommu.h.
This is not what I read from this series, all the following uAPI is VFIO
On 2020/9/16 上午3:26, Raj, Ashok wrote:
IIUC, you are asking that part of the interface to move to a API interface
that potentially the new /dev/sva and VFIO could share? I think the API's
for PASID management themselves are generic (Jean's patchset + Jacob's
ioasid set management).
Yes, the in
On 2020/9/14 下午4:01, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
On 2020/9/10 下午6:45, Liu Yi L wrote:
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA
A victim is Qemu's virtio-pci which doesn't advertise the page aligned
address. Fixing by disable PRI instead of ATS if device doesn't have
page aligned request.
Cc: sta...@vger.kernel.org
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Keith Busch
Cc: Kuppuswamy Sathyanarayanan
Signed-off-by: Jason Wang
--
On 2020/9/10 下午6:45, Liu Yi L wrote:
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA can reduce programming complexity and enhance security.
This VFIO series is intended to expose SVA
On 2020/9/10 下午11:53, Raj, Ashok wrote:
On Wed, Sep 09, 2020 at 10:17:35PM -0400, Jason Wang wrote:
- Original Message -
Hi Jason
On Wed, Sep 09, 2020 at 04:34:32PM +0800, Jason Wang wrote:
Commit 61363c1474b1 ("iommu/vt-d: Enable ATS only if the device uses
page aligned ad
On 2020/10/14 上午11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
speci
On 2020/10/15 下午3:58, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 2:52 PM
On 2020/10/14 上午11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14
On 2020/10/15 上午7:10, Alex Williamson wrote:
On Wed, 14 Oct 2020 03:08:31 +
"Tian, Kevin" wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020 2:22 PM
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
On 2020/10/12 下午4:38, Tian, Kevin wrote:
From: Jason Wang
Sent: Monday, September 14, 2020 12:20 PM
[...]
> If it's possible, I would suggest a generic uAPI instead of a VFIO
specific one.
Jason suggest something like /dev/sva. There will be a lot of other
subsystems that could bene
On 2020/10/15 下午6:14, Liu, Yi L wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 4:41 PM
On 2020/10/15 ??3:58, Tian, Kevin wrote:
From: Jason Wang
Sent: Thursday, October 15, 2020 2:52 PM
On 2020/10/14 ??11:08, Tian, Kevin wrote:
From: Jason Wang
Sent: Tuesday, October 13, 2020
Hi Yi:
On 2020/10/20 下午4:19, Liu, Yi L wrote:
Yes, but since PASID is a global identifier now, I think kernel should
track the a device list per PASID?
We have such track. It's done in iommu driver. You can refer to the
struct intel_svm. PASID is a global identifier, but it doesn’t affect that
On 2020/9/18 上午2:17, Jacob Pan (Jun) wrote:
Hi Jason,
On Thu, 17 Sep 2020 11:53:49 +0800, Jason Wang
wrote:
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote
On 2020/9/17 上午7:09, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 15:38:41 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
Hi Jason,
On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
wrote:
On Wed, Sep 16, 2020 at 09:33:43AM
On 2020/10/22 上午11:54, Liu, Yi L wrote:
Hi Jason,
From: Jason Wang
Sent: Thursday, October 22, 2020 10:56 AM
[...]
If you(Intel) don't have plan to do vDPA, you should not prevent other vendors
from implementing PASID capable hardware through non-VFIO subsystem/uAPI
on top of your SIOV
On 2020/10/22 上午1:51, Raj, Ashok wrote:
On Wed, Oct 21, 2020 at 08:48:29AM -0300, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote:
On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
- Original Message -
> .snip.
> > > > This raises two issues:
> > > > 1) swiotlb_tlb_unmap_single fails to check whether the index generated
> > > > from the dma_addr is in range of the io_tlb_orig_addr array.
> > > That is fairly simple to implement I would think. That is it can check
- Original Message -
>
>
> - Original Message -
> > .snip.
> > > > > This raises two issues:
> > > > > 1) swiotlb_tlb_unmap_single fails to check whether the index
> > > > > generated
> > > > > from the dma_addr is in range of the io_tlb_orig_addr array.
> > > > That is fairly
On 2020/12/15 上午5:49, Konrad Rzeszutek Wilk wrote:
On Fri, Dec 11, 2020 at 06:31:21PM +0100, Felicitas Hetzelt wrote:
Hello,
Hi! Please see below my responses.
we have been analyzing the Hypervisor-OS interface of Linux
and discovered bugs in the swiotlb/virtio implementation that can be
On 2020/12/16 下午9:04, Konrad Rzeszutek Wilk wrote:
On December 16, 2020 1:41:48 AM EST, Jason Wang wrote:
- Original Message -
- Original Message -
.snip.
This raises two issues:
1) swiotlb_tlb_unmap_single fails to check whether the index
generated
from the dma_addr
On 2020/10/20 下午10:19, Liu, Yi L wrote:
From: Jason Gunthorpe
Sent: Tuesday, October 20, 2020 10:02 PM
[...]
Whoever provides the vIOMMU emulation and relays the page fault to the
guest
has to translate the RID -
that's the point. But the device info (especially the sub-device info) is
On 2021/1/14 上午9:30, Lu Baolu wrote:
Some vendor IOMMU drivers are able to declare that it is running in a VM
context. This is very valuable for the features that only want to be
supported on bare metal. Add a capability bit so that it could be used.
Signed-off-by: Lu Baolu
---
在 2021/6/3 上午1:21, Jason Gunthorpe 写道:
On Wed, Jun 02, 2021 at 04:54:26PM +0800, Jason Wang wrote:
在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
We can open up to ~0U file descriptors, I don't see why we need to restrict
it in uAPI
在 2021/6/8 上午3:41, Alex Williamson 写道:
On Mon, 7 Jun 2021 16:08:02 -0300
Jason Gunthorpe wrote:
On Mon, Jun 07, 2021 at 12:59:46PM -0600, Alex Williamson wrote:
It is up to qemu if it wants to proceed or not. There is no issue with
allowing the use of no-snoop and blocking wbinvd, other
在 2021/6/7 下午10:14, Jason Gunthorpe 写道:
On Mon, Jun 07, 2021 at 11:18:33AM +0800, Jason Wang wrote:
Note that no drivers call these things doesn't meant it was not
supported by the spec.
Of course it does. If the spec doesn't define exactly when the driver
should call the cache flushes
在 2021/6/10 上午10:00, Jason Wang 写道:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already
worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
在 2021/6/22 下午4:14, Yongji Xie 写道:
On Tue, Jun 22, 2021 at 3:50 PM Jason Wang wrote:
在 2021/6/22 下午3:22, Yongji Xie 写道:
We need fix a way to propagate the error to the userspace.
E.g if we want to stop the deivce, we will delay the status reset until
we get respose from the userspace?
I
在 2021/6/21 下午6:41, Yongji Xie 写道:
On Mon, Jun 21, 2021 at 5:14 PM Jason Wang wrote:
在 2021/6/15 下午10:13, Xie Yongji 写道:
This VDUSE driver enables implementing vDPA devices in userspace.
The vDPA device's control path is handled in kernel and the data
path is handled in userspace
在 2021/6/22 下午3:22, Yongji Xie 写道:
We need fix a way to propagate the error to the userspace.
E.g if we want to stop the deivce, we will delay the status reset until
we get respose from the userspace?
I didn't get how to delay the status reset. And should it be a DoS
that we want to fix if
在 2021/6/15 下午10:13, Xie Yongji 写道:
This VDUSE driver enables implementing vDPA devices in userspace.
The vDPA device's control path is handled in kernel and the data
path is handled in userspace.
A message mechnism is used by VDUSE driver to forward some control
messages such as
在 2021/6/24 下午5:16, Yongji Xie 写道:
On Thu, Jun 24, 2021 at 4:14 PM Jason Wang wrote:
在 2021/6/24 下午12:46, Yongji Xie 写道:
So we need to deal with both FEATURES_OK and reset, but probably not
DRIVER_OK.
OK, I see. Thanks for the explanation. One more question is how about
clearing
在 2021/6/10 下午7:47, Jason Gunthorpe 写道:
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds
在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
Well, this sounds like a re-invention of io_uring which has already worked
for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
Actually
在 2021/6/8 下午6:45, Enrico Weigelt, metux IT consult 写道:
On 07.06.21 20:01, Jason Gunthorpe wrote:
it is what it is, select has a fixed size bitmap of FD #s and
a hard upper bound on that size as part of the glibc ABI - can't be
fixed.
in glibc ABI ? Uuuuh!
Note that dealing with select()
在 2021/5/17 下午5:55, Xie Yongji 写道:
Export alloc_iova_fast() so that some modules can use it
to improve iova allocation efficiency.
Signed-off-by: Xie Yongji
---
drivers/iommu/iova.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index
scsi_cmnd *sc, u32 resid)
{
if (resid)
- scsi_set_resid(sc, resid);
+ scsi_set_resid(sc, min(resid, scsi_bufflen(sc)));
}
/*
Acked-by: Jason Wang
___
iommu mailing list
iommu@lists.linux-foundation.org
在 2021/5/20 下午5:06, Yongji Xie 写道:
On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin wrote:
On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
This series introduces a framework, which can be used to implement
vDPA Devices in a userspace program. The work consist of two parts:
On Tue, May 25, 2021 at 2:48 PM Michael S. Tsirkin wrote:
>
> On Tue, May 25, 2021 at 02:40:57PM +0800, Jason Wang wrote:
> >
> > 在 2021/5/20 下午5:06, Yongji Xie 写道:
> > > On Thu, May 20, 2021 at 2:06 PM Michael S. Tsirkin
> > > wrote:
> > > > On M
在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
We can open up to ~0U file descriptors, I don't see why we need to restrict
it in uAPI.
There are significant problems with such large file descriptor
tables. High FD numbers man things like
在 2021/6/2 上午4:28, Jason Gunthorpe 写道:
I summarized five opens here, about:
1) Finalizing the name to replace /dev/ioasid;
2) Whether one device is allowed to bind to multiple IOASID fd's;
3) Carry device information in invalidation/fault reporting uAPI;
4) What should/could be specified
在 2021/6/2 上午1:29, Jason Gunthorpe 写道:
On Tue, Jun 01, 2021 at 02:07:05PM +0800, Jason Wang wrote:
For the case of 1M, I would like to know what's the use case for a single
process to handle 1M+ address spaces?
For some scenarios every guest PASID will require a IOASID ID # so
在 2021/5/31 下午4:41, Liu Yi L 写道:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail in the IOASID_CREATE_NESTING. If the gpa_ioasid
is not able to support nesting, then should fail it.
在 2021/6/1 上午11:31, Liu Yi L 写道:
On Tue, 1 Jun 2021 10:36:36 +0800, Jason Wang wrote:
在 2021/5/31 下午4:41, Liu Yi L 写道:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail
在 2021/6/1 下午1:42, Tian, Kevin 写道:
From: Jason Wang
Sent: Tuesday, June 1, 2021 1:30 PM
在 2021/6/1 下午1:23, Lu Baolu 写道:
Hi Jason W,
On 6/1/21 1:08 PM, Jason Wang wrote:
2) If yes, what's the reason for not simply use the fd opened from
/dev/ioas. (This is the question that is not answered
在 2021/6/1 下午12:27, Shenming Lu 写道:
On 2021/6/1 10:36, Jason Wang wrote:
在 2021/5/31 下�4:41, Liu Yi L 写�:
I guess VFIO_ATTACH_IOASID will fail if the underlayer doesn't support
hardware nesting. Or is there way to detect the capability before?
I think it could fail
在 2021/6/1 下午1:23, Lu Baolu 写道:
Hi Jason W,
On 6/1/21 1:08 PM, Jason Wang wrote:
2) If yes, what's the reason for not simply use the fd opened from
/dev/ioas. (This is the question that is not answered) and what
happens
if we call GET_INFO for the ioasid_fd?
3) If not, how GET_INFO work
在 2021/5/27 下午4:41, Jason Wang 写道:
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang wrote:
在 2021/5/27 下午1:08, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:00 PM Jason Wang
wrote:
在 2021/5/27 下午12:57, Yongji Xie 写道:
On Thu, May 27, 2021 at 12:13 PM Jason Wang
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang wrote:
在 2021/5/27 下午1:08, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:00 PM Jason Wang wrote:
在 2021/5/27 下午12:57, Yongji Xie 写道:
On Thu, May 27, 2021 at 12:13 PM Jason Wang wrote:
在 2021/5/17 下午5:55, Xie
在 2021/5/28 上午11:54, Yongji Xie 写道:
On Fri, May 28, 2021 at 9:33 AM Jason Wang wrote:
在 2021/5/27 下午6:14, Yongji Xie 写道:
On Thu, May 27, 2021 at 4:43 PM Jason Wang wrote:
在 2021/5/27 下午4:41, Jason Wang 写道:
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang
在 2021/5/27 下午3:58, Tian, Kevin 写道:
/dev/ioasid provides an unified interface for managing I/O page tables for
devices assigned to userspace. Device passthrough frameworks (VFIO, vDPA,
etc.) are expected to use this interface instead of creating their own logic to
isolate untrusted device DMAs
在 2021/5/27 下午6:14, Yongji Xie 写道:
On Thu, May 27, 2021 at 4:43 PM Jason Wang wrote:
在 2021/5/27 下午4:41, Jason Wang 写道:
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang wrote:
在 2021/5/27 下午1:08, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:00 PM Jason Wang
在 2021/5/27 下午9:17, Yongji Xie 写道:
On Thu, May 27, 2021 at 4:41 PM Jason Wang wrote:
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang wrote:
在 2021/5/27 下午1:08, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:00 PM Jason Wang wrote:
在 2021/5/27 下午12:57, Yongji Xie
在 2021/6/3 上午8:41, Andi Kleen 写道:
In protected guest mode we don't trust the host.
This means we need to make sure the host cannot subvert us through
virtio communication. In general it can corrupt our virtio data
and cause a DOS, but it should not be able to access any data
that is not
在 2021/6/3 上午10:18, Andi Kleen 写道:
It looks to me all the evils came from the fact that we depends on
the descriptor ring.
So the checks in this patch could is unnecessary if we don't even
read from the descriptor ring which could be manipulated by the device.
This is what my series
在 2021/6/3 上午9:48, Andi Kleen 写道:
So we will see huge performance regression without indirect
descriptor. We need to consider to address this.
A regression would be when some existing case would be slower.
That's not the case because the behavior for the existing cases does
not change.
在 2021/6/3 上午10:56, Andi Kleen 写道:
I agree, but I want to know why indirect descriptor needs to be
disabled. The table can't be wrote by the device since it's not
coherent swiotlb mapping.
I had all kinds of problems with uninitialized entries in the indirect
table. So I gave up on it
在 2021/6/3 上午8:41, Andi Kleen 写道:
When running under TDX the virtio host is untrusted. The bulk
of the kernel memory is encrypted and protected, but the virtio
ring is in special shared memory that is shared with the
untrusted host.
This means virtio needs to be hardened against any attacks
在 2021/6/3 上午8:41, Andi Kleen 写道:
Harden the split buffer detachment path by adding boundary checking. Note
that when this fails we may fail to unmap some swiotlb mapping, which could
result in a leak and a DOS. But that's acceptable because an malicious host
can DOS us anyways.
Signed-off-by:
在 2021/6/3 上午8:41, Andi Kleen 写道:
[v1: Initial post]
With confidential computing like TDX the guest doesn't trust the host
anymore. The host is allowed to DOS of course, but it is not allowed
to read or write any guest memory not explicitely shared with it.
This has implication for virtio.
在 2021/6/3 上午4:37, Alex Williamson 写道:
On Wed, 2 Jun 2021 16:54:04 -0300
Jason Gunthorpe wrote:
On Wed, Jun 02, 2021 at 01:00:53PM -0600, Alex Williamson wrote:
Right, the device can generate the no-snoop transactions, but it's the
IOMMU that essentially determines whether those
在 2021/6/4 下午7:58, Jason Gunthorpe 写道:
On Fri, Jun 04, 2021 at 09:11:03AM +0800, Jason Wang wrote:
nor do any virtio drivers implement the required platform specific
cache flushing to make no-snoop TLPs work.
I don't get why virtio drivers needs to do that. I think DMA API should hide
those
在 2021/5/27 下午12:57, Yongji Xie 写道:
On Thu, May 27, 2021 at 12:13 PM Jason Wang wrote:
在 2021/5/17 下午5:55, Xie Yongji 写道:
+
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_dev_msg *msg)
+{
+ init_waitqueue_head(>waitq);
+ spin_l
在 2021/5/17 下午5:55, Xie Yongji 写道:
+
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_dev_msg *msg)
+{
+ init_waitqueue_head(>waitq);
+ spin_lock(>msg_lock);
+ vduse_enqueue_msg(>send_list, msg);
+ wake_up(>waitq);
+
在 2021/5/27 下午1:08, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:00 PM Jason Wang wrote:
在 2021/5/27 下午12:57, Yongji Xie 写道:
On Thu, May 27, 2021 at 12:13 PM Jason Wang wrote:
在 2021/5/17 下午5:55, Xie Yongji 写道:
+
+static int vduse_dev_msg_sync(struct vduse_dev *dev
在 2021/6/1 下午2:16, Tian, Kevin 写道:
From: Jason Wang
Sent: Tuesday, June 1, 2021 2:07 PM
在 2021/6/1 下午1:42, Tian, Kevin 写道:
From: Jason Wang
Sent: Tuesday, June 1, 2021 1:30 PM
在 2021/6/1 下午1:23, Lu Baolu 写道:
Hi Jason W,
On 6/1/21 1:08 PM, Jason Wang wrote:
2) If yes, what's the reason
在 2021/5/31 下午12:27, Yongji Xie 写道:
On Fri, May 28, 2021 at 10:31 AM Jason Wang wrote:
在 2021/5/27 下午9:17, Yongji Xie 写道:
On Thu, May 27, 2021 at 4:41 PM Jason Wang wrote:
在 2021/5/27 下午3:34, Yongji Xie 写道:
On Thu, May 27, 2021 at 1:40 PM Jason Wang wrote:
在 2021/5/27 下午1:08, Yongji
在 2021/6/4 上午1:33, Andy Lutomirski 写道:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
an malicious host to force anything else. Also disallow
indirect mode for similar reasons.
I read
在 2021/6/3 下午9:55, Andi Kleen 写道:
Ok, but what I meant is this, if we don't read from the descriptor
ring, and validate all the other metadata supplied by the device
(used id and len). Then there should be no way for the device to
suppress the dma flags to write to the indirect descriptor
在 2021/6/3 下午9:09, Jason Gunthorpe 写道:
On Thu, Jun 03, 2021 at 10:52:51AM +0800, Jason Wang wrote:
Basically, we don't want to bother with pseudo KVM device like what VFIO
did. So for simplicity, we rules out the IOMMU that can't enforce coherency
in vhost-vDPA if the parent purely depends
在 2021/6/4 上午3:31, Andy Lutomirski 写道:
On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
在 2021/6/4 上午2:00, Andi Kleen 写道:
On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
On 6/2/21 5:41 PM, Andi Kleen wrote:
Only allow split mode when in a protected guest. Followon
patches harden the split mode code paths, and we don't want
an malicious host to force anything else. Also disallow
在 2021/6/4 上午2:19, Jacob Pan 写道:
Hi Shenming,
On Wed, 2 Jun 2021 12:50:26 +0800, Shenming Lu
wrote:
On 2021/6/2 1:33, Jason Gunthorpe wrote:
On Tue, Jun 01, 2021 at 08:30:35PM +0800, Lu Baolu wrote:
The drivers register per page table fault handlers to /dev/ioasid which
will then
在 2021/7/4 下午5:49, Yongji Xie 写道:
OK, I get you now. Since the VIRTIO specification says "Device
configuration space is generally used for rarely-changing or
initialization-time parameters". I assume the VDUSE_DEV_SET_CONFIG
ioctl should not be called frequently.
The spec uses MUST and other
在 2021/7/7 下午11:54, Stefan Hajnoczi 写道:
On Wed, Jul 07, 2021 at 05:24:08PM +0800, Jason Wang wrote:
在 2021/7/7 下午4:55, Stefan Hajnoczi 写道:
On Wed, Jul 07, 2021 at 11:43:28AM +0800, Jason Wang wrote:
在 2021/7/7 上午1:11, Stefan Hajnoczi 写道:
On Tue, Jul 06, 2021 at 09:08:26PM +0800, Jason Wang
在 2021/6/24 下午12:46, Yongji Xie 写道:
So we need to deal with both FEATURES_OK and reset, but probably not
DRIVER_OK.
OK, I see. Thanks for the explanation. One more question is how about
clearing the corresponding status bit in get_status() rather than
making set_status() fail. Since the spec
在 2021/6/23 下午1:50, Yongji Xie 写道:
On Wed, Jun 23, 2021 at 11:31 AM Jason Wang wrote:
在 2021/6/22 下午4:14, Yongji Xie 写道:
On Tue, Jun 22, 2021 at 3:50 PM Jason Wang wrote:
在 2021/6/22 下午3:22, Yongji Xie 写道:
We need fix a way to propagate the error to the userspace.
E.g if we want to stop
在 2021/7/1 下午6:26, Yongji Xie 写道:
On Thu, Jul 1, 2021 at 3:55 PM Jason Wang wrote:
在 2021/7/1 下午2:50, Yongji Xie 写道:
On Wed, Jun 30, 2021 at 5:51 PM Stefan Hajnoczi wrote:
On Tue, Jun 29, 2021 at 10:59:51AM +0800, Yongji Xie wrote:
On Mon, Jun 28, 2021 at 9:02 PM Stefan Hajnoczi wrote
在 2021/7/1 下午2:50, Yongji Xie 写道:
On Wed, Jun 30, 2021 at 5:51 PM Stefan Hajnoczi wrote:
On Tue, Jun 29, 2021 at 10:59:51AM +0800, Yongji Xie wrote:
On Mon, Jun 28, 2021 at 9:02 PM Stefan Hajnoczi wrote:
On Tue, Jun 15, 2021 at 10:13:30PM +0800, Xie Yongji wrote:
+/* ioctls */
+
+struct
在 2021/6/28 下午1:54, Liu, Xiaodong 写道:
Several issues:
- VDUSE needs to limit the total size of the bounce buffers (64M if I was not
wrong). Does it work for SPDK?
Yes, Jason. It is enough and works for SPDK.
Since it's a kind of bounce buffer mainly for in-flight IO, so limited size like
在 2021/6/29 上午11:56, Yongji Xie 写道:
On Tue, Jun 29, 2021 at 11:29 AM Jason Wang wrote:
在 2021/6/29 上午10:26, Yongji Xie 写道:
On Mon, Jun 28, 2021 at 12:40 PM Jason Wang wrote:
在 2021/6/25 下午12:19, Yongji Xie 写道:
2b) for set_status(): simply relay the message to userspace, reply
在 2021/6/29 上午10:26, Yongji Xie 写道:
On Mon, Jun 28, 2021 at 12:40 PM Jason Wang wrote:
在 2021/6/25 下午12:19, Yongji Xie 写道:
2b) for set_status(): simply relay the message to userspace, reply is no
needed. Userspace will use a command to update the status when the
datapath is stop
在 2021/6/28 下午6:32, Yongji Xie 写道:
The large barrier is bounce-buffer mapping: SPDK requires hugepages
for NVMe over PCIe and RDMA, so take some preallcoated hugepages to
map as bounce buffer is necessary. Or it's hard to avoid an extra
memcpy from bounce-buffer to hugepage.
If you can add an
在 2021/6/29 下午2:40, Yongji Xie 写道:
On Tue, Jun 29, 2021 at 12:13 PM Jason Wang wrote:
在 2021/6/28 下午6:32, Yongji Xie 写道:
The large barrier is bounce-buffer mapping: SPDK requires hugepages
for NVMe over PCIe and RDMA, so take some preallcoated hugepages to
map as bounce buffer is necessary
在 2021/7/5 下午8:49, Stefan Hajnoczi 写道:
On Mon, Jul 05, 2021 at 11:36:15AM +0800, Jason Wang wrote:
在 2021/7/4 下午5:49, Yongji Xie 写道:
OK, I get you now. Since the VIRTIO specification says "Device
configuration space is generally used for rarely-changing or
initialization-time parameter
在 2021/7/7 下午4:55, Stefan Hajnoczi 写道:
On Wed, Jul 07, 2021 at 11:43:28AM +0800, Jason Wang wrote:
在 2021/7/7 上午1:11, Stefan Hajnoczi 写道:
On Tue, Jul 06, 2021 at 09:08:26PM +0800, Jason Wang wrote:
On Tue, Jul 6, 2021 at 6:15 PM Stefan Hajnoczi wrote:
On Tue, Jul 06, 2021 at 10:34:33AM
1 - 100 of 148 matches
Mail list logo
