On 14/05/21 14:48, Mirela Grujic wrote:
With our approach, transitioning to the QMP configuration suppose to
happen gradually, i.e. we still specify some configuration options via
command line. For your approach to be applicable to our use case we
would at least need a QMP equivalent for the following:
qemu-system-riscv64 \
-M sifive_dt \
-cpu
rv64,i=true,g=false,m=true,a=true,f=true,d=true,c=true,s=false,u=false,x-b=true,pmp=true,mmu=false,num-pmp-regions=8
\
-smp 1 \
-device ...
AFAIU from the materials you shared, we would need to add -cpu and
-device, but I don't see any reason why we wouldn't do this.
-cpu is indeed the big one that I had not looked at so far, while
-device should be mostly covered by the existing device_add command.
One possibility for -cpu is to make it an argument of machine-set too.
For example the above would be
{ 'execute': 'machine-set', arguments: {
'type': 'sifive_dt',
'smp': { 'cpus': 1 },
'cpu': { 'model': 'rv64', 'i': true, 'g': false, ... }
}
Ok, please let me know once you test, then I would run your code and
play with it to better understand what needs to be done. Then I might
come back with a couple of questions, so that we align on the TODOs. Is
that ok with you?
Yes, of course. I pushed something that at least compiles and passes a
basic smoke test.
Btw, when (in which version) did you plan to integrate the
qemu-qmp-* support? I guess once machine-set/accel-set is implemented, > but
maybe I'm wrong...
Well, the right answer is "when somebody needs it". The things that I
was mostly interested in (e.g. compound properties for machines, such as
smp in the example above) were all enablers for qemu-qmp-* but I was not
really interested in the new binaries. I did the qemu-qmp-* patches
mostly to validate that the 5.2/6.0 refactoring of preconfig was going
in the right direction.
However, if there is indeed somebody that needs it I'll contribute where
our interests overlap. In particular I can take care of converting the
command line options to properties.
Paolo
