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.129.124]) by mx.groups.io with SMTP id smtpd.web11.30804.1635161279333429962 for ; Mon, 25 Oct 2021 04:27:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ErENDeYM; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635161278; 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=B++p1wvT1izdhX/QDxs9zczotNtzYrjaJtHR2Oz1g18=; b=ErENDeYMz0FOe+pMUvpP64ZLo/xTfjO/ZL/xIJWpcSiDX6mkUKtV/+1v8IgiqyBY588PHs Fk+laHq6NsodVu36Z/9GaYLal/bwDP5evPCp5Gq9JUFd+O4/4XEWdnE1jgdzojdCU/thEC W6ADMVt68SoQzW1H7trwp+5OJKJJPIA= 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-99-5cdheeSCNyeHnVjqrC2ipQ-1; Mon, 25 Oct 2021 07:27:54 -0400 X-MC-Unique: 5cdheeSCNyeHnVjqrC2ipQ-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 DF4F9802B7E; Mon, 25 Oct 2021 11:27:52 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8D932101E5BF; Mon, 25 Oct 2021 11:27:52 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id DCF221800791; Mon, 25 Oct 2021 13:27:50 +0200 (CEST) Date: Mon, 25 Oct 2021 13:27:50 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, min.m.xu@intel.com Cc: Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V2 28/28] OvmfPkg: Add LocalApicTimerDxe Message-ID: <20211025112750.mytcbe3yawtidj7q@sirius.home.kraxel.org> References: <20211012130207.zmx2yf5inpkoalqf@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Oct 25, 2021 at 07:37:33AM +0000, Min Xu wrote: > On October 12, 2021 9:02 PM, Gerd Hoffmann wrote: > > On Tue, Oct 05, 2021 at 11:39:39AM +0800, Min Xu wrote: > > > RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429 > > > > > > TDX guest supports LocalApicTimer. But in current OvmfPkg the > > > supported timer is 8254TimerDxe. So > > > gUefiOvmfPkgTokenSpaceGuid.PcdTimerSelector > > > is introduced to select the running Timer. The Timer driver will check > > > the TimerSelector in its entry point. The default Timer is 8254. > > > > Hmm. > > > > We already have a local apic timer implementation (XenTimerDxe). Works fine > > with kvm, microvm already uses that. See commit 76602f45dcd9 > > ("OvmfPkg/Microvm: use XenTimerDxe (lapic timer)"). > > > > So, first I'd suggest to just use that (maybe rename the thing to avoid confusion > > as it isn't really Xen specific). > > Thanks for reminder. We can use XenTimerDxe as the LocalApicTimerDxe in Tdx guest. There will be a separate patch to rename XenTimerDxe to LocalApicTimerDxe in the next version. You can also split this off into a separate patch series as it shouldn't have any tdx dependency. > I am not quite sure if there will be any side effect if we switch ovmf > (X64) from 8254 to lapic unconditionally. Quick smoke test does show > no obvious problems (EDK2 CI shows no error either). But since 8254 > timer has already been used in OvmfPkgX64, then there always a reason > why 8254 is used. Note that 8254TimerDxe was not written for OVMF, it was moved over from PcAtChipsetPkg to OvmfPkg in 2019. Probably because OVMF was the only user left. Most likely the reason OVMF used 8254TimerDxe initially was that it could just use the existing driver in PcAtChipsetPkg. And it simply hasn't been changed ever. Hmm, CSM support was moved in 2019 too, checking ... Yes, CSM support depends on 8254 (and 8259) drivers. > I am thinking if it is a more secure way to introduce PcdTimerSelector > (to select timer in run-time) this time. We can revisit this proposal > (switch ovmf from 8254 to lapic unconditionally) when we are pretty > sure there is no side effect in the future. I still think we don't need a runtime switch. Continue using 8254TimerDxe for CSM_ENABLE=TRUE builds should be enough. take care, Gerd