qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 15/31] target-i386: use memory API to implement


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 15/31] target-i386: use memory API to implement SMRAM
Date: Mon, 1 Jun 2015 12:38:14 +0200

On Mon, Jun 01, 2015 at 10:58:57AM +0200, Paolo Bonzini wrote:
> 
> 
> On 01/06/2015 10:10, Michael S. Tsirkin wrote:
> > > UNUSED is written as zeroes, so it will think SMM is _disabled_,
> > > unconditionally.  Note that d->smram_region is backwards: it aliases to
> > > VRAM, so it is enabled when SMRAM is closed and disabled when SMRAM is 
> > > open.
> > > 
> > > This is correct for KVM, though not for TCG.  Backwards migration is not
> > > supported officially upstream, and I think we can agree it is even less
> > > supported for TCG.
> >
> > Generally backwards migration is nice to have to test cross-version
> > migration properly by doing ping-pong.
> > Looks like we only need to set smm_enabled correctly before save,
> > and it'll work cleanly.
> > No?
> 
> Sort of.  Old QEMU is not able to handle the case where some CPUs are in
> SMM and some are not.  It is also a layering violation to compute
> smm_enabled from the CPUs.

Yes, I got that. But I guess typically only one CPU is running so
something like smm_enabled_any will DTRT, without layering violations,
right?

> Old SeaBIOS never uses SMM after POST, and executes a dozen instructions
> or so inside SMRAM.  New SeaBIOS does use SMM after POST (e.g. during
> grub), but it _literally_ executes two instructions inside SMRAM and
> then jumps to the F-segment, so even if you do not migrate smm_enabled
> the chance that something break is basically zero.
> 
> This is why I decided that it wasn't worth the complication (and the
> layering violation).
> 
> Paolo

To me it seems easier to support than to explain why we don't
have to, but if you are strongly against that, please add
code comments explaining all this.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]