From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14107C4707F for ; Tue, 25 May 2021 21:44:45 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 82DA2613B6 for ; Tue, 25 May 2021 21:44:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82DA2613B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lleqx-0006KV-Ef for qemu-devel@archiver.kernel.org; Tue, 25 May 2021 17:44:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lleq5-0005e6-Jm for qemu-devel@nongnu.org; Tue, 25 May 2021 17:43:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46545) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lleq2-00015H-Hm for qemu-devel@nongnu.org; Tue, 25 May 2021 17:43:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621979024; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yLwpEgMvAHXbNeYOfXIWSjM/CB63m06JMbhh2KSRSME=; b=Sb0ZdaZvmJN4VkwuIOgBa9c0YOGlVFjJgsrSaAjnPJuCk7RPCnwOa4EofvD9hufNpW8dWB CnYoLgXV5L+DYYHr7aOrbVJO4nF8MQdGm72sKbxBCA8I/vW29+b6qgaRiyFIhB+Tscozzv 3qlvvDFcMDxG46nBeyKRxMRlmUPjqU4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-327-oiHeKwbqM1iVHS81EDGRZg-1; Tue, 25 May 2021 17:43:41 -0400 X-MC-Unique: oiHeKwbqM1iVHS81EDGRZg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 091EA107ACE4; Tue, 25 May 2021 21:43:40 +0000 (UTC) Received: from localhost (unknown [10.40.208.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id EABA41002F12; Tue, 25 May 2021 21:43:26 +0000 (UTC) Date: Tue, 25 May 2021 23:43:24 +0200 From: Igor Mammedov To: Eric DeVolder Subject: Re: [PATCH v2 3/7] ACPI ERST: support for ACPI ERST feature Message-ID: <20210525234324.050c0f5b@redhat.com> In-Reply-To: References: <1612817879-21511-1-git-send-email-eric.devolder@oracle.com> <1612817879-21511-4-git-send-email-eric.devolder@oracle.com> <20210406213131.21045f68@redhat.com> <20210414111759.66e78f71@redhat.com> <20210503190734.12e4c1ac@redhat.com> <20210517183138.5a429692@redhat.com> <20210520130047.1a89d520@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=imammedo@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=imammedo@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.371, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "ehabkost@redhat.com" , Konrad Wilk , "mst@redhat.com" , "jusual@redhat.com" , "qemu-devel@nongnu.org" , dgilbert@redhat.com, "pbonzini@redhat.com" , Boris Ostrovsky , "rth@twiddle.net" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 25 May 2021 20:22:26 +0000 Eric DeVolder wrote: > Igor, > Thank you for the pointers, I've turned the corner on the use of hostmem-file and am able to use it now! > I do have one question regarding hostmem-file. In the VMStateDescription, I used to have this for the contents > of the nvram (backed by a file): > > VMSTATE_VARRAY_UINT32(nvram, ERSTDeviceState, prop_size, 0, > vmstate_info_uint8, uint8_t), > > I've searched and I do not locate an example of passing a HostMemoryBackend object; how do I do that? if I'm not wrong, you do not need to do it, i.e. treat backing file as any other storage, i.e. put it on shared storage were VM's hard disks are located so source and target host can access it. alternatively you can mark MemoryRegion as migratable, which will make QEMU stream its content over migration socket automatically. In that case file associated with backend doesn't need to be shared between source and target hosts. I think this option is fine if file in question is small, but others might think otherwise. (obvious drawback is that it increases migration time) CCed David as he might have an opinion about it from migration point of view. > Thanks, > eric > > [...]