On 11/04/15 17:55, Kinney, Michael D wrote: > Laszlo, > > BaseXApicX2ApicLib is intended to be used by platforms that support more > >=256 CPUs. > > If the current system configuration is < 256 CPUs, then the platform will > typically stay in APIC mode. If >= 256 CPUs are detected, then X2 APIC mode > can be enabled using the following API. > > VOID > EFIAPI > SetApicMode ( > IN UINTN ApicMode > ) > > So just adding BaseXApicX2ApicLib to the DSC does not enable X2 APIC mode. > You have to add logic to enable X2 APIC mode. > > I see that QEMU is limited to 255 VCPUs, so the use of BaseXApicLib makes > sense. Are OVMF configurations supported with >= 256 VCPUs?
I don't think so, but 64-bit Linux guest kernels enable x2apic mode anyway, apparently regardless of the VCPU count and topology. This is normally not a problem, but with SMM support, the APIC library gets used (within SMM) *after* Linux configures x2apic mode. This causes the "basic" library instance to blow up. Therefore I flipped the library class resolution to the one instance that supports x2apic mode, but only for the SMM build of OVMF. So, the question Paolo and I have is *not* whether we must use the x2apic-capable library in the SMM build -- that is a fact, forced by the X64 Linux guest kernel's behavior. Neither is our question "how could we enable x2apic mode"? About that, we don't care at the moment. :) Instead, our question is if we can use BaseXApicX2ApicLib even in the *non*-SMM build, without fear of regressions. In other words, if BaseXApicX2ApicLib can safely replace BaseXApicLib in a build where BaseXApicLib would be otherwise fully sufficient. Because, if the answer is "yes, it is compatible", then we shouldn't complicate the library class resolution in the OVMF DSC files, making it dependent on the build type (i.e., SMM -> BaseXApicX2ApicLib, non-SMM -> BaseXApicLib). Rather than that, we should indiscriminately use BaseXApicX2ApicLib. So... is BaseXApicX2ApicLib compatible with BaseXApicLib in the domain where the latter would work sufficiently? Thanks! Laszlo > > Thanks, > > Mike > >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Wednesday, November 04, 2015 2:41 AM >> To: Paolo Bonzini; edk2-de...@ml01.01.org; Kinney, Michael D; Fan, Jeff; >> Justen, Jordan L >> Subject: Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance >> with x2apic support if SMM_REQUIRE >> >> On 11/04/15 09:48, Paolo Bonzini wrote: >>> >>> >>> On 03/11/2015 22:00, Laszlo Ersek wrote: >>>> + >>>> +!if $(SMM_REQUIRE) == TRUE >>>> + >> LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf >>>> +!else >>>> LocalApicLib|UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf >>>> +!endif >>>> + >>> >>> Can we enable BaseXApicX2ApicLib unconditionally? >> >> I think I am technically capable of that :), but should we? We haven't >> used BaseXApicX2ApicLib thus far in OVMF, so I can't predict at all if >> it could regress stuff or not. If it causes problems with the >> SMM_REQUIRE build, so be it, that's new stuff, but I wanted to avoid >> such a global change for the traditional build. >> >> I'm not against it, I just don't have experience with BaseXApicX2ApicLib. >> >> Mike, Jeff, Jordan -- what do you think? Why do separate BaseXApicLib >> and BaseXApicX2ApicLib instances exist? And why has OvmfPkg always used >> the former? If it has only been for simplicity's sake, and >> BaseXApicX2ApicLib is otherwise widely used internally at Intel, then I >> think Paolo is right, and we should just keep the OVMF DSCs simple. >> >> Thanks >> Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
