On Mon, 5 May 2014 14:20:25 +0200
Vasilis Liaskovitis <vasilis.liaskovi...@profitbricks.com> wrote:
> Hi,
>
> On Fri, Apr 04, 2014 at 03:36:45PM +0200, Igor Mammedov wrote:
> > - implements QEMU hardware part of memory hotplug protocol
> > described at "docs/specs/acpi_mem_hotplug.txt"
> > - handles only memory add notification event for now
> >
> [...]
> > + [0x4-0x7] OST event code reported by OSPM
> > + [0x8-0xb] OST status code reported by OSPM
> > + case 0x4: /* _OST event */
> > + mdev = &mem_st->devs[mem_st->selector];
> > + if (data == 1) {
> > + /* TODO: handle device insert OST event */
> > + } else if (data == 3) {
> > + /* TODO: handle device remove OST event */
> > + }
>
> Are there any patches planned to report _OST notifications to upper management
> layers? E.g. some older patchseries implemented a queue for these
> notifications
> that could be queried with an "info memhp" command.
I don't recall seeing patches "info memhp", could you point them to me, please?
But I have in mind to add corresponding commands for get OST and sending
corresponding QMP events.
>
> As a more general question for the patchseries: How do we query
> status/presence
> of dimms present? Some posssible options could be:
>
> - info qtree: If links<> are implemented between dimms and an acpi machine
> adapter, would the dimms show up in the general device tree? Currently I
> believe
> they don't.
>
> - info dimm: We could have a new "info dimm" command that shows information
> for
> present DIMMs: start-end guest physical address, last _OST notification
> received
> for this DIMM, as well as backing memdev object for this dimm.
I'd prefer this one for hmp and from QMP side qom-get could be used to
enumerate/get
properties.
>
> (qemu) info dimm
> dimm0: range="start_address - end_address" memdev="obj0" _OST="last_OST
> message"
> dimm1: range="start_address - end_address" memdev="obj1" _OST="last_OST
> message"
>
> where last_OST message could be "hot-add succesfull", "hot-add failed",
> "hot-remove failed". Not sure how "hot-remove successful" would be reported
> though, as the dimm device would be removed (or soon to be removed) from the
> machine. Unless we have a separate command for OST messages received/queued,
> as
> mentioned above.
Not much could be done here except of sending QMP event. It's generic hot-unplug
issue.
>
> If the guest does not support _OST, the OST entries would remain empty,
> at least giving management layer a hint that the guest may not have
> succesfully
> completed the requested hot-operation.
>
> The examples are all in hmp, but there should obviously be qmp support.
> Thoughts?
>
> thanks,
>
> - Vasilis
>
>
