From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Max Reitz" <mreitz@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day)
Date: Thu, 30 Apr 2020 11:34:37 +0100 [thread overview]
Message-ID: <20200430103437.GI2084570@redhat.com> (raw)
In-Reply-To: <87tv11e1en.fsf_-_@dusky.pond.sub.org>
On Thu, Apr 30, 2020 at 12:03:12PM +0200, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Thu, 30 Apr 2020 at 08:09, Markus Armbruster <armbru@redhat.com> wrote:
> >> Our means to configure onboard devices are weak. We sidestepped this
> >> for isa-fdc by taking it off the board, and thus make -device work.
> >
> > This seems to be a general dynamic: the x86 pc machine works
> > via -device options (or is changed so it can work that way);
> > and then people propose dropping/deprecating/etc the config
> > options that work with onboard devices, without providing
> > clear solutions/instructions on how the command line needs
> > to change/etc for the mass of boards which are not the x86
> > pc machine and which do have a lot of onboard devices which
> > can't be handled via -device.
> >
> > So my gut reaction to the "we should deprecate -global"
> > suggestions in this thread was a bit "here we go again"...
> > What works for x86 or even "what is sufficient for libvirt"
> > doesn't necessarily cover all the cases.
>
> Such shortsighted proposals have been made, but don't think it's what
> we're doing here.
>
> You're 100% right in that we do need to configure onboard devices.
> -global is a terrible way to do it, though: it applies to *all* devices
> of a kind. What if the board has more than one? What if the can add
> more?
> Any better ideas for letting users configure onboard devices?
All the devices in QEMU form a tree, as reported by "info qtree".
So, IIUC, the challenge is to provide a way to uniquely identify
any node in the tree.
Devices configured by the user/mgmt app will have an "id" property
but most built-in devices will not have any "id". In addition even
user configured devices may create multiple sub-nodes in the tree
without "id" parameters.
Uniquely referencing nodes in a tee is a solved problem though,
even without "id" parameters. The XPath query languages shows
this for XML.
-global defines a query language based on the object type, and
property name which is insufficiently flexible
-set defines a query language based on the object type and ID
value and property name(s) which is again insufficiently flexible.
We "merely" need a new query language targetted to QEMU's qtree
structure, which we can expose in the CLI that gives unique access
to every possible property.
Here is the truncated 'info qtree' for a running guest of mine:
bus: main-system-bus
type System
dev: kvm-ioapic, id ""
gpio-in "" 24
gsi_base = 0 (0x0)
mmio 00000000fec00000/0000000000001000
dev: i440FX-pcihost, id ""
pci-hole64-size = 2147483648 (2 GiB)
short_root_bus = 0 (0x0)
x-pci-hole64-fix = false
bus: pci.0
type PCI
dev: virtio-balloon-pci, id "balloon0"
disable-legacy = "off"
disable-modern = true
class = 255 (0xff)
virtio-pci-bus-master-bug-migration = false
migrate-extra = false
modern-pio-notify = false
x-disable-pcie = true
page-per-vq = true
x-ignore-backend-features = true
ats = false
x-pcie-deverr-init = false
x-pcie-lnkctl-init = false
x-pcie-pm-init = false
addr = 08.0
romfile = ""
rombar = 1 (0x1)
multifunction = false
command_serr_enable = true
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = false
class Class 00ff, addr 00:08.0, pci id 1af4:1002 (sub 1af4:0005)
bar 0: i/o at 0xc100 [0xc11f]
bus: virtio-bus
type virtio-pci-bus
dev: virtio-balloon-device, id ""
deflate-on-oom = false
free-page-hint = false
qemu-4-0-config-size = false
iothread = ""
indirect_desc = true
event_idx = true
notify_on_empty = true
any_layout = true
iommu_platform = false
use-started = false
Consider the problem is to set the "deflate-on-oom" property on
the balloon device.
To uniquely identify this we can have a string:
/dev[1]/bus[pci/0]/dev[id=balloon0]/bus[virtio-bus]/dev[0]/deflate-on-oom=true
If we consider that "id" values are unique, we can allow a simplication
by omitting everything before that part of the match - "//" could indicate
an omitted part like XPath allows, so we'd get
//dev[id=balloon0]/bus[virtio-bus]/dev[0]/deflate-on-oom=true
There's only one bus, and one dev on that bus, so knowing this we can
simplify a bit more and still be a unique query, to get this:
//dev[id=balloon0]/bus/dev/deflate-on-oom=true
Or even allow use of "//" in the middle too:
//dev[id=balloon0]//deflate-on-oom=true
Which conceptually says
"find the device with id balloon0 and set the property 'deflate-on-oom'
on the first child node in the qtree that hsa such a property name"
I didn't say this would be pretty, and of course no one would seriously
use this syntax for the virtio-balloon device, as you'd just set the
property with -device. It should work for the many built-in devices
though.
Now just provide a new CLI arg
$QEMU -qtree //dev[id=balloon0]//deflate-on-oom=true
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-04-30 10:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 15:28 Failing property setters + hardwired devices + -global = a bad day Markus Armbruster
2020-04-29 15:39 ` Paolo Bonzini
2020-04-29 16:23 ` Eduardo Habkost
2020-04-29 15:57 ` Daniel P. Berrangé
2020-04-30 7:09 ` Markus Armbruster
2020-04-30 9:27 ` Peter Maydell
2020-04-30 10:03 ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Markus Armbruster
2020-04-30 10:29 ` Mark Cave-Ayland
2020-04-30 14:11 ` Configuring onboard devices Markus Armbruster
2020-04-30 14:32 ` Mark Cave-Ayland
2020-04-30 15:20 ` Markus Armbruster
2020-04-30 16:56 ` Mark Cave-Ayland
2020-05-02 5:47 ` Markus Armbruster
2020-05-03 22:13 ` Mark Cave-Ayland
2020-05-04 16:30 ` Eduardo Habkost
2020-04-30 10:34 ` Daniel P. Berrangé [this message]
2020-04-30 10:45 ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Peter Maydell
2020-04-30 10:53 ` Daniel P. Berrangé
2020-04-30 14:38 ` Configuring onboard devices Markus Armbruster
2020-04-30 10:54 ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Mark Cave-Ayland
2020-04-30 14:27 ` Configuring onboard devices Markus Armbruster
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=20200430103437.GI2084570@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jasowang@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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.