Re: (v2) Design proposal for RMRR fix

["Tian, Kevin" <kevin.tian@intel.com>]

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, January 12, 2015 5:33 PM
> 
> >>> On 12.01.15 at 09:46, <kevin.tian@intel.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Friday, January 09, 2015 6:35 PM
> >> >>> On 09.01.15 at 11:10, <kevin.tian@intel.com> wrote:
> >> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> The question isn't about migrating with devices assigned, but about
> >> >> assigning devices after migration (consider a dual vif + SR-IOV NIC
> >> >> guest setup where the SR-IOV NIC gets hot-removed before
> >> >> migration and a new one hot-plugged afterwards).
> >> >>
> >> >> Furthermore any tying of the guest memory layout to the host's
> >> >> where the guest first boots is awkward, as post-migration there's
> >> >> not going to be any reliable correlation between the guest layout
> >> >> and the new host's.
> >> >
> >> > how can you solve this? like above example, a NIC on node-A leaves
> >> > a reserved region in guest e820. now it's hot-removed and then
> >> > migrated to node-b. there's no way to update e820 again since it's
> >> > only boot structure. then user will still see such awkward regions.
> >> > since it's not avoidable, report-all in the summary mail looks not
> >> > causing a new problem.
> >>
> >> The solution to this are reserved regions specified in the guest config,
> >> independent of host characteristics.
> >
> > I don't think how reserved regions are specified matter here. My point
> > is that when a region is reserved in e820 at boot time, there's no way
> > to erase that knowledge in the guest even when devices causing that
> > reservation are hot removed later.
> 
> I don't think anyone ever indicated that such erasure would be
> needed/wanted - I'm not sure how you ended up there.
> 

I ended here to indicate that report-all which gives user more reserved
regions than necessary is not a weird case since above scenario can also
create such fact. User shouldn't set expectation about reserved region
layout. and this argument is necessary to support our proposal of using
report-all. :-)

Thanks
Kevin