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

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

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

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 Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote: > That would still not work I think where swiotlb is used for pass-thr devices > (when private memory is fine) as well as virtio devices (when shared memory is > required). So that is a separate question. When there are multiple untrusted devices, at the moment it looks like a single bounce buffer is used. Which to me

On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote: > That would still not work I think where swiotlb is used for pass-thr devices > (when private memory is fine) as well as virtio devices (when shared memory is > required). So that is a separate question. When there are multiple untrusted devices, at the moment it looks like a single bounce buffer is used. Which to me

On Wed, Apr 29, 2020 at 12:26:43PM +0200, Jan Kiszka wrote: > On 29.04.20 12:20, Michael S. Tsirkin wrote: > > On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote: > > > That would still not work I think where swiotlb is used for pass-thr devices > > > (when private memory is fine) as well as virtio devices (when shared memory is > > > required).

On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: > * Michael S. Tsirkin <mst at redhat.com> [2020-04-28 12:17:57]: > > > Okay, but how is all this virtio specific? For example, why not allow > > separate swiotlbs for any type of device? > > For example, this might make sense if a given device is from a > > different, less trusted vendor.

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

On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote: > On 2020/4/29 4:41, Michael S. Tsirkin wrote: > > On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: > > > * Michael S. Tsirkin<mst at redhat.com> [2020-04-28 12:17:57]: > > > > > > > Okay, but how is all this virtio specific? For example, why not allow > > > >

On Wed, Apr 29, 2020 at 03:14:10PM +0530, Srivatsa Vaddagiri wrote: > * Michael S. Tsirkin <mst at redhat.com> [2020-04-29 02:50:41]: > > > So it seems that with modern Linux, all one needs > > to do on x86 is mark the device as untrusted. > > It's already possible to do this with ACPI and with OF - would that be > > sufficient for achieving what this

On 29.04.20 12:20, Michael S. Tsirkin wrote: > On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote: >> That would still not work I think where swiotlb is used for pass-thr devices >> (when private memory is fine) as well as virtio devices (when shared memory is >> required). > > So that is a separate question. When there are multiple untrusted >

On Wed, Apr 29, 2020 at 01:42:13PM +0800, Lu Baolu wrote: > On 2020/4/29 12:57, Michael S. Tsirkin wrote: > > On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote: > > > On 2020/4/29 4:41, Michael S. Tsirkin wrote: > > > > On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: > > > > > * Michael S. Tsirkin<mst at redhat.com>

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e commit: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e [12/12] vhost: use vhost_desc instead of vhost_log reproduce: # apt-get install sparse # sparse version: v0.6.1-101-g82dee2e-dirty git checkout b072ae74df177c3ad7704c5fbe66e3f10aad9d4e make

On 07.02.23 22:09, Srivatsa S. Bhat wrote: > On 2/6/23 11:59 PM, Juergen Gross wrote: >> The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are >> sharing the same implementations in all cases: for Xen PV guests they >> are pinning the PGD of the new mm_struct, and for all other cases >> they are a NOP. >> >> In the end both callbacks are meant to

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the extra call to preempt_enable() added by commit 41bd956 (xen/smp: Fix

xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. Getting rid of xen_play_dead()'s dependency on cpu_bringup() helps in hooking on to the generic SMP booting framework. Also remove the extra call to preempt_enable() added by commit 41bd956 (xen/smp: Fix

I''ve been banging my head against this wall for several hours, and it hurts now so I''ll stop and ask someone. In one of my forms I had been using a statement to extract the current year for use with some form field calculations. <% currentyear = DateTime.now.year %> And then further down several date_selects like the following, <%= date_select