[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v3 11/19] Implement qmp and hmp commands for
From: |
Vasilis Liaskovitis |
Subject: |
Re: [Qemu-devel] [RFC PATCH v3 11/19] Implement qmp and hmp commands for notification lists |
Date: |
Mon, 24 Sep 2012 16:45:02 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi,
On Fri, Sep 21, 2012 at 04:03:26PM -0600, Eric Blake wrote:
> On 09/21/2012 05:17 AM, Vasilis Liaskovitis wrote:
> > Guest can respond to ACPI hotplug events e.g. with _EJ or _OST method.
> > This patch implements a tail queue to store guest notifications for memory
> > hot-add and hot-remove requests.
> >
> > Guest responses for memory hotplug command on a per-dimm basis can be
> > detected
> > with the new hmp command "info memhp" or the new qmp command "query-memhp"
>
> Naming doesn't match the QMP code.
will fix.
>
> > Examples:
> >
> > (qemu) device_add dimm,id=ram0
>
> >
> > These notification items should probably be part of migration state (not yet
> > implemented).
>
> In the case of libvirt driving migration, you already said in 10/19 that
> libvirt has to start the destination with the populated=on|off fields
> correct for each dimm according to the state it was in at the time the
That patch actually alleviates this restriction for the off->on direction i.e.
it allows for the target-VM to not have its args updated for dimm hot-add.
(e.g. Let's say the source was started with a dimm, initialy off. The dimm is
hot-plugged, and then migrated . WIth patch 10/19, the populated arg doesn't
have to be updated on the target)
The other direction (off->on) still needs correct arg change.
If libvirt/management layers guarantee the dimm arguments are correctly changed,
I don't see that we need 10/19 patch eventually.
What I think is needed is another hmp/qmp command, that will report
which dimms are on/off at any given time e.g.
(monitor) info memory-hotplug
dimm0: off
dimm1: on
...
dimmN: off
This can be used on the source by libvirt / other layers to find out the
populated dimms, and construct the correct command line on the destination.
Does this make sense to you?
The current patch only deals with success/failure event notifications (not
on-off state of dimms) and should probably be renamed to
"query-memory-hotplug-events".
> host started the update. Can the host hot unplug memory after migration
> has started?
Good testcase. I would rather not allow any hotplug operations while the
migration
is happening.
What do we do with pci hotplug during migration currently? I found a discussion
dating from a year ago, suggesting the same as the simplest solution, but I
don't know what's currently implemented.
http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg01204.html
>
> > +
> > +##
> > +# @MemHpInfo:
> > +#
> > +# Information about status of a memory hotplug command
> > +#
> > +# @dimm: the Dimm associated with the result
> > +#
> > +# @result: the result of the hotplug command
> > +#
> > +# Since: 1.3
> > +#
> > +##
> > +{ 'type': 'MemHpInfo',
> > + 'data': {'dimm': 'str', 'request': 'str', 'result': 'str'} }
>
> Should 'result' be a bool (true for success, false for still pending) or
> an enum, instead of a free-form string? Likewise, isn't 'request' going
> to be exactly one of two values (plug or unplug)?
agreed with 'request'.
For 'result' it is also a boolean, but with 'success' and 'failure' (rather than
'pending'). Items are only queued when the guest has given us a definite _OST
or _EJ result wich is either success or fail. If an operation is pending,
nothing
is queued here.
Perhaps queueing pending operations also has a usecase, but this isn't addressed
in this patch.
thanks,
- Vasilis
- [Qemu-devel] [RFC PATCH v3 05/19] Implement dimm device abstraction, (continued)
- [Qemu-devel] [RFC PATCH v3 05/19] Implement dimm device abstraction, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 04/19][SeaBIOS] acpi: generate hotplug memory devices, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 07/19] acpi_piix4: Implement memory device hotplug registers, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 08/19] pc: calculate dimm physical addresses and adjust memory map, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 09/19] pc: Add dimm paravirt SRAT info, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 11/19] Implement qmp and hmp commands for notification lists, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 12/19] Implement "info memory-total" and "query-memory-total", Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 17/19][SeaBIOS] Implement _PS3 method for memory device, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 15/19] Add _OST dimm support, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 18/19] Implement _PS3 for dimm, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 13/19] balloon: update with hotplugged memory, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 10/19] fix live-migration when "populated=on" is missing, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 14/19][SeaBIOS] Add _OST dimm method, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 16/19] Update dimm state on reset, Vasilis Liaskovitis, 2012/09/21
- [Qemu-devel] [RFC PATCH v3 19/19][SeaBIOS] Calculate pcimem_start and pcimem64_start from SRAT entries, Vasilis Liaskovitis, 2012/09/21