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

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2014/11/12 17:56, Jan Beulich wrote:
>>>> On 12.11.14 at 10:13, <tiejun.chen@intel.com> wrote:
>> On 2014/11/12 17:02, Jan Beulich wrote:
>>>>>> 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
>>
>> 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
>
>
>