[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v7][RFC][PATCH 05/13] hvmloader/mmio: reconcile guest mmio with reserved device memory



>>> On 29.10.14 at 08:03, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/10/28 17:56, Jan Beulich wrote:
>>>>> On 28.10.14 at 08:11, <tiejun.chen@xxxxxxxxx> wrote:
>>> On 2014/10/27 17:56, Jan Beulich wrote:
>>>>>>> On 27.10.14 at 08:12, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> On 2014/10/24 22:42, Jan Beulich wrote:
>>>>>>>>> On 24.10.14 at 09:34, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> Additionally, actually there are some original codes just following my
>>>>> codes:
>>>>>
>>>>>            if ( need_skip_rmrr )
>>>>>            {
>>>>>           ...
>>>>>            }
>>>>>
>>>>>   base += bar_sz;
>>>>>
>>>>>            if ( (base < resource->base) || (base > resource->max) )
>>>>>            {
>>>>>                printf("pci dev %02x:%x bar %02x size "PRIllx": no space 
>>>>> for "
>>>>>                       "resource!\n", devfn>>3, devfn&7, bar_reg,
>>>>>                       PRIllx_arg(bar_sz));
>>>>>                continue;
>>>>>            }
>>>>>
>>>>> This can guarantee we don't overwhelm the previous mmio range.
>>>>
>>>> Resulting in the BAR not getting a value assigned afaict. Certainly
>>>> not what we want as a side effect of your changes.
>>>
>>> I don't understand what a side effect is. I just to try to make sure BAR
>>> space skip any conflict range but they are still in these resource ranges.
>>
>> A side effect is an effect you don't primarily intend with your change
>> (or more generally, with any particular operation). In the case here,
>> a BAR that previously got a value assigned may not anymore with
>> your change in place. An acceptable effect of your change would be
>> if the value it gets assigned is now different, but not assigning a value
>> at all is not acceptable.
> 
> As I understand that value just need to align with BAR and size. Then 
> any range should be fine. Here I think its not necessary to consider any 
> space restriction, i.e, some device may just access under 4G.

No. The code determining where to put the lower boundary of the
MMIO range doesn't (with your present patch) consider the regions
the actual assignment code now skips. Hence the lower boundary
may not be low enough to accommodate all BARs.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.