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] [RFC Patch] Support for making an E820 PCI hole in tools

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


Xen-devel mailing list

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