From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZZL-0000mD-Jt for qemu-devel@nongnu.org; Tue, 06 May 2014 03:13:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhZZG-0008Sx-RC for qemu-devel@nongnu.org; Tue, 06 May 2014 03:13:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZZG-0008Sc-KU for qemu-devel@nongnu.org; Tue, 06 May 2014 03:13:34 -0400 Date: Tue, 6 May 2014 09:13:13 +0200 From: Igor Mammedov Message-ID: <20140506091313.78dda762@nial.usersys.redhat.com> In-Reply-To: <20140505122025.GA8574@dhcp-192-168-178-175.profitbricks.localdomain> References: <1396618620-27823-1-git-send-email-imammedo@redhat.com> <1396618620-27823-21-git-send-email-imammedo@redhat.com> <20140505122025.GA8574@dhcp-192-168-178-175.profitbricks.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 20/35] acpi: memory hotplug ACPI hardware implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vasilis Liaskovitis Cc: peter.maydell@linaro.org, mst@redhat.com, aik@ozlabs.ru, hutao@cn.fujitsu.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, kraxel@redhat.com, akong@redhat.com, quintela@redhat.com, armbru@redhat.com, aliguori@amazon.com, jan.kiszka@siemens.com, lersek@redhat.com, ehabkost@redhat.com, marcel.a@redhat.com, stefanha@redhat.com, chegu_vinod@hp.com, rth@twiddle.net, kwolf@redhat.com, s.priebe@profihost.ag, mreitz@redhat.com, pbonzini@redhat.com, afaerber@suse.de On Mon, 5 May 2014 14:20:25 +0200 Vasilis Liaskovitis 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 > >