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

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

> 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]
> >> Boot time device assignment is different: The question isn't whether
> >> an assigned device works, instead the proper analogy is whether a
> >> device is _present_. If a device doesn't work on bare metal, it will
> >> still be discoverable. Yet if device assignment fails, that's not going
> >> to be the case - for security reasons, the guest would not see any
> >> notion of the device.
> >
> > the question is whether we want such device assignment fail due to
> > RMRR confliction, and the fail decision should be when Xen handles
> > actual assignment instead of when domain builder prepares reserved
> > regions.
> 
> Detecting the failure only in the hypervisor has the downside of
> potentially leaving the user with little clues as to what went wrong.
> Sending messages to the hypervisor log in that case is
> questionable, yet the tool stack (namely libxc) is known to not
> always do a good job in error propagation.
> 
> >> 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.

Thanks
Kevin

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