Re: [Qemu-devel] [PATCH 20/35] acpi: memory hotplug ACPI hardware implementation

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 5 May 2014 14:20:25 +0200
Vasilis Liaskovitis <vasilis.liaskovitis@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
> 
>