On Fri, Mar 13, 2015 at 10:38:51 -0400, John Ferlan wrote:
On 03/04/2015 11:24 AM, Peter Krempa wrote:
When using 'dimm' memory devices with qemu, some of the information like the slot number and base address need to be reloaded from qemu after process start so that it reflects the actual state. The state then allows to use memory devices across migrations. --- src/qemu/qemu_domain.c | 49 +++++++++++++++++ src/qemu/qemu_domain.h | 4 ++ src/qemu/qemu_monitor.c | 42 +++++++++++++++ src/qemu/qemu_monitor.h | 14 +++++ src/qemu/qemu_monitor_json.c | 122 +++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 5 ++ src/qemu/qemu_process.c | 4 ++ 7 files changed, 240 insertions(+)
...
+ /* Technically, qemuProcessStart can be called from inside * QEMU_ASYNC_JOB_MIGRATION_IN, but we are okay treating this like * a sync job since no other job can call into the domain until
There's nothing through the qemuProcessAttach processing for this data (although there is balloon info processing)
- Decision on error handling of -2 or not
All other places should handle well if qemu did not report the data.
- Don't drop into the loop to look at returned data if we had -2 returned
I've added this, it would probably cause a crash.
- And add some sort of qemuProcessAttach handling...
Since the command line parser is not implemeneted for memory devices and I don't really find it worth bothering with making qemuProcessAttach work with every new feature I would rather not try doing this.
Just so it doesn't impede progress, I'm fine with a future follow-up patch for the qemuProcessAttach. Leaving only handling the second point above for an ACK
Peter