Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Yes, good point, but yet the POST still happens. :-) I wonder why...

 -- Keir

On 29/7/08 11:40, "Trolle Selander" <trolle.selander@xxxxxxxxx> wrote:

> I don't think there is such a thing as "warm reset" with a Xen HVM - one of the self-modifying functrions at first boot is clobber_entry_point() which overwrites the bios entry with a jump to machine_reset. The patch I posted earlier on this issue should take of the acpi table issue, but maybe we want to tighten the "writable window" to be as narrow as possible?
>
> -- Trolle
>
> 2008/7/29 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
> > I can reproduce the issue. It's two things: firstly certain ACPI tables do
> > need to be writable (e.g., firmware_waking_vector). Secondly, when the BIOS
> > re-POSTs it is writing to itself, which we allow on initial boot but not on
> > warm reset. That needs fixing. I'll take a look at doing so.
> >
> >  -- Keir
> >
> > On 29/7/08 10:53, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
> >
> > > Hi,
> > >
> > > I didn't actually test cs18120, so I'm not certain that I removed all writes
> > > to write-protected ROM regions. If such writes are happening then the logging
> > > at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to the Xen console.
> > > You may need a debug build of Xen to see them, or add guest_loglvl=all as a
> > > Xen boot parameter.
> > >
> > > The EBDA is simply a RAM area for the BIOS to stash important private (and in
> > > some cases public) data. Usually it is located just below the VGA framebuffer,
> > > at around 0x9fc00. Certain parts of it have a well-defined format; other parts
> > > are completely private to the BIOS. For our purposes all we care about is that
> > > we do not write-protect it, and we just stash an extra 8-bit variable within
> > > it to indicate if this is a warm return from S3.
> > >
> > >  -- Keir
> > >
> > > On 29/7/08 10:47, "Ke, Liping" <liping.ke <http://liping.ke> @intel.com <http://intel.com> > wrote:
> > >
> > >> Hi, Selander and Jean
> > >>
> > >> Jiajun is reporting similar (on cs18132) error in latest cs.
> > >> I found when keeping cs18120, revert 18027, everything is just ok.
> > >> So cs18120 itself works fine, yet if cs18027 set ro-attributes, problem still
> > >> exist.
> > >>
> > >> Just did some debugging, from ITP, one cpu is in default_idle loop, other one
> > >> is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think this
> > >> might be the same problem Guyader meet before?
> > >>
> > >> I am not familiar about EBDA, could somebody help me to have a look?
> > >>
> > >> Thanks& Regards,
> > >> Criping
> > >>
> > >> -----Original Message-----
> > >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
> > >> Sent: 2008年7月24日 20:45
> > >> To: Jean Guyader; Trolle Selander
> > >> Cc: xen-devel; Ian Jackson
> > >> Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
> > >>
> > >> On 24/7/08 13:12, "Jean Guyader" <jean.guyader@xxxxxxxxxxxxx> wrote:
> > >>
> > >>> Jean Guyader wrote:
> > >>>> I already tried to reduce the rw area, and just keep 0xe0 -> 0xef. But
> > >>>> obviously it doesn't work the device model needs to write on this frame
> > >>>> 0xf1. I still don't figure out why.
> > >>>
> > >>> The rombios write on this page because of this flags s3_resume_flag
> > >>> (rombios.c:98883). I don't know if it's a good reason to set the
> > >>> rombios as rw. However it's bad to set the first 2 pages of the rombios
> > >>> as rw just because of that.
> > >>> Any suggestions ?
> > >>
> > >> In that case the changes to ioemu-remote should be reverted. The correct fix
> > >> is to move the S3 resume flag into the EBDA. I have committed this fix as
> > >> xen-unstable.hg:18120.
> > >>
> > >>  -- Keir
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Xen-devel mailing list
> > >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> > >> http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel