From patchwork Mon Jun 2 14:29:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vasilis Liaskovitis X-Patchwork-Id: 4282621 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 97378BEEA7 for ; Mon, 2 Jun 2014 14:29:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 88B69203DC for ; Mon, 2 Jun 2014 14:29:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1846520122 for ; Mon, 2 Jun 2014 14:29:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755134AbaFBO3m (ORCPT ); Mon, 2 Jun 2014 10:29:42 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:56947 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755133AbaFBO3k (ORCPT ); Mon, 2 Jun 2014 10:29:40 -0400 Received: by mail-wi0-f171.google.com with SMTP id cc10so4626546wib.10 for ; Mon, 02 Jun 2014 07:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=IT2KmS72gSly+nY5x5/Bc64dpgb0wvD/tQWmDudQA+A=; b=OsgUcEakZquzsUCDLtgJadp+o+Gjh0wf3uqqj94AWuWN1BfP3fwuoTzJDkDiV8cjh7 92NRenj4k0pAbxdbfeODI7xoGwdyQJ6P5buxQkJWAsHzh4wGyJUt3stDIKzJfCzhurAh l3DBQLx2uYNeeCv2BWBV+a8QI4HZFdthPc455P9ppkZkUrF/zhMWkR07O349KVIxoh1h +1o6E0g/yKyhbZvjI2JRiHjH6SpLmKgIKsnSsaj75rXN6/1qTkxN6rzWJT76WWjOLQCL o56/6uI66CK+sNWpIMgqrfp7PfSR9SVqTOXyeiMkbeLnFsawtpF7WTU0S+vY2t114HIw 4YCg== X-Gm-Message-State: ALoCoQm/B9dwIsBBvFsuWrCi+VSoOKeWzZ8qI7/DyNKxUXD2+1WVrdi6bA/MuvBkIQ3U9M0f3MlZ X-Received: by 10.194.242.136 with SMTP id wq8mr50531793wjc.4.1401719376914; Mon, 02 Jun 2014 07:29:36 -0700 (PDT) Received: from dhcp-192-168-178-175.profitbricks.localdomain ([62.217.45.26]) by mx.google.com with ESMTPSA id l9sm33012051wic.21.2014.06.02.07.29.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 02 Jun 2014 07:29:36 -0700 (PDT) Date: Mon, 2 Jun 2014 16:29:32 +0200 From: Vasilis Liaskovitis To: Igor Mammedov Cc: Peter Maydell , mst@redhat.com, aik@ozlabs.ru, Hu Tao , mjt@tls.msk.ru, qemu-devel , 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, Anshul Makkar , chegu_vinod@hp.com, rth@twiddle.net, kwolf@redhat.com, s.priebe@profihost.ag, mreitz@redhat.com, pbonzini@redhat.com, afaerber@suse.de, linux-acpi@vger.kernel.org Subject: Re: [Qemu-devel] [PATCH 33/35] pc: ACPI BIOS: reserve SRAT entry for hotplug mem hole Message-ID: <20140602142932.GA20120@dhcp-192-168-178-175.profitbricks.localdomain> References: <20140414184442.6ff3e626@nial.usersys.redhat.com> <20140505155915.GB8574@dhcp-192-168-178-175.profitbricks.localdomain> <20140506015239.GA3722@G08FNSTD100614.fnst.cn.fujitsu.com> <20140506130028.GB5326@dhcp-192-168-178-175.profitbricks.localdomain> <20140528100722.01b59a48@nial.usersys.redhat.com> <20140528122312.GA4730@dhcp-192-168-178-175.profitbricks.localdomain> <20140528152642.108cb193@nial.usersys.redhat.com> <20140528163813.GB28017@dhcp-192-168-178-175.profitbricks.localdomain> <20140529111237.7d775371@nial.usersys.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140529111237.7d775371@nial.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, May 29, 2014 at 11:12:37AM +0200, Igor Mammedov wrote: > On Wed, 28 May 2014 18:38:13 +0200 > Vasilis Liaskovitis wrote: > > > On Wed, May 28, 2014 at 03:26:42PM +0200, Igor Mammedov wrote: > > > On Wed, 28 May 2014 14:23:13 +0200 > > > Vasilis Liaskovitis wrote: > > > > > > > On Wed, May 28, 2014 at 10:07:22AM +0200, Igor Mammedov wrote: > > > > > On Tue, 27 May 2014 17:57:31 +0200 > > > > > Anshul Makkar wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I tested the hot unplug patch and doesn't seem to work properly with Debian > > > > > > 6 and Ubuntu host. > > > > > > > > > > > > Scenario: > > > > > > I added 3 dimm devices of 1G each: > > > > > > > > > > > > object_add memory-ram,id=ram0,size=1G, device_add dimm,id=dimm1,memdev=ram0 > > > > > > > > > > > > object_add memory-ram,id=ram1,size=1G, device_add dimm,id=dimm2,memdev=ram1 > > > > > > > > > > > > object_add memory-ram,id=ram2,size=1G, device_add dimm,id=dimm3,memdev=ram2 > > > > > > > > > > > > device_del dimm3: I get the OST EVENT EJECT 0x3 and OST STATUS as 0x84(IN > > > > > > PROGRESS) If I check on the guest, the device has been successfully > > > > > > removed. But no OST EJECT SUCCESS event was received. > > > > > I think there should be a SUCCESS event, > > > > > it should be investigated from the guest side first, OST support in kernel > > > > > is relatively new. > > > > > > > > When testing older guest kernel (3.11), _OST success events are not sent > > > > from the guest. I haven't tried newer versions yet. > > > > > > > > In terms of OSPM _OST behaviour, I am not sure if returning OST success status > > > > on succcesful removal is *required*. Figure 6-37, page 306 of ACPI spec5.0 > > > > shows that on succcesfull OS ejection ejection, _EJ0 is evaluated. Evaluating > > > > _OST does not seem to be a requirement, is it? (cc'ing linux-acpi for input) > > > > > > > > In linux guests, on successful removal, _EJ0 is always evaluated. I believe we > > > > should be handling _EJ0 and doing the dimm removal (object_unparent) there. > > > > Currently OST successes are never received and dimm devices remain in QEMU even > > > > when successfully ejected from guest. > > > > E.g. a quick patch for _EJ0 handling, on top of Hu Tao's series: > > > > > The same register [0x14] is control register when writing there, so we can use-reuse > the same bit position as MRMV for signaling QEMU to perform eject on writing 1 there, > similarly like it's done for insert event. thanks, on a closer look that makes sense. MRMV is sufficient, example patch below. With the new "query-acpi-ospm-status" we can read OST status from QMP. However as I mentioned, on succesful removal, the guest kernel does not send the OST success status (0x0). This leads to the scenario where memory device is succesfully ejected, _EJ0 is evaluated in guest and device is deleted in qemu (with the patch below). The dimm will no longer show up in "query-memory-devices", however the ospm status of the dimm slot will still remain at 0x84 (ejection in progress). This can be confusing to management layers. Do you have any suggestion for how to report the succesful _EJ0? We could simply write a succesful status: mdev->ost_status = 0x0 when MRMV is written to, but it is a bit hacky. On the other hand, having another command only for _EJ0 notification sounds like overkill. In terms of linux kernel ACPI conformity, Figure 6-37 in the spec implies that _OST evaluation is not required after succesfull _EJ0 evaluation. Also see relevant comment in drivers/acpi/scan.c: acpi_scan_hot_remove() line 378 (3.15-rc8): /* * Verify if eject was indeed successful. If not, log an error * message. No need to call _OST since _EJ0 call was made * OK. */ acpi, memory-hotplug: Add _EJ0 handling --- docs/specs/acpi_mem_hotplug.txt | 3 ++- hw/acpi/memory_hotplug.c | 9 +++------ 2 files changed, 5 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/docs/specs/acpi_mem_hotplug.txt b/docs/specs/acpi_mem_hotplug.txt index 1290994..4501774 100644 --- a/docs/specs/acpi_mem_hotplug.txt +++ b/docs/specs/acpi_mem_hotplug.txt @@ -35,7 +35,8 @@ Memory hot-plug interface (IO port 0xa00-0xa17, 1-4 byte access): 1: if set to 1 clears device insert event, set by OSPM after it has emitted device check event for the selected memory device - 2-7: reserved, OSPM must clear them before writing to register + 2: Device no longer used by guest, can be safely removed + 3-7: reserved, OSPM must clear them before writing to register Selecting memory device slot beyond present range has no effect on platform: - write accesses to memory hot-plug registers not documented above are diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index 8aa829d..24989d3 100644 --- a/hw/acpi/memory_hotplug.c +++ b/hw/acpi/memory_hotplug.c @@ -93,9 +93,6 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data, case 0x03: /* EJECT */ switch (mdev->ost_status) { case 0x0: /* SUCCESS */ - object_unparent(OBJECT(mdev->dimm)); - mdev->is_removing = false; - mdev->dimm = NULL; break; case 0x1: /* FAILURE */ case 0x2: /* UNRECOGNIZED NOTIFY */ @@ -115,9 +112,6 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data, case 0x103: /* OSPM EJECT */ switch (mdev->ost_status) { case 0x0: /* SUCCESS */ - object_unparent(OBJECT(mdev->dimm)); - mdev->is_removing = false; - mdev->dimm = NULL; break; case 0x84: /* EJECTION IN PROGRESS */ mdev->is_enabled = false; @@ -135,6 +129,9 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data, trace_mhp_acpi_clear_insert_evt(mem_st->selector); } else if (data & 4) { /* MRMV */ mdev->is_enabled = false; + object_unparent(OBJECT(mdev->dimm)); + mdev->is_removing = false; + mdev->dimm = NULL; } break; }