On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
> Gleb Natapov wrote:
> >On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
> >>No. You have to physically shut down and start up again. That's
> >>the right semantics IMHO.
> >>
> >Reset is equivalent (or should be) to shut down and start up again.
>
> Not at all. Reset can happen in a lot of different ways, some that
We support only one way of reset: hard reset. It equivalent to full
HW power cycling. ACPI spec define ACPI reset as equivalent to HW power
cycling too BTW (see 4.7.3.6).
> there is really no way to detect (jumping right to BIOS vector).
This is not reset at all from qemu POV. No need to reload ROMS.
> From a hardware perspective, powering down a CPU and powering it on
> again behaves very differently than reset (consider the VT
> enablement MSRs).
May be you are confusing cpu reset by INIT with CPU reset by power
cycling. system_reset (or triple fault or kbd reset or ACPI reset)
does the later.
>
> >>>Second what if ROM size have changed (on destination it is
> >>>smaller)?
> >>Then we're in trouble :-)
> >Yeah, we are. May be relaying on file size is not good enough heuristic
> >to determine ROM BAR size.
>
> Practically speaking, I don't think it's a huge problem to be
> honest. It's a very unlikely scenario. We could make the rom size
> a qdev property which would allow a user to explicitly deal with
> this case.
Agree that it is unlikely, but I don't want to be the one debugging it.
>
> >>But the fw_cfg rom loading doesn't seem handle migration :-/
> >>
> >Looks like it. We should send them over during migration too.
>
> We should just qemu_ram_alloc() that memory regardless of whether we
> every map it into the guest. Since roms can be large, we want to
> send their contents over during the live part of migration. If we
> use qemu_ram_alloc(), we get that for free.
>
This will work only if we assume that rom file size doesn't shrink,
--
Gleb.
