[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
Be sure you are building the ioemu you think you are. By default we now build in directory tools/ioemu-remote, which is a clone of an out-of-tree git repository. -- Keir On 29/7/08 12:22, "Ke, Liping" <liping.ke@xxxxxxxxx> wrote: > Hi, Selander > > Today I had a rough try on Guyader's patch, change xen_platform.c > xen_platform_ioport_writeb ->xc_hvm_set_mem_type last param from 0x40 to 0x20. > Seems not working if I am not wrong. > > The patch you mentioned here is the one below? > + if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x20) || > xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xf0, 0x10)) > fprintf(logfile,"xen_platform: unable to change ro/rw " > "state of ROM memory area!\n"); > else > > > > Regards, > Criping > ________________________________________ > From: Trolle Selander [mailto:trolle.selander@xxxxxxxxx] > Sent: 2008年7月29日 18:41 > To: Keir Fraser > Cc: Ke, Liping; Jean Guyader; Xu, Jiajun; xen-devel; Ian Jackson > Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up > > 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@xxxxxxxxx> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |