From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] [HVM] Patches to make HVM capable of running OS/2. Date: Fri, 16 Mar 2007 12:21:07 +0000 Message-ID: References: <515922b50703160507v5da9ad6eg3389c46044a0f8d1@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1719585393==" Return-path: In-Reply-To: <515922b50703160507v5da9ad6eg3389c46044a0f8d1@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Trolle Selander , xen-devel@lists.xensource.com Cc: Mats.Petersson@amd.com, thomas.woller@amd.com List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1719585393== Content-type: multipart/alternative; boundary="B_3256892467_52420061" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3256892467_52420061 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 16/3/07 12:07, "Trolle Selander" wrote: > This is a "minimally intrusive" way to fix an issue that I think should r= eally > be fixed in a different way. > Currently, the shared info, ioreq and buffered_io pages are mapped into t= he > guest's memory space as the three highest page frames. They are "protecte= d" > from use by being marked as reserved in the e820 ram map. However, legacy > software won't know about the e820 call, and since the older e801 call re= ports > all ram, including the shared pages, the guest OS will end up using them = as > regular ram with disastrous results. > This patch makes the older e801 bios call report one 64kb block less memo= ry, > thus "protecting" the shared pages from older OS's in a similar manner to= the > e820 call, at the expense of 52kb of wasted ram (the e801 call reports me= mory > in 64kb blocks, so no way around this). I think we should reserve a 64kB block just below 0xF0000000 (by marking E820_RESERVED) and put these =8Cspecial pages=B9 in there. The fact they=B9re not currently mentioned by the e820 map at all is pretty bad =8B an OS might decide to remap PCI devices on top of them, for example! -- Keir --B_3256892467_52420061 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH] [HVM] Patches to make HVM capable of running= OS/2. On 16= /3/07 12:07, "Trolle Selander" <trolle.selander@gmail.com> w= rote:

This is a "minimally intrusive" way to fix an= issue that I think should really be fixed in a different way.
Currently, the shared info, ioreq and buffered_io pages are mapped into the= guest's memory space as the three highest page frames. They are "prote= cted" from use by being marked as reserved in the e820 ram map. However= , legacy software won't know about the e820 call, and since the older e801 c= all reports all ram, including the shared pages, the guest OS will end up us= ing them as regular ram with disastrous results.
This patch makes the older e801 bios call report one 64kb block less memory= , thus "protecting" the shared pages from older OS's in a similar = manner to the e820 call, at the expense of 52kb of wasted ram (the e801 call= reports memory in 64kb blocks, so no way around this).

I think we should reserve a 64kB block just below 0xF0000000 (by marking E8= 20_RESERVED) and put these ‘special pages’ in there. The fact th= ey’re not currently mentioned by the e820 map at all is pretty bad = 212; an OS might decide to remap PCI devices on top of them, for example!
 -- Keir
 --B_3256892467_52420061-- --===============1719585393== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1719585393==--