KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
	"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: Tue, 11 Jun 2019 21:45:08 +0200
Message-ID: <20190611214508.0a86aeb2.cohuck@redhat.com> (raw)
In-Reply-To: <20190607180630.7e8e24d4.pasic@linux.ibm.com>

On Fri, 7 Jun 2019 18:06:30 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> On Fri, 24 May 2019 12:11:06 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Thu, 23 May 2019 17:20:01 -0600
> > Alex Williamson <alex.williamson@redhat.com> wrote:
> >   
> > > Hi,
> > >   
> 
> [..]
> 
> > > 
> > > 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.
> >   
> 
> Sorry for being late...
> 
> I guess for vfio-ccw one needs to make sure that the ccw device is bound
> to the vfio-ccw driver first, and only after that can one use  
> create-mdev to create the mdev on top of the subchannel.
> 
> So to make this work persistently (survive a reboot) one would need to
> take care of the subchannel getting bound to the right vfio_ccw driver
> before mdevctl is called. Right?
> 
> BTW how does this concurrence situation between the drivers io_subchannel
> and vfio_ccw work? Especially if both are build in?

If you have two drivers that match to the same device type, you'll
always have the issue that the driver that is first matched with the
device will bind to it and you have to do the unbind/rebind dance to
get it bound to the correct device driver. (I guess that this was the
basic motivation behind the ap bus default driver infrastructure,
right?) I think that in our case the io_subchannel driver will be
called first (alphabetical order and the fact that vfio-ccw will often
be a module). I'm not sure if it is within the scope of mdevctl to
ensure that the device is bound to the correct driver, or if it rather
should work with devices already bound to the correct driver only.
Maybe a separate udev-rules generator?

There's also the question where that automatic configuration should
stop. Should cio_ignore handling be part of it as well? [That's a
non-generic interface, of course. Tooling within s390-tools, maybe?]

> > > 
> > > 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. 
> 
> +1
> 
> @Alex: I'm curious what is the big management picture for non-auto
> looks like.
> 
> Regards,
> Halil
> 
> [..]
> 


  reply index

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 23:20 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 [this message]
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 publically 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=20190611214508.0a86aeb2.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=pasic@linux.ibm.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

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