Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, November 12, 2014 5:57 PM
> 
> >>> On 12.11.14 at 10:13, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2014/11/12 17:02, Jan Beulich wrote:
> >>>>> On 12.11.14 at 09:45, <tiejun.chen@xxxxxxxxx> 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
> be changed. Please also consult with the VT-d maintainers (hint to
> them: participating in this discussion publicly would be really nice)
> on _all_ decisions to be made here.
> 

there's no decision made privately. we hope all the discussions publicly.
will get back w/ our thoughts soon.

Thanks
Kevin

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