Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
Peter Maydell writes: > On 21 October 2016 at 19:26, Markus Armbruster wrote: >> "Device not pluggable" does not imply "device has no configuration knobs >> a user may legitimately want to mess with". Plenty of onboard devices >> have such knobs. >> >> Right now, users configure these mostly via board-agnostic options like >> -serial. Anything that doesn't fit the mold can't be configured that >> way. >> >> However, A fully mature QOM as I envisage it would provide users access >> to QOM properties for onboard devices, too. Not with -device, >> obviously, but with qom-set and similar, as Eduardo said. If any of >> these properties are not for users, they should be marked as such. Just >> like for pluggable devices. > > Yes, you're right about this. (What's the command line > equivalent of qom-set? Command line isn't implemented. >We have -global but that's a bit > awkward if I'm remembering its syntax correctly.) -global changes a device property default value. You can abuse it to set a specific device's property only when there's at most one instance. >> Perhaps non-pluggable devices tend to have more "not for users" QOM >> properties than pluggable ones, I don't know. But that would be a >> *quantitative* difference, not a *qualitative* one. > > I agree that it's not really qualitative, but a pluggable > device's properties are all by definition for the user > to set (since the user is the only one who can set them). > In a pre-plugged device, although there may be a lot of > properties, some of them won't be usefully changeable > in the context of this device in this board (ie if you > mess with them you'll just break things). We don't have > any way for the board to say "this stuff isn't for the > user", I think. The closest we have now is the x-prefix convention. Perhaps we could use a flag to mark certain properties as "not user-settable", similar to how we mark devices as "not pluggable" (really: can be created only by board code, not the user).
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On 21 October 2016 at 19:26, Markus Armbruster wrote: > "Device not pluggable" does not imply "device has no configuration knobs > a user may legitimately want to mess with". Plenty of onboard devices > have such knobs. > > Right now, users configure these mostly via board-agnostic options like > -serial. Anything that doesn't fit the mold can't be configured that > way. > > However, A fully mature QOM as I envisage it would provide users access > to QOM properties for onboard devices, too. Not with -device, > obviously, but with qom-set and similar, as Eduardo said. If any of > these properties are not for users, they should be marked as such. Just > like for pluggable devices. Yes, you're right about this. (What's the command line equivalent of qom-set? We have -global but that's a bit awkward if I'm remembering its syntax correctly.) > Perhaps non-pluggable devices tend to have more "not for users" QOM > properties than pluggable ones, I don't know. But that would be a > *quantitative* difference, not a *qualitative* one. I agree that it's not really qualitative, but a pluggable device's properties are all by definition for the user to set (since the user is the only one who can set them). In a pre-plugged device, although there may be a lot of properties, some of them won't be usefully changeable in the context of this device in this board (ie if you mess with them you'll just break things). We don't have any way for the board to say "this stuff isn't for the user", I think. thanks -- PMM
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
Peter Maydell writes: > On 18 October 2016 at 21:49, Eduardo Habkost wrote: >> On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: >>> Lots of stuff in a device's C struct is strictly internal >>> and not to be messed with. I thought that QOM properties >>> were essentially how a device defined its public (and >>> typically settable-only-once) config knobs. QOM properties >>> shouldn't be user-facing (read: stable, required to be >>> backwards-compatible) interface in general because >>> we don't really want to tie ourselves down that much. >>> In fact almost all our QOM objects are not usefully >>> user-facing at all. >> >> This interpretation surprises me, because it is the opposite of >> what I have seen us doing. Most of our QOM objects and properties >> are user-visible and user-configurable using -global, -device, >> -object, or qom-set (and probably other QMP commands). > > Most of the devices I deal with are not and never will > be sensibly usable with -device. Exposing wiring up > of IRQ and GPIO lines or MMIO regions to the user is > never going to make sense. For x86 most devices are > probably pluggable (and usable with -device), but over > the whole source tree I think the embedded-style device > is in the majority. They're all still worth QOMifying > and having properties for the things board code wants > to modify, though. "Device not pluggable" does not imply "device has no configuration knobs a user may legitimately want to mess with". Plenty of onboard devices have such knobs. Right now, users configure these mostly via board-agnostic options like -serial. Anything that doesn't fit the mold can't be configured that way. However, A fully mature QOM as I envisage it would provide users access to QOM properties for onboard devices, too. Not with -device, obviously, but with qom-set and similar, as Eduardo said. If any of these properties are not for users, they should be marked as such. Just like for pluggable devices. Perhaps non-pluggable devices tend to have more "not for users" QOM properties than pluggable ones, I don't know. But that would be a *quantitative* difference, not a *qualitative* one.
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On 19 October 2016 at 12:11, Eduardo Habkost wrote: > BTW, if most devices aren't supposed to be used with -device, > possibly many of them don't have > cannot_instantiate_with_device_add_yet set properly. They used to be covered by hw/core/sysbus.c setting it for them. In commit 33cd52b5d7b9adf that was removed, because under certain specialized circumstances it is now possible to dynamically add a sysbus device. If the machine model doesn't set mc->has_dynamic_sysbus they'll error out via a different route. If the machine model does set that option then it'll probably just do something unhelpful unless the user knew what they were doing. thanks -- PMM
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On Tue, Oct 18, 2016 at 10:08:21PM +0100, Peter Maydell wrote: > On 18 October 2016 at 21:49, Eduardo Habkost wrote: > > On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: > >> Lots of stuff in a device's C struct is strictly internal > >> and not to be messed with. I thought that QOM properties > >> were essentially how a device defined its public (and > >> typically settable-only-once) config knobs. QOM properties > >> shouldn't be user-facing (read: stable, required to be > >> backwards-compatible) interface in general because > >> we don't really want to tie ourselves down that much. > >> In fact almost all our QOM objects are not usefully > >> user-facing at all. > > > > This interpretation surprises me, because it is the opposite of > > what I have seen us doing. Most of our QOM objects and properties > > are user-visible and user-configurable using -global, -device, > > -object, or qom-set (and probably other QMP commands). > > Most of the devices I deal with are not and never will > be sensibly usable with -device. Exposing wiring up > of IRQ and GPIO lines or MMIO regions to the user is > never going to make sense. For x86 most devices are > probably pluggable (and usable with -device), but over > the whole source tree I think the embedded-style device > is in the majority. They're all still worth QOMifying > and having properties for the things board code wants > to modify, though. Even if they are not usable with -device, all properties are configurable using -global. There's no mechanism to avoid letting the user configure properties for devices. Is this really OK? If internal-only usage is also an intended use case for QOM properties, fine. But I believe we need to communicate this more clearly, based on the previous thread (subject: "QOM: best way for parents to pass information to children?"). BTW, if most devices aren't supposed to be used with -device, possibly many of them don't have cannot_instantiate_with_device_add_yet set properly. On the 2.6.2 binaries in Fedora 24, I see: * 1671 device types (including CPU types) * 1011 CPU device types * 1076 no-user device types (including CPU types) * 660 non-CPU device types * 65 no-user non-CPU device types (10% of them) * 860 type_register_*() lines in the code (this includes non-TYPE_DEVICE types, though) * 56 cannot_instantiate_with_device_add_yet=true lines in the code Commands I used to get the numbers above: $ for f in /usr/bin/qemu-system-*;do \ (echo 'info qdm';echo quit;) | $f -machine none -nodefaults -monitor stdio -nographic 2>&1 \ done | grep ^name | sort -u > /tmp/devs $ wc -l /tmp/devs 1671 /tmp/devs $ grep no-user /tmp/devs | wc -l 1076 $ grep -- '-cpu"' /tmp/devs | wc -l 1011 $ grep -v -- '-cpu"' /tmp/devs | wc -l 660 $ grep -v -- '-cpu"' /tmp/devs | grep no-user | wc -l 65 $ -- Eduardo
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On 18 October 2016 at 21:49, Eduardo Habkost wrote: > On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: >> Lots of stuff in a device's C struct is strictly internal >> and not to be messed with. I thought that QOM properties >> were essentially how a device defined its public (and >> typically settable-only-once) config knobs. QOM properties >> shouldn't be user-facing (read: stable, required to be >> backwards-compatible) interface in general because >> we don't really want to tie ourselves down that much. >> In fact almost all our QOM objects are not usefully >> user-facing at all. > > This interpretation surprises me, because it is the opposite of > what I have seen us doing. Most of our QOM objects and properties > are user-visible and user-configurable using -global, -device, > -object, or qom-set (and probably other QMP commands). Most of the devices I deal with are not and never will be sensibly usable with -device. Exposing wiring up of IRQ and GPIO lines or MMIO regions to the user is never going to make sense. For x86 most devices are probably pluggable (and usable with -device), but over the whole source tree I think the embedded-style device is in the majority. They're all still worth QOMifying and having properties for the things board code wants to modify, though. thanks -- PMM
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote: > On 18 October 2016 at 19:45, Eduardo Habkost wrote: > > On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote: > >> We actually have a concrete instance in the tree at the moment: > >> the raspberry pi 2. Specifically hw/arm/bcm2836.c sets the > >> mp_affinity for each cpu to 0xF00 | n (where n is the CPUID). > >> Currently it's doing that by reaching in and messing with > >> the mp_affinity field directly, but really it ought to be > >> doing it by setting a property on the CPU, and what it > >> wants isn't somethnig that can be expressed with a simple > >> nr_sockets/nr_cores/etc scheme. > > > > I am confused now. I thought QOM properties were meant for > > user-visible and/or user-configurable data. I assumed that if > > it's only meant to be used by C code inside QEMU, C functions > > and/or C struct fields were the way to go. > > Lots of stuff in a device's C struct is strictly internal > and not to be messed with. I thought that QOM properties > were essentially how a device defined its public (and > typically settable-only-once) config knobs. QOM properties > shouldn't be user-facing (read: stable, required to be > backwards-compatible) interface in general because > we don't really want to tie ourselves down that much. > In fact almost all our QOM objects are not usefully > user-facing at all. This interpretation surprises me, because it is the opposite of what I have seen us doing. Most of our QOM objects and properties are user-visible and user-configurable using -global, -device, -object, or qom-set (and probably other QMP commands). Some QOM properties are internal and we have been using the "x-" prefix to indicate that, but most of them do _not_ have the "x-" prefix. -- Eduardo
Re: [Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On 18 October 2016 at 19:45, Eduardo Habkost wrote: > On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote: >> We actually have a concrete instance in the tree at the moment: >> the raspberry pi 2. Specifically hw/arm/bcm2836.c sets the >> mp_affinity for each cpu to 0xF00 | n (where n is the CPUID). >> Currently it's doing that by reaching in and messing with >> the mp_affinity field directly, but really it ought to be >> doing it by setting a property on the CPU, and what it >> wants isn't somethnig that can be expressed with a simple >> nr_sockets/nr_cores/etc scheme. > > I am confused now. I thought QOM properties were meant for > user-visible and/or user-configurable data. I assumed that if > it's only meant to be used by C code inside QEMU, C functions > and/or C struct fields were the way to go. Lots of stuff in a device's C struct is strictly internal and not to be messed with. I thought that QOM properties were essentially how a device defined its public (and typically settable-only-once) config knobs. QOM properties shouldn't be user-facing (read: stable, required to be backwards-compatible) interface in general because we don't really want to tie ourselves down that much. In fact almost all our QOM objects are not usefully user-facing at all. thanks -- PMM
[Qemu-devel] QOM properties vs C functions/fields (was Re: [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())
On Tue, Oct 18, 2016 at 07:12:51PM +0100, Peter Maydell wrote: > On 18 October 2016 at 18:57, Andrew Jones wrote: > > On Tue, Oct 18, 2016 at 06:07:49PM +0100, Peter Maydell wrote: > >> Why do you want to un-property mp_affinity? Eventually it would > >> be nice for the machine model to be able to use it to set up > >> a specific NUMA configuration. > > > > I thought about that, but I think we'll want to specify machine > > properties; nr_sockets, nr_cores, nr_threads and use the -device > > command line for the cpu to specify which socket, which core, > > which thread it is. This would be consistent with other architectures > > and easily map to the MPIDR & cpu topology hardware descriptions. > > I was thinking more about "modelling board X, which we know > always has 2xA53 and 4xA57 with these MPIDRs". > > We actually have a concrete instance in the tree at the moment: > the raspberry pi 2. Specifically hw/arm/bcm2836.c sets the > mp_affinity for each cpu to 0xF00 | n (where n is the CPUID). > Currently it's doing that by reaching in and messing with > the mp_affinity field directly, but really it ought to be > doing it by setting a property on the CPU, and what it > wants isn't somethnig that can be expressed with a simple > nr_sockets/nr_cores/etc scheme. I am confused now. I thought QOM properties were meant for user-visible and/or user-configurable data. I assumed that if it's only meant to be used by C code inside QEMU, C functions and/or C struct fields were the way to go. See a previous thread where this was discussed: https://www.mail-archive.com/qemu-devel@nongnu.org/msg387169.html (Subject: "QOM: best way for parents to pass information to children?") > > > Anyway, atm, I don't know of any reason to have the property user- > > settable, so it seems safest to keep it hidden until we decide. > > I agree that it doesn't make sense to let the user mess with it, > but it should be available for the board code to read and write. If it doesn't make sense to let the user mess with it, why would we make it a QOM property? -- Eduardo
