From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: (v2) Design proposal for RMRR fix Date: Mon, 12 Jan 2015 09:50:56 +0000 Message-ID: <54B3A71002000078000538E1@mail.emea.novell.com> References: <54AE9A2F0200007800052ACF@mail.emea.novell.com> <54AFAB90020000780005303C@mail.emea.novell.com> <54AFBCE502000078000530F3@mail.emea.novell.com> <54B3A2D602000078000538A2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kevin Tian Cc: "wei.liu2@citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" , "tim@xen.org" , "ian.jackson@eu.citrix.com" , "xen-devel@lists.xen.org" , Yang Z Zhang , Tiejun Chen List-Id: xen-devel@lists.xenproject.org >>> On 12.01.15 at 10:41, wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Monday, January 12, 2015 5:33 PM >> >>> On 12.01.15 at 09:46, wrote: >> >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >> Sent: Friday, January 09, 2015 6:35 PM >> >> >>> On 09.01.15 at 11:10, 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. :-) 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. Jan