From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Libvirt Devel" <libvir-list@redhat.com>,
"Kirti Wankhede" <kwankhede@nvidia.com>,
"Erik Skultety" <eskultet@redhat.com>,
"Pavel Hrdina" <phrdina@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Sylvain Bauza" <sbauza@redhat.com>
Subject: Re: mdevctl: A shoestring mediated device management and persistence utility
Date: Fri, 24 May 2019 12:11:06 +0200 [thread overview]
Message-ID: <20190524121106.16e08562.cohuck@redhat.com> (raw)
In-Reply-To: <20190523172001.41f386d8@x1.home>
On Thu, 23 May 2019 17:20:01 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> Hi,
>
> Currently mediated device management, much like SR-IOV VF management,
> is largely left as an exercise for the user. This is an attempt to
> provide something and see where it goes. I doubt we'll solve
> everyone's needs on the first pass, but maybe we'll solve enough and
> provide helpers for the rest. Without further ado, I'll point to what
> I have so far:
>
> https://github.com/awilliam/mdevctl
>
> This is inspired by driverctl, which is also a bash utility. mdevctl
> uses udev and systemd to record and recreate mdev devices for
> persistence and provides a command line utility for querying, listing,
> starting, stopping, adding, and removing mdev devices. Currently, for
> better or worse, it considers anything created to be persistent. I can
> imagine a global configuration option that might disable this and
> perhaps an autostart flag per mdev device, such that mdevctl might
> simply "know" about some mdevs but not attempt to create them
> automatically. Clearly command line usage help, man pages, and
> packaging are lacking as well, release early, release often, plus this
> is a discussion starter to see if perhaps this is sufficient to meet
> some needs.
>
> Originally I thought about making a utility to manage both mdev and
> SR-IOV VFs all in one, but it seemed more natural to start here
> (besides, I couldn't think of a good name for the combined utility).
> If this seems useful, maybe I'll start on a vfctl for SR-IOV and we'll
> see whether they have enough synergy to become one.
>
> It would be really useful if s390 folks could help me understand
> whether it's possible to glean all the information necessary to
> recreate a ccw or ap mdev device from sysfs. I expect the file where
> we currently only store the mdev_type to evolve into something that
> includes more information to facilitate more complicated devices. For
> now I make no claims to maintaining compatibility of recorded mdev
> devices, it will absolutely change, but I didn't want to get bogged
> down in making sure I don't accidentally source a root kit hidden in an
> mdev config file.
I played a bit with it on my LPAR, and it is at least not obviously
broken with vfio-ccw :) I don't have any ap devices to play with,
though.
>
> I'm also curious how or if libvirt or openstack might use this. If
> nothing else, it makes libvirt hook scripts easier to write, especially
> if we add an option not to autostart mdevs, or if users don't mind
> persistent mdevs, maybe there's nothing more to do.
>
> BTW, feel free to clean up by bash, I'm a brute force and ignorance
> shell coder ;)
Not that I'm a good shell coder, but I sent you a pull req at least
adding a basic help text ;)
I have not yet looked at most of the code, though.
> Thanks,
>
> Alex
next prev parent reply other threads:[~2019-05-24 10:11 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 23:20 mdevctl: A shoestring mediated device management and persistence utility Alex Williamson
2019-05-24 10:11 ` Cornelia Huck [this message]
2019-05-24 14:43 ` Alex Williamson
2019-06-07 16:06 ` Halil Pasic
2019-06-11 19:45 ` Cornelia Huck
2019-06-11 20:28 ` Alex Williamson
2019-06-12 7:14 ` Cornelia Huck
2019-06-12 15:54 ` Halil Pasic
2019-06-13 10:02 ` Cornelia Huck
2019-06-12 15:07 ` Halil Pasic
2019-06-13 16:17 ` Christophe de Dinechin
2019-06-13 16:35 ` Alex Williamson
2019-06-14 9:54 ` [libvirt] " Christophe de Dinechin
2019-06-14 14:23 ` Alex Williamson
2019-06-14 15:06 ` Christophe de Dinechin
2019-06-14 16:04 ` Alex Williamson
2019-06-17 16:03 ` Cornelia Huck
2019-06-17 14:00 ` Daniel P. Berrangé
2019-06-17 14:54 ` Alex Williamson
2019-06-17 15:10 ` Daniel P. Berrangé
2019-06-17 17:05 ` Alex Williamson
2019-06-18 8:44 ` Daniel P. Berrangé
2019-06-18 11:01 ` Cornelia Huck
[not found] ` <CALOCmukPWiXiM+mN0hCTvSwfdHy5UdERU8WnvOXiBrMQ9tH3VA@mail.gmail.com>
2019-06-18 22:12 ` Alex Williamson
2019-06-19 7:28 ` Daniel P. Berrangé
2019-06-19 9:46 ` Cornelia Huck
2019-06-19 18:46 ` Alex Williamson
2019-06-20 8:24 ` Daniel P. Berrangé
[not found] ` <CALOCmu=6Xmw-_-SVXujCEcgPY2CQiBQKgfUMJ45WnZ_9XORyUw@mail.gmail.com>
2019-06-19 9:57 ` Cornelia Huck
2019-06-19 19:53 ` Alex Williamson
2019-06-25 22:52 ` Alex Williamson
2019-06-26 9:58 ` Cornelia Huck
2019-06-26 14:37 ` Alex Williamson
2019-06-27 1:53 ` Alex Williamson
2019-06-27 12:26 ` Cornelia Huck
2019-06-27 15:00 ` Matthew Rosato
2019-06-27 15:38 ` Alex Williamson
2019-06-27 16:13 ` Matthew Rosato
2019-06-27 21:15 ` Alex Williamson
2019-06-28 1:57 ` Alex Williamson
2019-06-28 9:06 ` Cornelia Huck
2019-06-28 14:01 ` Matthew Rosato
2019-06-28 17:05 ` Alex Williamson
2019-07-01 8:20 ` Cornelia Huck
2019-07-01 14:40 ` Alex Williamson
2019-07-01 17:13 ` Cornelia Huck
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=20190524121106.16e08562.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=berrange@redhat.com \
--cc=eskultet@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=libvir-list@redhat.com \
--cc=phrdina@redhat.com \
--cc=sbauza@redhat.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.