Re: [Xen-devel] (v2) Design proposal for RMRR fix

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Monday, January 12, 2015 5:51 PM
> 
> >>> On 12.01.15 at 10:41, <kevin.tian@xxxxxxxxx> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Monday, January 12, 2015 5:33 PM
> >> >>> On 12.01.15 at 09:46, <kevin.tian@xxxxxxxxx> wrote:
> >> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> Sent: Friday, January 09, 2015 6:35 PM
> >> >> >>> On 09.01.15 at 11:10, <kevin.tian@xxxxxxxxx> wrote:
> >> >> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> >> 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. :-)
> 
> The fact that ranges can't be removed from a guest's memory map
> is irrelevant - there's simply no question that this is that way. The
> main counter argument against report-all remains: It may result in
> unnecessarily little low memory in guests not needing all of the host
> regions to be reserved for them.
> 

the result is related to another open whether we want to block guest
boot for such problem. If 'warn' in domain builder is acceptable, we
don't need to change lowmem for such rare 1GB case, just throws
a warning for unnecessary conflictions (doesn't hurt if user doesn't
assign it). 

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel