This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News



To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH PV_OPS PCIFRONT]
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 06 Nov 2009 14:33:37 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 06 Nov 2009 14:33:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091106215035.GA22320@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1257456819-782-1-git-send-email-konrad.wilk@xxxxxxxxxx> <20091105220414.GA3820@xxxxxxxxxxxxxxxxxxx> <4AF497BE.1030806@xxxxxxxx> <20091106215035.GA22320@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
On 11/06/09 13:50, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 06, 2009 at 01:40:14PM -0800, Jeremy Fitzhardinge wrote:
>> On 11/05/09 14:04, Konrad Rzeszutek Wilk wrote:
>>>> That is it for right now. The driver works with INTx and MSI cards. I've 
>>>> tested
>>>> with USB and network (Broadcom) succesfully. There is still some more work 
>>>> to do:
>>>>  - MSI disable is not yet in,
>>>>  - no MSI-X enable/disable functionality.
>>> and:
>>>  - If 4GB or more are allocated to the domain, you get this:
>>> PCI: Warning: Cannot find a gap in the 32bit address range
>>> PCI: Unassigned devices with 32bit resource registers may break!
>>>    and the device shows up as disabled and is not usuable.
>> Presumably less than 4G can trigger this.  My rough thought about this
>> was to always reserve a chunk of memory under 4G to make space for this
>> kind of thing, and push the displaced memory higher.
> <nods> This would be done in the xc_build_domain_linux_something ?

I was thinking of doing it within the domain itself.  Fairly early, it
would clear out the range and modify the E820 table before handing it to
the rest of the kernel.  The code's actually already there, but it
hasn't really been exercised yet.  And it just releases the memory, but
doesn't relocate it.  You'd need to balloon it in again later.

>>> WARNING: at drivers/pci/msi.c:602 pci_enable_msi_block+0xcd/0x339()
>>> .. snip ..
>>> Call Trace:
>>>  [<ffffffff8107ed59>] warn_slowpath_common+0xc9/0x10c
>>>  [<ffffffff8107edcc>] warn_slowpath_null+0x30/0x4d
>>>  [<ffffffff81362cec>] pci_enable_msi_block+0xcd/0x339
>>>  [<ffffffff814006ec>] ? pciback_do_op+0x0/0x1b4
>>>  [<ffffffff8140469e>] pciback_enable_msi+0x3e/0xb0
>>>  [<ffffffff814007b9>] pciback_do_op+0xcd/0x1b4
>>> ..snip..
>> What does that warning mean?
> Something about slowpath. Didn't dive any deeper in this. I think it complains
> about the workqueue taking too long to do its job.

"slowpath" here just means the slow path of the warning code; ie, a
warning happened.  The warning itself appears to be:
in pci_enable_msi_block().


Xen-devel mailing list