similar to: [PATCH 5/5] virtio: Add bounce DMA ops

On Tue, Apr 28, 2020 at 05:09:18PM +0530, Srivatsa Vaddagiri wrote: > For better security, its desirable that a guest VM's memory is > not accessible to any entity that executes outside the context of > guest VM. In case of virtio, backend drivers execute outside the > context of guest VM and in general will need access to complete > guest VM memory. One option to restrict the

On Tue, 28 Apr 2020, Srivatsa Vaddagiri wrote: > For better security, its desirable that a guest VM's memory is > not accessible to any entity that executes outside the context of > guest VM. In case of virtio, backend drivers execute outside the > context of guest VM and in general will need access to complete > guest VM memory. One option to restrict the access provided to

Hi Srivatsa, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on vhost/linux-next] [also build test WARNING on xen-tip/linux-next linus/master v5.7-rc3 next-20200428] [cannot apply to swiotlb/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify

Hi Srivatsa, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on vhost/linux-next] [also build test WARNING on xen-tip/linux-next linus/master v5.7-rc3 next-20200428] [cannot apply to swiotlb/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify

Signed-off-by: kbuild test robot <lkp at intel.com> --- virtio_bounce.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/virtio/virtio_bounce.c b/drivers/virtio/virtio_bounce.c index 3de8e0eb71e48..5a68d48667c42 100644 --- a/drivers/virtio/virtio_bounce.c +++ b/drivers/virtio/virtio_bounce.c @@ -19,7 +19,7 @@ static phys_addr_t bounce_buf_paddr; static

From: Erwan Yvin <erwan.yvin at stericsson.com> Add the CAIF Virtio shared memory driver for talking to a modem. This CAIF Link layer communicates to the modem over shared memory. It is implemented as a virtio_driver. The underlying virtio device is managed by the remoteproc framework. The Virtio queue is used for transmitting data to the modem, and the new vringh is used for receiving

From: Erwan Yvin <erwan.yvin at stericsson.com> Add the CAIF Virtio shared memory driver for talking to a modem. This CAIF Link layer communicates to the modem over shared memory. It is implemented as a virtio_driver. The underlying virtio device is managed by the remoteproc framework. The Virtio queue is used for transmitting data to the modem, and the new vringh is used for receiving

Hi All, I am adding ip_queue module for snort inline IDS. I am using snort2.4.0 And iptables-1.3.4. Userspace Queuing(queue target) is enabled. It is built-in and not built as a module. The output of /proc/net/ip_queue is shown below: cat /proc/net/ip_queue> Peer PID : 0 Copy mode : 0 Copy range : 0 Queue length : 0 Queue max. length : 1024 IPTABLES 1.3.4 is

--mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I have released Version 1.01 of the iptables userspace logging daemon (ulogd).=20 The new Version is available as tar.bz2 only and can be retrieved from: ftp://ftp.netfilter.org/pub/ulogd/ulogd-1.01.tar.bz2 There is a GPG signature for verification of the

Hi Srivatsa, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on xen-tip/linux-next linus/master v5.7-rc3 next-20200429] [cannot apply to swiotlb/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base

Hi Srivatsa, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on xen-tip/linux-next linus/master v5.7-rc3 next-20200428] [cannot apply to swiotlb/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base

On Tue, Jan 24, 2017 at 04:10:46PM -0500, David Miller wrote: > This works in the regimen that XDP packets always live in exactly one > page. That will be needed to mmap the RX ring into userspace, and it > helps make adjust_header trivial as well. I think the point was to avoid resets across xdp attach/detach. If we are doing resets now, we could do whatever buffering we want. We

On Tue, Jan 24, 2017 at 04:10:46PM -0500, David Miller wrote: > This works in the regimen that XDP packets always live in exactly one > page. That will be needed to mmap the RX ring into userspace, and it > helps make adjust_header trivial as well. I think the point was to avoid resets across xdp attach/detach. If we are doing resets now, we could do whatever buffering we want. We

On Tue, Jan 24, 2017 at 03:53:31PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" <mst at redhat.com> > Date: Tue, 24 Jan 2017 22:45:37 +0200 > > > On Tue, Jan 24, 2017 at 03:09:59PM -0500, David Miller wrote: > >> From: "Michael S. Tsirkin" <mst at redhat.com> > >> Date: Tue, 24 Jan 2017 21:53:13 +0200 > >> >

On Tue, Jan 24, 2017 at 03:53:31PM -0500, David Miller wrote: > From: "Michael S. Tsirkin" <mst at redhat.com> > Date: Tue, 24 Jan 2017 22:45:37 +0200 > > > On Tue, Jan 24, 2017 at 03:09:59PM -0500, David Miller wrote: > >> From: "Michael S. Tsirkin" <mst at redhat.com> > >> Date: Tue, 24 Jan 2017 21:53:13 +0200 > >> >

https://bugzilla.netfilter.org/show_bug.cgi?id=1218 Bug ID: 1218 Summary: ULOGD PCAP Plugin Missing Ethernet Headers Product: ulogd Version: SVN (please provide timestamp) Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 Component: ulogd Assignee:

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Tue, 24 Jan 2017 23:07:51 +0200 > On Tue, Jan 24, 2017 at 03:53:31PM -0500, David Miller wrote: >> From: "Michael S. Tsirkin" <mst at redhat.com> >> Date: Tue, 24 Jan 2017 22:45:37 +0200 >> >> > On Tue, Jan 24, 2017 at 03:09:59PM -0500, David Miller wrote: >> >> From:

On Tue, Jan 24, 2017 at 08:07:40PM -0800, Alexei Starovoitov wrote: > On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend > <john.fastabend at gmail.com> wrote: > > > > It is a concern on my side. I want XDP and Linux stack to work > > reasonably well together. > > btw the micro benchmarks showed that page per packet approach > that xdp took in mlx4 should be

Hello All: I've been requested to add some TCP tuning parameters to some CentOS 5.4 systems. These tunings are for the TCP receive buffer windows: net.core.rmem_max net.core.wmem_max Information on this tuning is broadly available: http://fasterdata.es.net/TCP-tuning/linux.html http://www.speedguide.net/read_articles.php?id=121 Potential downsides are available:

Ok so maybe someone can explain this to me. I've been banging my head against the wall on this one for several weeks now and the powers that be are starting to get a little impatient. What we've got is an old FoxPro application, the FoxPro .dbf's being stored on a Linux fileserver using Samba (Fedora 3 currently, using Fedora 5 on the new test server). We're having speed