KVM Archive on lore.kernel.org
 help / color / Atom feed
* mdevctl: A shoestring mediated device management and persistence utility
@ 2019-05-23 23:20 Alex Williamson
  2019-05-24 10:11 ` Cornelia Huck
                   ` (3 more replies)
  0 siblings, 4 replies; 46+ messages in thread
From: Alex Williamson @ 2019-05-23 23:20 UTC (permalink / raw)
  To: kvm
  Cc: Libvirt Devel, Kirti Wankhede, Erik Skultety, Pavel Hrdina,
	Daniel P. Berrangé,
	Sylvain Bauza, Cornelia Huck

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'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 ;)  Thanks,

Alex

^ permalink raw reply	[flat|nested] 46+ messages in thread

end of thread, back to index

Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-23 23:20 mdevctl: A shoestring mediated device management and persistence utility Alex Williamson
2019-05-24 10:11 ` Cornelia Huck
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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org kvm@archiver.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox