From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.5440.1654076035970738680 for ; Wed, 01 Jun 2022 02:33:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IX6khkyq; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654076035; 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: in-reply-to:in-reply-to:references:references; bh=WF0su7IRMD3vFYHye9giR0kvktEY1JX0lBm/Dl17v2E=; b=IX6khkyq+YFFrXxQJJyIkmLwXH2Tl8S8bu95gNtf8Ni0OPXbhHIS3pLXe4VACt4Dqy90tM iZf+AhjAf/CccPfWjpvZrJ4yXdLbZ4Nlqk5NIYG6jPOWPeX0+RXfgOmsG6+ukLlPi4/nSl PPd94J7LMwR8K1Wpgf9xsSB6FZ25weQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-368-qYot9gCgOh-9kSSxPYbZ0g-1; Wed, 01 Jun 2022 05:33:54 -0400 X-MC-Unique: qYot9gCgOh-9kSSxPYbZ0g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9F9223C0D199; Wed, 1 Jun 2022 09:33:53 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 562C11410F36; Wed, 1 Jun 2022 09:33:53 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 101E71800612; Wed, 1 Jun 2022 11:33:52 +0200 (CEST) Date: Wed, 1 Jun 2022 11:33:52 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, graf@amazon.com Cc: Ard Biesheuvel , Leif Lindholm , Dandan Bi , Zhichao Gao , Liming Gao Subject: Re: [edk2-devel] [PATCH 00/12] Introduce Bootlog DEBUG() output Message-ID: <20220601093352.hx4w447n7myc7re6@sirius.home.kraxel.org> References: <20220527024317.13476-1-graf@amazon.com> MIME-Version: 1.0 In-Reply-To: <20220527024317.13476-1-graf@amazon.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 27, 2022 at 04:43:05AM +0200, Alexander Graf via groups.io wrote: > I recently looked at improving the bootup performance of virtual machines > and was amazed by the fact that there is no logging / tracing framework > available that would give me a full picture of the Pre-OS phase including > time stamps and boot loaders (such as grub) without writing data to the > serial port - which taints all measurements. Hmm. Maybe it's time to tackle the log performance problem for virtual machines? Create a debug log device with DMA support, so we don't need a vmexit for every single character we want log? That will not completely kill the boot slowdown / measurement tainting problem, but it should be an order of magnitude smaller. Advantages: We can leave the time stamp collection to the host, avoiding issues like not knowing the tsc frequency in early firmware code. You can read the log even in case the guest doesn't boot up successfully. > 3) Extensability to other payloads - The FPDT infrastructure considers > everything as owned by PerformanceLib. I would like to create a one > stop place for arbitrary UEFI applications to also put performance > measurement data. How does that relate to coreboot? coreboot has logging-to-memory too. Not sure what the state is, there have been discussions on the coreboot list about changing that from a pure text log to something structed with timestamps a while back. Don't know whenever this did actually happen. So, when adding logging-to-memory to edk2 it surely make sense to coordinate that with coreboot, so we'll have both coreboot and edk2 logs there in case edk2 runs as coreboot payload. take care, Gerd