[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 2014/10/29 17:08, Jan Beulich wrote:
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.

Right, so maybe before any mmio allocation, we can expand mmio resource to own sufficient space covering RMRR and all BARs.

Thanks
Tiejun


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®.