From: Matthew Rosato <mjrosato@linux.ibm.com> To: Cornelia Huck <cohuck@redhat.com>, 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>, "Christophe de Dinechin" <dinechin@redhat.com>, "Tony Krowiak" <akrowiak@linux.ibm.com> Subject: Re: mdevctl: A shoestring mediated device management and persistence utility Date: Thu, 27 Jun 2019 11:00:31 -0400 Message-ID: <06114b39-69c2-3fa0-d0b3-aa96a44ae2ce@linux.ibm.com> (raw) In-Reply-To: <20190627142626.415138da.cohuck@redhat.com> On 6/27/19 8:26 AM, Cornelia Huck wrote: > On Wed, 26 Jun 2019 19:53:50 -0600 > Alex Williamson <alex.williamson@redhat.com> wrote: > >> On Wed, 26 Jun 2019 08:37:20 -0600 >> Alex Williamson <alex.williamson@redhat.com> wrote: >> >>> On Wed, 26 Jun 2019 11:58:06 +0200 >>> Cornelia Huck <cohuck@redhat.com> wrote: >>> >>>> On Tue, 25 Jun 2019 16:52:51 -0600 >>>> Alex Williamson <alex.williamson@redhat.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Based on the discussions we've had, I've rewritten the bulk of >>>>> mdevctl. I think it largely does everything we want now, modulo >>>>> devices that will need some sort of 1:N values per key for >>>>> configuration in the config file versus the 1:1 key:value setup we >>>>> currently have (so don't consider the format final just yet). >>>> >>>> We might want to factor out that config format handling while we're >>>> trying to finalize it. >>>> >>>> cc:ing Matt for his awareness. I'm currently not quite sure how to >>>> handle those vfio-ap "write several values to an attribute one at a >>>> time" requirements. Maybe 1:N key:value is the way to go; maybe we >>>> need/want JSON or something like that. >>> >>> Maybe we should just do JSON for future flexibility. I assume there >>> are lots of helpers that should make it easy even from a bash script. >>> I'll look at that next. >> >> Done. Throw away any old mdev config files, we use JSON now. > > The code changes look quite straightforward, thanks. > >> The per >> mdev config now looks like this: >> >> { >> "mdev_type": "i915-GVTg_V4_8", >> "start": "auto" >> } >> >> My expectation, and what I've already pre-enabled support in set_key >> and get_key functions, is that we'd use arrays for values, so we might >> have: >> >> "new_key": ["value1", "value2"] >> >> set_key will automatically convert a comma separated list of values >> into such an array, so I'm thinking this would be specified by the user >> as: >> >> # mdevctl modify -u UUID --key=new_key --value=value1,value2 > > Looks sensible. > > For vfio-ap, we'd probably end up with something like the following: > > { > "mdev_type": "vfio_ap-passthrough", > "start": "auto", > "assign_adapter": ["5", "6"], > "assign_domain": ["4", "0xab"] > } > > (following the Guest1 example in the kernel documentation) > > <As an aside, what should happen if e.g "assign_adapter" is set to > ["6", "7"]? Remove 5, add 7? Remove all values, then set the new ones? IMO remove 5, add 7 would make the most sense. I'm not sure that doing an unassign of all adapters (effectively removing all APQNs) followed by an assign of the new ones would work nicely with Tony's vfio-ap dynamic configuration patches. > Similar for deleting the "assign_adapter" key. We have an > "unassign_adapter" attribute, but this is not something we can infer > automatically; we need to know that we're dealing with an vfio-ap > matrix device...> > >> >> We should think about whether ordering is important and maybe >> incorporate that into key naming conventions or come up with some >> syntax for specifying startup blocks. Thanks, >> >> Alex > > Hm... > > { > "foo": "1", > "bar": "42", > "baz": { > "depends": ["foo", "bar"], > "value": "plahh" > } > } > > Something like that? >
next prev parent 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 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 [this message] 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=06114b39-69c2-3fa0-d0b3-aa96a44ae2ce@linux.ibm.com \ --to=mjrosato@linux.ibm.com \ --cc=akrowiak@linux.ibm.com \ --cc=alex.williamson@redhat.com \ --cc=berrange@redhat.com \ --cc=cohuck@redhat.com \ --cc=dinechin@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
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 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.git