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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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