WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: Paravirtualizing bits of acpi access

To: 'Jeremy Fitzhardinge' <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: Paravirtualizing bits of acpi access
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 24 Mar 2009 13:45:07 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Brown, Len" <len.brown@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, "Rafael J. Wysocki" <rjw@xxxxxxx>, "linux-acpi@xxxxxxxxxxxxxxx" <linux-acpi@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Mar 2009 22:47:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49C872D1.8060403@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49C484B7.20100@xxxxxxxx> <200903231920.12991.rjw@xxxxxxx> <49C7DDDC.2050103@xxxxxxxx> <200903232127.40683.rjw@xxxxxxx> <49C86C41.1060803@xxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD60E5E877A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49C872D1.8060403@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmsQ11/esceSQ23R22/AKB0pX+5OgAAAqCA
Thread-topic: [Xen-devel] Re: Paravirtualizing bits of acpi access
>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx] 
>Sent: Tuesday, March 24, 2009 1:43 PM
>
>Tian, Kevin wrote:
>> The reason why those useless code are prevented, is in case of
>> clobberring 0-1M area which if contains valid Xen content. in
>> acpi_save_state_mem, dom0's wakeup code is copied to area
>> allocated in acpi_reserve_bootmem. If every Xen's usage on 0-1M
>> is based on copy-on-use style, such as trampoline code for AP
>> boot, it's ok. But I'm not sure whether Xen puts some persistent
>> content there. IIRC, that boot time allocation usually returns sth
>> like 0x90000 since wakeup stub is first run in real mode. But if
>> for dom0 alloc_bootmem_low never gives <1M page, then this
>> prevention could be skipped as your thought.
>>   
>
>Yes, but the memory allocated is only in 0-1M in dom0's 
>pseudo-physical 
>space, not in Xen's machine space.  It allocates the memory and does a 
>virt_to_phys on it, but there's no special effort to remap it 
>as mfns or 
>anything.  There should be no possible conflict with Xen's use of the 
>real 0-1M region.

OK, then it's safe to avoid that change. I had thought that dom0's 0-1M
is identity-mapped to machine 0-1M... :-)

Thanks,
Kevin

>
>Not that I've actually tried to execute that patch yet, so I 
>could well 
>be overlooking something...
>
>    J
>

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

<Prev in Thread] Current Thread [Next in Thread>