similar to: [RFC/PATCH 1/1] virtio: Introduce MMIO ops

On Thu, Apr 30, 2020 at 04:04:46PM +0530, Srivatsa Vaddagiri wrote: > * Will Deacon <will at kernel.org> [2020-04-30 11:14:32]: > > > > +#ifdef CONFIG_VIRTIO_MMIO_OPS > > > > > > +static struct virtio_mmio_ops *mmio_ops; > > > + > > > +#define virtio_readb(a) mmio_ops->mmio_readl((a)) > > > +#define virtio_readw(a)

On Thu, Apr 30, 2020 at 07:03:21PM +0530, Srivatsa Vaddagiri wrote: > * Jan Kiszka <jan.kiszka at siemens.com> [2020-04-30 14:59:50]: > > > >I believe ivshmem2_virtio requires hypervisor to support PCI device emulation > > >(for life-cycle management of VMs), which our hypervisor may not support. PCI is mostly just 2 registers. One sets the affected device, one the

On Thu, Apr 30, 2020 at 03:32:56PM +0530, Srivatsa Vaddagiri wrote: > Some hypervisors may not support MMIO transport i.e trap config > space access and have it be handled by backend driver. They may > allow other ways to interact with backend such as message-queue > or doorbell API. This patch allows for hypervisor specific > methods for config space IO. > > Signed-off-by:

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

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? -- MST

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. > [1] summarizes some of the problems we have in making virtio work on such > hypervisors. This patch proposes a solution for transport problem viz how we can > do config space IO on such a hypervisor. Hypervisor specific methods >

Hi Vatsa, On Thu, Apr 30, 2020 at 03:59:39PM +0530, Srivatsa Vaddagiri wrote: > * Will Deacon <will at kernel.org> [2020-04-30 11:08:22]: > > > > This patch is meant to seek comments. If its considered to be in right > > > direction, will work on making it more complete and send the next version! > > > > What's stopping you from implementing the

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).

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

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

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, 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.

This series forms the kvm host part of paravirtual spinlock based against kvm tree. Please refer to https://lkml.org/lkml/2013/8/9/265 for kvm guest and Xen, x86 part merged to -tip spinlocks. Please note that: kvm uapi: Add KICK_CPU and PV_UNHALT definition to uapi is a common patch for both guest and host. Changes since V12: fold the patch 3 into patch 2 for bisection. (Eric Northup)

This series forms the kvm host part of paravirtual spinlock based against kvm tree. Please refer to https://lkml.org/lkml/2013/8/9/265 for kvm guest and Xen, x86 part merged to -tip spinlocks. Please note that: kvm uapi: Add KICK_CPU and PV_UNHALT definition to uapi is a common patch for both guest and host. Changes since V12: fold the patch 3 into patch 2 for bisection. (Eric Northup)

On Mon, Aug 26, 2013 at 02:18:32PM +0530, Raghavendra K T wrote: > > This series forms the kvm host part of paravirtual spinlock > based against kvm tree. > > Please refer to https://lkml.org/lkml/2013/8/9/265 for > kvm guest and Xen, x86 part merged to -tip spinlocks. > > Please note that: > kvm uapi: Add KICK_CPU and PV_UNHALT definition to uapi is a common

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 > > > >