From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, libvir-list@redhat.com,
Matthew Rosato <mjrosato@linux.ibm.com>,
Tony Krowiak <akrowiak@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [PATCH RFC 1/1] allow to specify additional config data
Date: Tue, 18 Jun 2019 17:11:54 +0200 [thread overview]
Message-ID: <20190618171154.3828eb6b.cohuck@redhat.com> (raw)
In-Reply-To: <20190606101552.6fc62bef@x1.home>
On Thu, 6 Jun 2019 10:15:52 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Thu, 6 Jun 2019 09:32:24 -0600
> Alex Williamson <alex.williamson@redhat.com> wrote:
>
> > On Thu, 6 Jun 2019 16:44:17 +0200
> > Cornelia Huck <cohuck@redhat.com> wrote:
> >
> > > Add a rough implementation for vfio-ap.
> > >
> > > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > > ---
> > > mdevctl.libexec | 25 ++++++++++++++++++++++
> > > mdevctl.sbin | 56 ++++++++++++++++++++++++++++++++++++++++++++++++-
> > > 2 files changed, 80 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mdevctl.libexec b/mdevctl.libexec
> > > index 804166b5086d..cc0546142924 100755
> > > --- a/mdevctl.libexec
> > > +++ b/mdevctl.libexec
> > > @@ -54,6 +54,19 @@ wait_for_supported_types () {
> > > fi
> > > }
> > >
> > > +# configure vfio-ap devices <config entry> <matrix attribute>
> > > +configure_ap_devices() {
> > > + list="`echo "${config[$1]}" | sed 's/,/ /'`"
> > > + [ -z "$list" ] && return
> > > + for a in $list; do
> > > + echo "$a" > "$supported_types/${config[mdev_type]}/devices/$uuid/$2"
> > > + if [ $? -ne 0 ]; then
> > > + echo "Error writing '$a' to '$uuid/$2'" >&2
> > > + exit 1
> > > + fi
> > > + done
> > > +}
> > > +
> > > case ${1} in
> > > start-mdev|stop-mdev)
> > > if [ $# -ne 2 ]; then
> > > @@ -148,6 +161,18 @@ case ${cmd} in
> > > echo "Error creating mdev type ${config[mdev_type]} on $parent" >&2
> > > exit 1
> > > fi
> > > +
> > > + # some types may specify additional config data
> > > + case ${config[mdev_type]} in
> > > + vfio_ap-passthrough)
> >
> > I think this could have some application beyond ap too, I know NVIDIA
> > GRID vGPUs do have some controls under the vendor hierarchy of the
> > device, ex. setting the frame rate limiter. The implementation here is
> > a bit rigid, we know a specific protocol for a specific mdev type, but
> > for supporting arbitrary vendor options we'd really just want to try to
> > apply whatever options are provided. If we didn't care about ordering,
> > we could just look for keys for every file in the device's immediate
> > sysfs hierarchy and apply any value we find, independent of the
> > mdev_type, ex. intel_vgpu/foo=bar Thanks,
>
> For example:
>
> for key in find -P $mdev_base/$uuid/ \( -path
> "$mdev_base/$uuid/power/*" -o -path $mdev_base/$uuid/uevent -o -path $mdev_base/$uuid/remove \) -prune -o -type f -print | sed -e "s|$mdev_base/$uuid/||g"); do
> [ -z ${config[$key]} ] && continue
> ... parse value(s) and iteratively apply to key
> done
>
> The find is a little ugly to exclude stuff, maybe we just let people do
> screwy stuff like specify remove=1 in their config. Also need to think
> about whether we're imposing a delimiter to apply multiple values to a
> key that conflicts with the attribute usage. Thanks,
>
> Alex
Hm, so I tried to write something like that, but there's an obvious
drawback for the vfio-ap use case: we want to specify a list of values
to be written to an attribute. We would have to model that as a list of
key=value pairs; but that would make it harder to remove a specific
value. (I currently overwrite a given key=value pair with a new value
or delete it.) We could specify something like ^key=value to cancel out
key=value.
Does it make sense to write *all* values specified for a specific key
to that attribute in sequence, or may this have surprising
consequences? Can we live with those possible surprises?
>
> > > + configure_ap_devices ap_adapters assign_adapter
> > > + configure_ap_devices ap_domains assign_domain
> > > + configure_ap_devices ap_control_domains assign_control_domain
> > > + # TODO: is assigning idempotent? Should we unwind on error?
> > > + ;;
> > > + *)
> > > + ;;
> > > + esac
> > > ;;
> > >
> > > add-mdev)
next prev parent reply other threads:[~2019-06-18 15:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 14:44 [PATCH RFC 0/1] mdevctl: further config for vfio-ap Cornelia Huck
2019-06-06 14:44 ` [PATCH RFC 1/1] allow to specify additional config data Cornelia Huck
2019-06-06 15:32 ` Alex Williamson
2019-06-06 16:15 ` Alex Williamson
2019-06-07 18:26 ` Tony Krowiak
2019-06-07 20:03 ` Alex Williamson
2019-06-11 14:19 ` Tony Krowiak
2019-06-13 14:18 ` Cornelia Huck
2019-06-14 13:24 ` Tony Krowiak
2019-06-18 15:11 ` Cornelia Huck [this message]
2019-06-13 15:56 ` Halil Pasic
2019-06-06 16:45 ` [PATCH RFC 0/1] mdevctl: further config for vfio-ap Matthew Rosato
2019-06-07 14:56 ` Cornelia Huck
2019-06-07 18:30 ` Tony Krowiak
2019-06-13 13:54 ` Cornelia Huck
2019-06-13 14:25 ` Matthew Rosato
2019-06-14 13:36 ` Tony Krowiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190618171154.3828eb6b.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox