>>> On 08.01.15 at 16:59, <dunl...@umich.edu> wrote: > On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich <jbeul...@suse.com> wrote: >>> the 1st invocation of this interface will save all reported reserved >>> regions under domain structure, and later invocation (e.g. from >>> hvmloader) gets saved content. >> >> Why would the reserved regions need attaching to the domain >> structure? The combination of (to be) assigned devices and >> global RMRR list always allow reproducing the intended set of >> regions without any extra storage. > > So when you say "(to be) assigned devices", you mean any device which > is currently assigned, *or may be assigned at some point in the > future*?
Yes. > Do you think the extra storage for "this VM might possibly be assigned > this device at some point" wouldn't really be that much bigger than > "this VM might possibly map this RMRR at some point in the future"? Since listing devices without RMRR association would be pointless, I think a list of devices would require less storage. But see below. > It seems a lot cleaner to me to have the toolstack tell Xen what > ranges are reserved for RMRR per VM, and then have Xen check again > when assigning a device to make sure that the RMRRs have already been > reserved. With an extra level of what can be got wrong by the admin. However, I now realize that doing it this way would allow specifying regions not associated with any device on the host the guest boots on, but associated with one on a host the guest may later migrate to. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
