qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vasilis Liaskovitis
Subject: Re: [Qemu-devel] [PATCH 20/35] acpi: memory hotplug ACPI hardware implementation
Date: Mon, 5 May 2014 14:20:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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.

(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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]