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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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