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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.11.14 at 02:36, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/11/11 18:07, Jan Beulich wrote:
>>>>> On 11.11.14 at 10:42, <tiejun.chen@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel