<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 18, 2019 at 1:01 PM Cornelia Huck <<a href="mailto:cohuck@redhat.com">cohuck@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 17 Jun 2019 11:05:17 -0600<br>
Alex Williamson <<a href="mailto:alex.williamson@redhat.com" target="_blank">alex.williamson@redhat.com</a>> wrote:<br>
<br>
> On Mon, 17 Jun 2019 16:10:30 +0100<br>
> Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
> <br>
> > On Mon, Jun 17, 2019 at 08:54:38AM -0600, Alex Williamson wrote:  <br>
> > > On Mon, 17 Jun 2019 15:00:00 +0100<br>
> > > Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
> > >     <br>
> > > > On Thu, May 23, 2019 at 05:20:01PM -0600, Alex Williamson wrote:    <br>
> > > > > Hi,<br>
> > > > > <br>
> > > > > Currently mediated device management, much like SR-IOV VF management,<br>
> > > > > is largely left as an exercise for the user.  This is an attempt to<br>
> > > > > provide something and see where it goes.  I doubt we'll solve<br>
> > > > > everyone's needs on the first pass, but maybe we'll solve enough and<br>
> > > > > provide helpers for the rest.  Without further ado, I'll point to what<br>
> > > > > I have so far:<br>
> > > > > <br>
> > > > > <a href="https://github.com/awilliam/mdevctl" rel="noreferrer" target="_blank">https://github.com/awilliam/mdevctl</a><br>
> > > > > <br>
> > > > > This is inspired by driverctl, which is also a bash utility.  mdevctl<br>
> > > > > uses udev and systemd to record and recreate mdev devices for<br>
> > > > > persistence and provides a command line utility for querying, listing,<br>
> > > > > starting, stopping, adding, and removing mdev devices.  Currently, for<br>
> > > > > better or worse, it considers anything created to be persistent.  I can<br>
> > > > > imagine a global configuration option that might disable this and<br>
> > > > > perhaps an autostart flag per mdev device, such that mdevctl might<br>
> > > > > simply "know" about some mdevs but not attempt to create them<br>
> > > > > automatically.  Clearly command line usage help, man pages, and<br>
> > > > > packaging are lacking as well, release early, release often, plus this<br>
> > > > > is a discussion starter to see if perhaps this is sufficient to meet<br>
> > > > > some needs.      <br>
> > > > <br>
> > > > I think from libvirt's POV, we would *not* want devices to be made<br>
> > > > unconditionally persistent. We usually wish to expose a choice to<br>
> > > > applications whether to have resources be transient or persistent.<br>
> > > > <br>
> > > > So from that POV, a global config option to turn off persistence<br>
> > > > is not workable either. We would want control per-device, with<br>
> > > > autostart control per device too.    <br>
> > > <br>
> > > The code has progressed somewhat in the past 3+ weeks, we still persist<br>
> > > all devices, but the start-up mode can be selected per device or with a<br>
> > > global default mode.  Devices configured with 'auto' start-up<br>
> > > automatically while 'manual' devices are simply known and available to<br>
> > > be started.  I imagine we could add a 'transient' mode where we purge<br>
> > > the information about the device when it is removed or the next time<br>
> > > the parent device is added.    <br>
> > <br>
> > Having a pesistent config written out & then purged later is still<br>
> > problematic. If the host crashes, nothing will purge the config file,<br>
> > so it will become a persistent device. Also when listing devices we<br>
> > want to be able to report whether it is persistent or transient. The<br>
> > obvious way todo that is to simply look if a config file exists or<br>
> > not.  <br>
> <br>
> I was thinking that the config file would identify the device as<br>
> transient, therefore if the system crashed we'd have the opportunity to<br>
> purge those entries on the next boot as we're processing the entries<br>
> for that parent device.  Clearly it has yet to be implemented, but I<br>
> expect there are some advantages to tracking devices via a transient<br>
> config entry or else we're constantly re-discovering foreign mdevs.<br>
<br>
I think we need to reach consensus about the actual scope of the<br>
mdevctl tool.<br>
<br></blockquote><div><br></div><div>Thanks Cornelia, my thoughts: <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Is it supposed to be responsible for managing *all* mdev devices in<br>
  the system, or is it more supposed to be a convenience helper for<br>
  users/software wanting to manage mdevs?<br></blockquote><div><br></div><div>The latter. If an operator (or some software) wants to create mdevs by not using mdevctl (and rather directly calling the sysfs), I think it's OK.</div><div> That said, mdevs created by mdevctl would be supported by systemctl, while the others not but I think it's okay.</div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Do we want mdevctl to manage config files for individual mdevs, or<br>
  are they supposed to be in a common format that can also be managed<br>
  by e.g. libvirt?<br></blockquote><div><br></div><div>Unless I misunderstand, I think mdevctl just helps to create mdevs for being used by guests created either by libvirt or QEMU or even others.<br></div><div>How a guest would allocate a mdev (ie. saying "I'll use this specific mdev UUID") is IMHO not something for mdevctl.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Should mdevctl be a stand-alone tool, provide library functions, or<br>
  both? Related: should it keep any internal state that is not written<br>
  to disk? (I think that also plays into the transient vs. persistent<br>
  question.)<br>
<br></blockquote><div><br></div><div>FWIW, I'd love using mdevctl for OpenStack (Nova) just at least for creating persisted mdevs (ie. mdevs that would be recreated after rebooting using systemctl). That's the real use case I need. <br></div><div>Whether libvirt would internally support mdevctl would be nice but that's not really something Nova needs, so I leave others providing their own thoughts.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My personal opinion is that mdevctl should be able to tolerate mdevs<br>
being configured by other means, but probably should not try to impose<br>
its own configuration if it detects that (unless explicitly asked to do<br>
so). Not sure how feasible that goal is.<br>
<br></blockquote><div>That's what I misunderstand : in order to have a guest using a vGPU, you need to do two things :</div><div>1/ create the mdev</div><div>2/ allocate this created dev to a specific guest config</div><div><br></div><div>Of course, we could imagine a way to have both steps to be done directly by libvirt, but from my opinion, mdevctl is really helping 1/ and not 2/.</div><div>-Sylvain</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A well-defined config file format is probably a win, even if it only<br>
ends up being used by mdevctl itself.<br>
</blockquote></div></div>