[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF |
Date: |
Fri, 16 Aug 2019 09:42:12 +0200 |
On Thu, 15 Aug 2019 18:24:53 +0200
Paolo Bonzini <address@hidden> wrote:
> On 15/08/19 18:07, Igor Mammedov wrote:
> > Looking at Q35 code and Seabios SMM relocation as example, if I see it
> > right QEMU has:
> > - SMRAM is aliased from DRAM at 0xa0000
> > - and TSEG steals from the top of low RAM when configured
> >
> > Now problem is that default SMBASE at 0x30000 isn't backed by anything
> > in SMRAM address space and default SMI entry falls-through to the same
> > location in System address space.
> >
> > The later is not trusted and entry into SMM mode will corrupt area + might
> > jump to 'random' SMI handler (hence save/restore code in Seabios).
> >
> > Here is an idea, can we map a memory region at 0x30000 in SMRAM address
> > space with relocation space/code reserved. It could be a part of TSEG
> > (so we don't have to invent ABI to configure that)?
>
> No, there could be real mode code using it.
My impression was that QEMU/KVM's SMM address space is accessible only from
CPU in SMM mode, so SMM CPU should access in-depended SMRAM at 0x30000 in
SMM address space while not SMM CPUs (including real mode) should access
0x30000 from normal system RAM.
> What we _could_ do is
> initialize SMBASE to 0xa0000, but I think it's better to not deviate too
> much from processor behavior (even if it's admittedly a 20-years legacy
> that doesn't make any sense).
Agreed, it's better to follow spec, that's one of the reasons why I was toying
with idea of using separate SMRAM at 0x30000 mapped only in SMM address space.
Practically we would be following spec: SDM: 34.4 SMRAM
"
System logic can use the SMI acknowledge transaction or the assertion of the
SMIACT# pin to decode accesses to
the SMRAM and redirect them (if desired) to specific SMRAM memory. If a
separate RAM memory is used for
SMRAM, system logic should provide a programmable method of mapping the SMRAM
into system memory space
when the processor is not in SMM. This mechanism will enable start-up
procedures to initialize the SMRAM space
(that is, load the SMI handler) before executing the SMI handler during SMM.
"
Another benefit that gives us, is that we won't have to pull in
all existing CPUs into SMM (essentially another stop_machine) to
guarantee exclusive access to 0x30000 in normal RAM.
>
> Paolo
- Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF, (continued)
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Laszlo Ersek, 2019/08/15
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/08/15
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Paolo Bonzini, 2019/08/15
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Yao, Jiewen, 2019/08/15
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Paolo Bonzini, 2019/08/16
- Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF, Yao, Jiewen, 2019/08/16
- Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF, Igor Mammedov, 2019/08/15
- Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF, Paolo Bonzini, 2019/08/15
- Re: [Qemu-devel] CPU hotplug using SMM with QEMU+OVMF,
Igor Mammedov <=