Paolo, It is my understanding that real HW hot plug uses the SDM defined methods. Meaning the initial SMI is to 3000:8000 and they rebase to TSEG in the first SMI. They must have chipset specific methods to protect 3000:8000 from DMA.
Can we add a chipset feature to prevent DMA to 64KB range from 0x30000-0x3FFFF and the UEFI Memory Map and ACPI content can be updated so the Guest OS knows to not use that range for DMA? Thanks, Mike > -----Original Message----- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Thursday, August 22, 2019 3:18 PM > To: Kinney, Michael D <michael.d.kin...@intel.com>; > Laszlo Ersek <ler...@redhat.com>; r...@edk2.groups.io; > Yao, Jiewen <jiewen....@intel.com> > Cc: Alex Williamson <alex.william...@redhat.com>; > de...@edk2.groups.io; qemu devel list <qemu- > de...@nongnu.org>; Igor Mammedov <imamm...@redhat.com>; > Chen, Yingwen <yingwen.c...@intel.com>; Nakajima, Jun > <jun.nakaj...@intel.com>; Boris Ostrovsky > <boris.ostrov...@oracle.com>; Joao Marcal Lemos Martins > <joao.m.mart...@oracle.com>; Phillip Goerl > <phillip.go...@oracle.com> > Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using > SMM with QEMU+OVMF > > On 22/08/19 22:06, Kinney, Michael D wrote: > > The SMBASE register is internal and cannot be directly > accessed by any > > CPU. There is an SMBASE field that is member of the > SMM Save State > > area and can only be modified from SMM and requires the > execution of > > an RSM instruction from SMM for the SMBASE register to > be updated from > > the current SMBASE field value. The new SMBASE > register value is only > > used on the next SMI. > > Actually there is also an SMBASE MSR, even though in > current silicon it's read-only and its use is > theoretically limited to SMM-transfer monitors. If that > MSR could be made accessible somehow outside SMM, that > would be great. > > > Once all the CPUs have been initialized for SMM, the > CPUs that are not > > needed can be hot removed. As noted above, the SMBASE > value does not > > change on an INIT. So as long as the hot add operation > does not do a > > RESET, the SMBASE value must be preserved. > > IIRC, hot-remove + hot-add will unplugs/plugs a > completely different CPU. > > > Another idea is to emulate this behavior. If the hot > plug controller > > provide registers (only accessible from SMM) to assign > the SMBASE > > address for every CPU. When a CPU is hot added, QEMU > can set the > > internal SMBASE register value from the hot plug > controller register > > value. If the SMM Monarch sends an INIT or an SMI from > the Local APIC > > to the hot added CPU, then the SMBASE register should > not be modified > > and the CPU starts execution within TSEG the first time > it receives an SMI. > > Yes, this would work. But again---if the issue is real > on current hardware too, I'd rather have a matching > solution for virtual platforms. > > If the current hardware for example remembers INIT- > preserved across hot-remove/hot-add, we could emulate > that. > > I guess the fundamental question is: how do bare metal > platforms avoid this issue, or plan to avoid this issue? > Once we know that, we can use that information to find a > way to implement it in KVM. Only if it is impossible > we'll have a different strategy that is specific to our > platform. > > Paolo > > > Jiewen and I can collect specific questions on this > topic and continue > > the discussion here. For example, I do not think there > is any method > > other than what I referenced above to program the > SMBASE register, but > > I can ask if there are any other methods.
