From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Re: Continuing problems booting
Date: Mon, 09 Mar 2009 09:35:41 -0700
Message-ID: <49B5455D.2040407@goop.org>
References: <alpine.GSO.2.00.0902201239010.757@algedi.dur.ac.uk>	<alpine.GSO.2.00.0902201554500.757@algedi.dur.ac.uk>	<alpine.LFD.2.00.0902211225540.14632@vega4.dur.ac.uk>	<49A0F68D.9070306@goop.org>	<alpine.LFD.2.00.0902220922040.4149@vega1.dur.ac.uk>	<alpine.LFD.2.00.0902221449410.17196@vega3.dur.ac.uk>	<49A187B8.7000902@goop.org>	<alpine.LFD.2.00.0902222257230.4472@vega4.dur.ac.uk>	<49A1DD80.1080903@goop.org>	<alpine.LFD.2.00.0902222359090.4472@vega4.dur.ac.uk>	<49A241EC.3050300@goop.org>	<alpine.LFD.2.00.0902242228550.12607@vega3.dur.ac.uk>	<alpine.LFD.2.00.0902272317030.17305@vega3.dur.ac.uk>
	<49A890FF.4080803@goop.org> <49ABAF7C.6050906@redhat.com>
	<49AF5FEB.4010508@goop.org> <49AF80C1.2060307@redhat.com>
	<49AFB122.5040301@redhat.com> <49B02069.5000207@goop.org>
	<49B12FE4.7050503@redhat.com> <49B139A1.6050002@redhat.com>
	<49B13F70.1060802@goop.org> <49B537F2.8070106@redhat.com>
	<49B53C44.1090706@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <49B53C44.1090706@redhat.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: xen-devel@lists.xensource.com, M A Young <m.a.young@durham.ac.uk>
List-Id: xen-devel@lists.xenproject.org

Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>   
>> i.e. early iomap setup is different in 32bit and 64bit.  Which would
>> also explain why vgacon works just fine in 64bit mode.
>>     
>
> I think it is something else.
>
> arch/x86/mm/init_64.c, phys_pte_init():
>
>         /*
>          * We will re-use the existing mapping.
>          * Xen for example has some special requirements, like mapping
>          * pagetable pages as RO. So assume someone who pre-setup
>          * these mappings are more intelligent.
>          */
>         if (pte_val(*pte)) {
>                 pages++;
>                 continue;
>          }
>
> I think that does also make sure vga mappings are not overwritten with
> something else.  32bit seems to have no equivalent for this though ...
>   
It does, in a fairly hacky and disgusting way.  During boot, we use a 
special version of xen_set_pte which ignores attempts to convert a 
RO->RW mapping, in order to protect existing pagetable mappings.  But it 
probably won't help if someone is trying to replace the ISA mappings 
with something else.  In theory all those mappings should be created 
with _PAGE_IOMAP anyway, so we'd do the right thing; but I don't think 
that's happening.  In the meantime I could extend the hack to look for 
attempts to overwrite _PAGE_IOMAP mappings or something...  Or force 
_PAGE_IOMAP on for pfns in the ISA window.

Fortunately there seems to be an active attempt to unify 32 and 64-bit 
mapping creation, should help (so long as it converges on the 64-bit 
code, which is more sensible).

    J