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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list