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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.