From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id D61EA9865B6 for ; Thu, 12 Jan 2023 14:31:10 +0000 (UTC) From: Cornelia Huck In-Reply-To: <1673524110.7417235-2-xuanzhuo@linux.alibaba.com> References: <20221223081354.15026-1-xuanzhuo@linux.alibaba.com> <20221223081354.15026-2-xuanzhuo@linux.alibaba.com> <20230110233401.131cc97a.pasic@linux.ibm.com> <1673435333.1297436-1-xuanzhuo@linux.alibaba.com> <20230111161128.48e6d7e0.pasic@linux.ibm.com> <20230112014722-mutt-send-email-mst@kernel.org> <87zgaocffm.fsf@redhat.com> <1673524110.7417235-2-xuanzhuo@linux.alibaba.com> Date: Thu, 12 Jan 2023 15:30:58 +0100 Message-ID: <87r0vzddul.fsf@redhat.com> MIME-Version: 1.0 Subject: Re: [virtio-dev] [PATCH v2 1/1] virtio-ism: introduce new device virtio-ism Content-Type: text/plain To: Xuan Zhuo Cc: Halil Pasic , virtio-dev@lists.oasis-open.org, hans@linux.alibaba.com, herongguang@linux.alibaba.com, zmlcc@linux.alibaba.com, dust.li@linux.alibaba.com, tonylu@linux.alibaba.com, zhenzao@linux.alibaba.com, helinguo@linux.alibaba.com, gerry@linux.alibaba.com, Jan Kiszka , wintera@linux.ibm.com, kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com, hca@linux.ibm.com, twinkler@linux.ibm.com, raspl@linux.ibm.com, "Michael S. Tsirkin" , Jason Wang List-ID: On Thu, Jan 12 2023, Xuan Zhuo wrote: > On Thu, 12 Jan 2023 09:42:05 +0100, Cornelia Huck wrote: >> On Thu, Jan 12 2023, "Michael S. Tsirkin" wrote: >> >> > On Thu, Jan 12, 2023 at 10:01:25AM +0800, Jason Wang wrote: >> >> On Wed, Jan 11, 2023 at 11:11 PM Halil Pasic wrote: >> >> > >> >> > On Wed, 11 Jan 2023 19:08:53 +0800 >> >> > Xuan Zhuo wrote: >> >> > >> >> > > > > +ISM(Internal Shared Memory) device provides the ability to share memory between >> >> > > > > +different VMs launched from the same entity. >> >> > > > >> >> > > > Launched by instead of from? Maybe introduce a catchy name for the >> >> > > > "entity that launched the VMs" and prevent oversimplification by >> >> > > > explaining any shortcomings of the name if any in one place. Host would >> >> > > > be one candidate, VMM another. >> >> > > >> >> > > Cornelia Huck wrote: >> >> > > >> >> > > Is there a way to avoid the term "host" (throughout this document)? >> >> > > IIUC, you need the uniqueness within the scope of the entity that >> >> > > launches the different instances that get shared access to the regions >> >> > > (which could conceivably a unit of hardware?) >> >> > > >> >> > > And I think she is right, so I am trying to remove the term HOST. >> >> > > >> >> > > Do you have better opinions? I think VMM is not particularly suitable. >> > >> > I think fundamentally from spec POV memory is shared between devices. >> > How sharing is accomplished guest does not care so neither should the >> > spec. Can some RDMA tricks be used for synchronisation behind the >> > scenes? Maybe, the spec does not care. But we can give an example. >> > >> > So something like: >> > >> > An ISM(Internal Shared Memory) device provides the ability to >> > access memory shared between multiple devices. This allows low-overhead >> > communication in presence of such memory. For example, memory can be >> > shared with guests of multiple virtual machines running on the same >> > host, with each virtual machine including an ISM device and with >> > the guests using the ISM devices to access the shared memory. >> > >> > what do others think? >> >> I like that: we don't want to talk about hosts/VMMs/etc. as we >> fundamentally deal with devices and drivers, but sharing between guests >> is of course the obvious use case. >> >> I'm just wondering how best to express the uniqueness scope, is it per >> (ISM) device? > > No, each vm has at least one separate device. The devices in a host form > an uniqueness scope. Should we call it a 'group', then? A host would be an example of such a group. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org