>>> On 12.11.14 at 02:36, <tiejun.c...@intel.com> wrote: > On 2014/11/11 18:07, Jan Beulich wrote: >>>>> On 11.11.14 at 10:42, <tiejun.c...@intel.com> wrote: >>> On 2014/11/11 17:06, Jan Beulich wrote: >>>> Part of which would involve re-considering whether device >>>> assignment shouldn't be done before memory population in the >>>> tool stack. >>> >>> Yes, after we introduce this new domctl, we just make sure this domctl >>> should be called before memory population no matter when we do assign a >>> device as passthrough. >> >> You didn't think through the implications then: If device assignment >> happens early enough, there's no need to report SBDF tuples via a > > In the present the device assignment is always after memory population. > And I also mentioned previously I double checked this sequence with printk.
And I didn't question that; instead I suggested to re-consider whether that should be changed. >> new domctl (or only if we want to still allow for post-boot assignment >> of affected devices without using the global enforcement flag, in >> which case assigning devices early at boot time is pointless). > > The global enforcement flag is mainly used to provide such an approach > the user know exactly he/she may need a hotplug later, we'd better check > to reserve all RMRR ranges in advance. > > So I guess you mean we need to separate this interface from our original > device assignment like this, > > #1 pci_force as a global variable would control whether we force to > check/reserve __all__ RMRR ranges. Yes. > #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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
