virtio — archive

[PATCH v10 00/10] Introduce device group and device management

From: Cornelia Huck <[email protected]>
To: [email protected]
Date: Wed, 08 Mar 2023 16:31:00 -0000

On Mon, Mar 06 2023, "Michael S. Tsirkin" <[email protected]> wrote: > On Mon, Mar 06, 2023 at 01:29:30PM +0100, Jiri Pirko wrote: >> Thu, Mar 02, 2023 at 02:04:48PM CET, [email protected] wrote: >> >> [...] >> >> > >> >TODO (maybe?) - probably ok to defer until this part is upstream: >> > >> > Add "all members" member id. >> > >> > Add commands for MSI, feature discovery. >> > >> > Add commands for transport vq. >> > >> > >> >My intent is to try and support both SR-IOV and SIOV >> >usecases with the same structure and maybe even the same >> >VQ. >> >> Sorry to be late to the party, I'm trying to catch up. Is it common to >> have cover letter for features this brief? I mean, from the cover >> letter, I'm totally unable to understand what you are introducing here. >> >> Could you elaborate about what you are aiming to achive with this? >> Could you shed some usecases perhaps? >> >> I have to be missing something obvious, but I don't get why any notion >> of SR-IOV could be beneficial for virtio. >> > > Good point, I'll add a bit of motivation. > > For SR-IOV, it is not unusual for PFs to excercise control over VFs. > There is interest in the community to include an interface to allow this > in the virtio spec, when the PF is a virtio device. This is what this > patch does. Unfortunately, information in the cover letter does not make it into git -- should things like that go into the github issue (and into the ballot?) It's useful both for reviewing (cover letter) and understanding the rationale later (github/ballot).