Re: [PATCH for 4.5 v7 1/1] Add mmio_hole_size

[Don Slutz <dslutz@verizon.com>]

On 10/15/14 12:12, Wei Liu wrote:
> On Tue, Oct 14, 2014 at 11:56:22AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Oct 13, 2014 at 08:51:19AM -0400, Don Slutz wrote:
>>> If you add enough PCI devices then all mmio may not fit below 4G
>>> which may not be the layout the user wanted. This allows you to
>>> increase the below 4G address space that PCI devices can use and
>>> therefore in more cases not have any mmio that is above 4G.
>>>
>>> There are real PCI cards that do not support mmio over 4G, so if you
>>> want to emulate them precisely, you may also need to increase the
>>> space below 4G for them. There are drivers for these cards that also
>>> do not work if they have their mmio space mapped above 4G.
>>>
>>> This allows growing the MMIO hole to the size needed.
>>>
>>> This may help with using pci passthru and HVM.
>>>
>>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>>
>> Wei, Ian, Stefano, Ian,
>>
>> I am OK with this patch going in Xen 4.5 (as a release-manager)
>> but it can't go anywhere unless there is an Ack/Review.
>>
>> P.S.
>> Also added Wei to the CC list.
> I didn't follow this closely. ISTR there's disagreement on whether this
> is the correct approach to fix this bug. Have we reached consent that we
> should use this approach?

I was hoping that if someone did have a disagreement with this
approach, they would have responded to this e-mail.  As far as I
know the only disagreement is on bug #28:


  #28 - support PCI hole resize in qemu-xen

http://bugs.xenproject.org/xen/bug/28

since this approach is not supporting PCI hole resize in qemu-xen.

> From Jan Beulich:

>> From Don Slutz:
>> The support for changing mmio_hole_size is still "missing" from QEMU.
>> So this code only works for qemu-traditional.  I think Jan said
>> back on v1 or v2 (sorry, e-mail issues) that since this is a config,
>> disable the auto changing code.

> Because it didn't seem like you would want to properly take care
> of both cases together (iirc the fact that the configured hole size
> could be other than a power of 2 introduced a conflict with the
> current resizing logic). I.e. doing one or the other is a suitable
> first step imo, but with room for improvement.


So I am going with this 1st step and not claiming to fix bug #28.

    -Don Slutz


> Wei.