Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
"Zhu, Lingshan" <[email protected]>
| Newsgroups | dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment |
|---|---|
| Message-ID | <[email protected]> |
On 9/27/2023 6:39 PM, Parav Pandit wrote: > >> From: Zhu, Lingshan <[email protected]> >> Sent: Wednesday, September 27, 2023 1:50 PM >> I see his proposal can: >> 1) meet some customers requirements without nested and bare-metal >> 2) align with Nvidia production > Slightly inaccurate. > The work produced is for the virtio spec update for the users. > > I have missed adding other contributors Sign-off who also share similar use cases, which I will add in v1. > >> 3) easier to emulate by onboard SOC >> >> The general purpose of his proposal and mine are aligned: migrate virtio >> devices. >> > Great. > >> Jason has ever proposed to collaborate, please allow me quote his proposal: >> >> " >> Let me repeat once again here for the possible steps to collaboration: >> >> 1) define virtqueue state, inflight descriptors in the section of >> basic facility but not under the admin commands >> 2) define the dirty page tracking, device context/states in the >> section of basic facility but not under the admin commands >> 3) define transport specific interfaces or admin commands to access them >> " >> >> I totally agree with his proposal. > We started discussing some of the it. > If I draw parallels, one should not say "detach descriptors from virtqueue" for the infrastructure that exists in the basic facilities. > If so, one should explain the technical design reason and it would make sense. not sure what is "detach descriptors from virtqueue", but admin vq carries commands anyway. > > So let's discuss it. > I like to better understand the _real_ technical reason for detaching it. so please to or cc me in your series. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]