On Thu, Apr 30, 2020 at 07:03:21PM +0530, Srivatsa Vaddagiri wrote: > * Jan Kiszka <jan.kiszka@xxxxxxxxxxx> [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 data to read/write. > A > > >simple shared memory and doorbell or message-queue based transport will work for > > >us. > > > > As written in our private conversation, a mapping of the ivshmem2 device > > discovery to platform mechanism (device tree etc.) and maybe even the > > register access for doorbell and life-cycle management to something > > hypercall-like would be imaginable. What would count more from virtio > > perspective is a common mapping on a shared memory transport. > > Yes that sounds simpler for us. > > > That said, I also warned about all the features that PCI already defined > > (such as message-based interrupts) which you may have to add when going a > > different way for the shared memory device. > > Is it really required to present this shared memory as belonging to a PCI > device? But then you will go on and add MSI, and NUMA, and security, and and and ... > I would expect the device-tree to indicate the presence of this shared > memory region, which we should be able to present to ivshmem2 as shared memory > region to use (along with some handles for doorbell or message queue use). > > I understand the usefulness of modeling the shared memory as part of device so > that hypervisor can send events related to peers going down or coming up. In our > case, there will be other means to discover those events and avoiding this > requirement on hypervisor (to emulate PCI) will simplify the solution for us. > > Any idea when we can expect virtio over ivshmem2 to become available?! Check out the virtio spec. Right at the beginning it states: These devices are found in virtual environments, yet by design they look like physical devices to the guest within the virtual machine - and this document treats them as such. This similarity allows the guest to use standard drivers and discovery mechanisms > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization