On Mon, Apr 10, 2023 at 10:01 AM Xuan Zhuo <[email protected]> wrote: > > On Mon, 10 Apr 2023 09:23:04 +0800, Jason Wang <[email protected]> wrote: > > On Fri, Apr 7, 2023 at 11:24 AM Xuan Zhuo <[email protected]> > > wrote: > > > > > > On Wed, 5 Apr 2023 08:52:14 -0400, "Michael S. Tsirkin" <[email protected]> > > > wrote: > > > > On Wed, Apr 05, 2023 at 02:39:53PM +0200, Alexandra Winter wrote: > > > > > > > > > > > > > > > On 24.03.23 05:03, Wen Gu wrote: > > > > > > > > > > > > > > > > > > On 2023/3/23 22:46, Halil Pasic wrote: > > > > > > > > > > > >> On Thu, 9 Feb 2023 11:30:56 +0800 > > > > > >> Xuan Zhuo <[email protected]> wrote: > > > > > >> > > > > > > > > > > ... > > > > > > > > > > > > > > > > >> To get back to the things proposed here: the cdid is IMHO > > > > > >> a nice thing, and is functionally corresponding to the > > > > > >> (S)EID. But it is 16 byte wide, and I have no idea how > > > > > >> is it supposed to be used in the CLC handshake. > > > > > >> > > > > > > > > > > > > CLC handshake carry one SEID for all the SMC-D device. Considering > > > > > > coexistence with ISM, I am not sure whether we can change or > > > > > > increase > > > > > > the SEID.. cc Alexandra > > > > > > > > > > > > Thanks! > > > > > > Wen Gu > > > > > > > > > > As mentioned by others, discussions are ongoing. > > > > > It would be great, if we can agree on a way to use the existing CLC > > > > > handshake > > > > > for SMC-D via virtio-ism and ism-loopback. > > > > > In that case SEID needs to be unique per hardware instance, cannot be > > > > > increased and > > > > > can only be changed for x86 in a non-colliding way. > > > > > > > > > > An alternative would be to define new a SMC-D(?) protocol > > > > > variant/version, where we > > > > > are free to define new fields (e.g. UUIDs). > > > > > > > > > > Alexandra > > > > > > > > Problem with tying to hardware is that it is blocking > > > > migration (which is a challenge with ism anyway, but still). > > > > > > > > > We don't want to support migration. At least we don't want to support it > > > for the > > > time being. Because there are indeed many problems. I think Migration is > > > not > > > necessary for a new Virtio device. > > > > We'd really need to take migration into consideration when developing > > new devices. It is not guaranteed that this device is backed by local > > RAMs. > > Yes, we have some considerations and researches on the aspects also, such as > CXL. > > We have not planned introducing these in SPEC directly, because we dont even > have a POC. It's just that there are researches in this area and we haven't > actually operated it.
Good to know that. > > > At least we should avoid designs that may complicate future > > migration support. > > Yes, we try to avoid it. If you find that we have this problem, you are > welcome > to point out. That's fine, this device is really interesting (but I haven't had time in going though this again). Thanks > > Thanks. > > > > > > Thanks > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > >> If this is really supposed to work with SMC and not just take > > > > > >> inspiration from it, I would like some insight from our > > > > > >> SMC experts (they are already on copy). > > > > > >> > > > > > >> Regards, > > > > > >> Halil > > > > > >> > > > > > >> --------------------------------------------------------------------- > > > > > >> To unsubscribe, e-mail: [email protected] > > > > > >> For additional commands, e-mail: > > > > > >> [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > This publicly archived list offers a means to provide input to the > > > OASIS Virtual I/O Device (VIRTIO) TC. > > > > > > In order to verify user consent to the Feedback License terms and > > > to minimize spam in the list archive, subscription is required > > > before posting. > > > > > > Subscribe: [email protected] > > > Unsubscribe: [email protected] > > > List help: [email protected] > > > List archive: https://lists.oasis-open.org/archives/virtio-comment/ > > > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf > > > List Guidelines: > > > https://www.oasis-open.org/policies-guidelines/mailing-lists > > > Committee: https://www.oasis-open.org/committees/virtio/ > > > Join OASIS: https://www.oasis-open.org/join/ > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
