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/
Home Products Support Community News


RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 17 Jun 2005 11:54:45 +0100
Delivery-date: Fri, 17 Jun 2005 10:56:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVyXcIsVytcYfebSZSjZoKeCr8e2wAuM30gAAJRi8AAAonBgA==
Thread-topic: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
> However, now I also suspected the necessity a bit. ;-b As you 
> said, that info is produced from outside, and consumed only 
> outside too. There's really no need to bother Xen as a 
> connector. Then cleaner way may be just to pass layout info 
> to device model from domain builder directly.
> If not done that yet, change will be made on qemu then. Do 
> you think so?

I believe this is the right approach.

> >In any event, can't your pursuade your unmodified IA64 
> domains that the 
> >MMIO region lives after the end of RAM? Or is it determined 
> to have it 
> >below 4GB or something?
> >It may be convention to have it below 4GB, but does the code 
> actually 
> >break if its above?
> Ideally the layout is decided by platform, and domain should 
> depend on EFI/ACPI table to make its life. However several 
> issues I think as problem now:
> - Experienced users may feel strange to see a layout not like 
> real hardware, if they don't realize running at VMM.
> - Not familiar with qemu... If unmodified domain is 
> configured with 4G memory, and then all MMIO region is moved 
> to >4G area, I'm not sure whether some old 32bit DMA 
> controller within qemu can work properly without re-compile?
> - On unmodified x86 domain with PAE enabled, can 32bit domain 
> handle MMIO >4G if following same policy to move MMIO beyond 
> memory? (If device model has no e820 map). I think the 
> internal type for I/O may be always 32bit... :)

That final point is interesting. Linux is careful thesedays to avoid
ever storing physcial address in 32bits, but its possible earlier
versions were not. 

Anyhow, this is all a discussion for 3.1. I don't want to get distracted
from finishing 3.0 right now, and encourage everyone else to think about
the 3.0 todo list too...


Xen-devel mailing list