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: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 17 Jun 2005 19:07:06 +0800
Delivery-date: Fri, 17 Jun 2005 11:06:18 +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: AcVyXcIsVytcYfebSZSjZoKeCr8e2wAuM30gAAJRi8AAAonBgAAAlM6Q
Thread-topic: [Xen-devel] [Patch 2/2] Add dom0_get_sectioninfo for XEN/VTI
>-----Original Message-----
>From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx]
>Sent: Friday, June 17, 2005 6:55 PM
>To: Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx
>> 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.

So I gave up requesting for new dom0 operation now. :)

>> - 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
>from finishing 3.0 right now, and encourage everyone else to think
>the 3.0 todo list too...



Xen-devel mailing list