On Thu, 16 Apr 2020, Randy Yates wrote:
1. Apparently the CPU has properties. What are the specific properties and
their
defaults? How do you change a property's default value?
Maybe look for DEFINE_PROP_ to find out, For example:
qemu/target/arm/cpu.c:2757:
static Property arm_cpu_properties[] = {
DEFINE_PROP_BOOL("start-powered-off", ARMCPU, start_powered_off, false),
DEFINE_PROP_UINT32("psci-conduit", ARMCPU, psci_conduit, 0),
DEFINE_PROP_UINT32("midr", ARMCPU, midr, 0),
DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
mp_affinity, ARM64_AFFINITY_INVALID),
DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
DEFINE_PROP_INT32("core-count", ARMCPU, core_count, -1),
DEFINE_PROP_END_OF_LIST()
};
then qemu/hw/arm/bcm2836.c:138:
/* start powered off if not enabled */
object_property_set_bool(OBJECT(&s->cpu[n].core), n >= s->enabled_cpus,
"start-powered-off", &err);
There's probably also a way to query and set these from monitor, info
qtree command lists properties of instantiated devices I think. There's
also some device_add option to get info on other devices but I don't know
how that works. Maybe help device_add in monitor tells you.
2. Ditto previous question for other machine components.
Same as above, but look for property definition in device model under
qemu/hw.
5. There may be custom hardware involved, e.g., GPIOs, I2Cs, etc. How would
these be defined in the machine?
You need to find the appropriate device model or write it if does not
exist then set it up in the board code to appear at the right addresses
(or attach to right bus e.g. for i2c devices). The info mtree monitor
command is useful to see what's mapped where and you can compare it to
memory map of real hardware. For writing device models look at exising
similar examples. Also enabling #define DEBUG_UNASSIGNED in qemu/memory.c
is useful to get logs about guest attempting to access missing devices
(although logged address can be relative to a memory region so may not be
actual memory address in some cases). There's also a placeholder
unimplemented device model that you can map over known unimplemented
areas before you actually implement them, see for example
hw/arm/xlnx-versal.c for how it's used.
6. Documentation for routing the monitor to another place (e.g., a telnet
termi-
nal) could be better. pm215 gave me the following complex set of
command-
line options:
-chardev
socket,id=monitor,host=127.0.0.1,port=4444,server,nowait,telnet -mon
chardev=monitor,mode=readline
This works, for telnet I'm afraid that's the simplest way. There's
-monitor stdio or -serial stdio that can be useful.
7. Ditto above comment for the -d option.
I think there's -D logfile to specify log file, these are somewhat
documented in --help.
Regards,
BALATON Zoltan
