From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v6][PATCH 0/7] xen: reserve RMRR to avoid conflicting MMIO/RAM Date: Thu, 11 Sep 2014 17:39:15 +0800 Message-ID: <54116DC3.9020506@intel.com> References: <1410328190-6372-1-git-send-email-tiejun.chen@intel.com> <5410FD10.1020603@intel.com> <54116FDA0200007800033AEC@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54116FDA0200007800033AEC@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Kevin Tian Cc: Yang Z Zhang , "xen-devel@lists.xen.org" , "ian.jackson@eu.citrix.com" , "ian.campbell@citrix.com" , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On 2014/9/11 15:48, Jan Beulich wrote: >>>> On 11.09.14 at 03:38, wrote: >> On 2014/9/11 5:44, Tian, Kevin wrote: >>>> From: Chen, Tiejun >>>> Sent: Tuesday, September 09, 2014 10:50 PM >>>> >>> >>> currently the confliction is detected absolutely. Do we need a way to allow >>> the confliction if there is no device assigned at all? >> >> How to handle a hot-plug case when guest already boot? I think it may >> not be worth distinguishing such fine gain, things will be becoming >> complicated. > > In that case hotplug should fail. I'm very much in agreement with > Kevin that an override should be possible if there's any risk of the > detection done now could cause problems on certain systems (as > pointed out before, I'm mainly concerned about RMRRs being > defined in regions that overlap where the guest's BIOS wants to > be placed). > Looks I have to refactor most codes again :) I just take a quick look at Xen codes to try figuring out this possible way. As I see, either we do assign a device when create VM, or we do attach a device to a running VM, eventually we always call libxl__device_pci_add() to finish this operation. Furthermore, xc_test_assign_device() call such a hypercall, XEN_DOMCTL_test_assign_device. Right? If yes, I guess I can do check if RMRR is overlapping something in two cases: #1: In case of creating a VM, we may use global flag to make sure our original codes work indeed. It should be easy and especially I guess we can't check any conflict directly here since those memory info, RAM/MMIO/others, don't be filled completely, right? #2: In case of a running VM, we can check if any overlapping exist then determine what's next. Often we should drop to attach such a conflicting device. I'm not sure if I understand this path in Xen, so if I'm wrong please correct me. Thanks Tiejun