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-ia64-devel

[Xen-ia64-devel] [PATCH] Another important Xen/ia64 domU/vbd fix

To: <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] [PATCH] Another important Xen/ia64 domU/vbd fix
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 4 Jan 2006 20:26:15 +0800
Delivery-date: Wed, 04 Jan 2006 12:31:22 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYRKg3vtmScnrGbT9KBa+YyrAgJwg==
Thread-topic: [PATCH] Another important Xen/ia64 domU/vbd fix
Hi, Dan,
        Attached is another important Xen/ia64 fix to enable domU/vbd
working on system with >1G hole in dom0's memory layout. Once memmap of
dom0 is virtualized, there's no way for dom0 to access machine frames
(like from domU) which is outside of EFI memory layout known by dom0,
because of no mapping. So we have to disable CONFIG_VIRTUAL_MEM_MAP
explicitly, to ensure dom0 constructing a physical memmap array.

Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>

        Following is background why this problem doesn't happen
previously since CONFIG_VIRTUAL_MEM_MAP is on for a long time. ;-)

[Q] Which changeset caused this regression on Tiger box?
[A]
changeset:   8374:545ba1b126ca2f06861c3982c4da33dd310e7717
user:        djm@xxxxxxxxxxxxxxx
date:        Wed Dec 21 04:11:17 2005
summary:     Important domU/vbd fix.  Reserve top granule of machine
memory for
dom0.

        Even when CONFIG_VIRTUAL_MEM_MAP is on, memmap will be
virtualized only when max hole presented by EFI memmap is larger than
1G. Previously dom0 is allocated with machine address [128M - 640M] on
my box, so there's no large hole. However when r8374 is checked in,
another granule close to max_pfn is also reserved for dom0. In my Tiger
box, max pfn is close to 2G and so a hole larger than 1G occurs and
vmem_map is created there. Then when blkback is up, accessing foreign
frames of front-end panic dom0.

[Q] Why does tip work for Dan's box?
[A] From the bootlog sent out by Dan today, it seems max pfn is < 1G
(without Tristan's 4G patch):
(XEN) Init boot pages: 0x1000000 -> 0x4000000.
(XEN) Init boot pages: 0x8f89030 -> 0x3f5e4000.
(XEN) Init boot pages: 0x3fb00000 -> 0x3fb2c000.
(XEN) Init boot pages: 0x4040000000 -> 0x407de8a000.

        So there's no hole > 1G, and memmap is still physical continuous
array. Actually once Tristan's 4G patch works, same problem will also
occur on Dan's box since there'll be a granule locating > 4G and thus
vmem_map will jump out to handle big hole.

Thanks,
Kevin

Attachment: remove_vmemmap_config.patch
Description: remove_vmemmap_config.patch

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