From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [v7][RFC][PATCH 06/13] hvmloader/ram: check if
 guest memory is out of reserved device memory maps
Date: Wed, 12 Nov 2014 09:02:23 +0000
Message-ID: <5463302F0200007800046AF8@mail.emea.novell.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<5457174C.8020400@intel.com>
	<5457515102000078000443B0@mail.emea.novell.com>
	<54574D8F.8060407@intel.com>
	<54575E2D0200007800044443@mail.emea.novell.com>
	<545767C4.7070806@intel.com>
	<5457787002000078000445C7@mail.emea.novell.com>
	<54576DF7.8060408@intel.com>
	<545784830200007800044627@mail.emea.novell.com>
	<54585EAA.20904@intel.com>
	<545894610200007800044A5B@mail.emea.novell.com>
	<545992A2.8070309@intel.com>
	<545A57AD02000078000C1037@mail.emea.novell.com>
	<545B3F4A.5070808@intel.com>
	<545B562F02000078000453FB@mail.emea.novell.com>
	<545C9E97.4040800@intel.com>
	<545CB64E02000078000459CD@mail.emea.novell.com>
	<5461AD94.2070008@intel.com> <5461BF97.1070709@intel.com>
	<5461DED50200007800046520@mail.emea.novell.com>
	<5461DFAF020000780004652B@mail.emea.novell.com>
	<5461DA23.6020105@intel.com>
	<5461EDD702000078000465C3@mail.emea.novell.com>
	<5462B9AC.6050704@intel.com>
	<54632A760200007800046ACC@mail.emea.novell.com>
	<54631E3A.2020909@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <54631E3A.2020909@intel.com>
Content-Disposition: inline
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tiejun Chen <tiejun.chen@intel.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org, xen-devel@lists.xen.org

>>> On 12.11.14 at 09:45, <tiejun.chen@intel.com> wrote:
>> > #2 flags field in each specific device of new domctl would control
>>> whether this device need to check/reserve its own RMRR range. But its
>>> not dependent on current device assignment domctl, so the user can use
>>> them to control which devices need to work as hotplug later, separately.
>>
>> And this could be left as a second step, in order for what needs to
>> be done now to not get more complicated that necessary.
>>
> 
> Do you mean currently we still rely on the device assignment domctl to 
> provide SBDF? So looks nothing should be changed in our policy.

I can't connect your question to what I said. What I tried to tell you
was that I don't currently see a need to make this overly complicated:
Having the option to punch holes for all devices and (by default)
dealing with just the devices assigned at boot may be sufficient as a
first step. Yet (repeating just to avoid any misunderstanding) that
makes things easier only if we decide to require device assignment to
happen before memory getting populated (since in that case there's
no need for a new domctl to communicate SBDFs, as devices needing
holes will be known to the hypervisor already).

Jan