Re: [Qemu-devel] [PATCH] piix: do not reset APIC base address (0x80) on piix4_reset.

[Marcel Apfelbaum]

On Thu, 2013-12-19 at 11:06 -0500, Kevin O'Connor wrote:
> On Wed, Dec 18, 2013 at 06:55:24PM +0200, Marcel Apfelbaum wrote:
> > On Wed, 2013-12-18 at 11:34 -0500, Paolo Bonzini wrote:
> > > Or put an array of (bdf, offset, size, value) tuples somewhere in low 
> > > memory,
> > > fill it at startup, and reproduce it blindly at S3 resume time.  This is 
> > > similar
> > > to what UEFI does.
> > Could you please elaborate a little more?
> > Let me see first if I understand the problem:
> > PciDevices list is a list of pointers that cannot be used
> > inside init code which is 16 bit code, right?
> 
> FYI, all the code at this point is 32bit code.  Both the SeaBIOS init
> code (aka POST) and the SeaBIOS resume code run in 32bit mode.
> 
> The problem is that SeaBIOS has ownership of all ram during its
> initialization phase, but it must release ownership during its runtime
> phase.  (During the runtime phase, the OS has ownership of the bulk of
> ram and SeaBIOS only has a tiny fraction that it reserves.)  The PCI
> device cache that SeaBIOS builds is not placed in reserved memory, and
> that's why it is marked as VARVERIFY32INIT.  It's to try and prevent
> pointers that no longer point to valid memory from being accessed
> after the init phase has completed.
> 
> The error it produces is correct - one must not access the pci_device
> structs from the resume code in the current code.
Thank you Kevin for the detailed explanation! By the way, do you know
how this fraction is allocated by Seabios and how can one "decide" to move
the device cache to this region reserved by the BIOS ? (not that I want to,
but to understand how Seabios does this)

Thanks again!
Marcel

> 
> > If I got it right, the solution is to find another way to iterate
> > over pci devices? If yes, *when* would this data be put in memory and 
> > "when"?
> > A pointer to the right direction would be appreciated,
> 
> A good question.  I'll take a look at Michael's patch.

> 
> -Kevin