| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in tools
|
To: |
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm) |
|
From: |
Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> |
|
Date: |
Wed, 17 Nov 2010 14:23:25 +0000 |
|
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "bruce.edge@xxxxxxxxx" <bruce.edge@xxxxxxxxx>, "Gianni@xxxxxxxxxxxxxxxxxxxx" <Gianni@xxxxxxxxxxxxxxxxxxxx>, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx> |
|
Delivery-date: |
Wed, 17 Nov 2010 06:24:18 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20101116155016.GA6535@xxxxxxxxxxxx> |
|
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> |
|
Organization: |
Citrix Systems, Inc. |
|
References: |
<4CE18AD6.5070102@xxxxxxxx> <C907413B.A0AD%keir@xxxxxxx> <20101115231133.GA12364@xxxxxxxxxxxx> <4CE1D921.2010703@xxxxxxxx> <1289899586.31507.717.camel@xxxxxxxxxxxxxxxxxxxxxx> <20101116155016.GA6535@xxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Tue, 2010-11-16 at 15:50 +0000, Konrad Rzeszutek Wilk wrote:
> disclaimer:
> This email got a bit lengthy - so make sure you got a cup of coffee when you
> read this.
>
> > On an unrelated note I think if we do go down the route of having the
> > guest kernel punch the holes itself and such we should do so iff
> > XENMEM_memory_map returns either ENOSYS or nr_entries == 1 to leave open
>
> When would that actually happen? Is that return value returned when the
> hypervisor is not implementing it (what version was that implemented this)?
-ENOSYS implies an older Xen which does not have this interface.
Currently this causes the guest to create a fake one-entry e820 covering
0..nr_pages, which is what old guests which don't know about the
hypercall do too.
If the hypercall returns an e820 with nr_entries == 1 then this implies
a newer Xen which implements the interface but where the tools have only
poked down a simple one-entry e820 covering 0..nr_pages or possibly
0..max_pages (this is all any existing hypervisor/tools will do).
If the hypervisor returns nr_entries >= 2 then you have some future Xen
which has tools which (think they) know what they are doing and so we
should trust the e820 given to us. Without allowing for this now we will
end up with XENFEAT_tools_provide_a_useful_guest_e820 which would be a
shame!
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home