>>> On 15.11.16 at 12:07, <jgr...@suse.com> wrote: > On 15/11/16 11:44, Jan Beulich wrote: >>>>> On 15.11.16 at 10:55, <jgr...@suse.com> wrote: >>> On 15/11/16 10:45, Jan Beulich wrote: >>>>>>> On 15.11.16 at 09:42, <jgr...@suse.com> wrote: >>>>> For a fully dynamical solution we'd need a way to get a partial >>>>> E820 map from the hypervisor (e.g. first 128 entries) in order to >>>>> be able to setup at least some memory and later get the rest of >>>>> the memory map using some dynamically allocated memory. >>>> >>>> And we could of course also make the hypercall allow for that (e.g. >>>> by defining the semantics of a specific error code, so far not used >>>> by it, to avoid mis-interpretation of output on older hypervisors), >>>> or introduce a new clone of the existing one(s). >>> >>> I'd go with the new error code. What about E2BIG or ENOSPC? >> >> Either seems fine. >> >>> I think the hypervisor should fill in the number of entries required >>> in this case. >> >> And you'd then mean the caller to imply that the passed in (and now >> overwritten) count to describe how many entries got filled? That's >> not that nice an interface. I'd rather return the number of entries >> filled, and require the sizing variant (NULL handle) to be used to >> obtain the number of entries. After all if a caller _wants_ to handle >> a partial map, it doesn't really care how many further entries there >> are. > > I just wanted to avoid two interface changes.
Just make one at a time. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
