From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" 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 18:18:29 +0800 Message-ID: <546333F5.6060307@intel.com> References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.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> <5463302F0200007800046AF8@mail.emea.novell.com> <546324AC.1010306@intel.com> <54633CF90200007800046B44@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: <54633CF90200007800046B44@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@intel.com, yang.z.zhang@intel.com Cc: tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 2014/11/12 17:56, Jan Beulich wrote: >>>> On 12.11.14 at 10:13, wrote: >> On 2014/11/12 17:02, Jan Beulich wrote: >>>>>> On 12.11.14 at 09:45, 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 >> >> Something is misunderstanding to me. >> >>> 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 >> >> Here what do you mean, 'if we decide to require device assignment to >> happen before memory getting populated'? >> >> Because -quote- >> " >> In the present the device assignment is always after memory population. >> And I also mentioned previously I double checked this sequence with printk. >> " >> >> Or you already plan or deciede to change this sequence? > > So it is now the 3rd time that I'm telling you that part of your > decision making as to which route to follow should be to > re-consider whether the current sequence of operations shouldn't As I said previously it may corrupt some existing frameworks to move device assignment codes. Anyway, who can determine formally this approach? Let me ping actively them. > be changed. Please also consult with the VT-d maintainers (hint to Especially, Yang and Kevin are always included in this thread. > them: participating in this discussion publicly would be really nice) Also in public. Thanks Tiejun > on _all_ decisions to be made here. > > Jan > > >