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

Re: [Xen-devel] Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"

On Fri, 2 Aug 2013 08:06:00 -0400, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Fri, Aug 02, 2013 at 10:27:04AM +0100, Gordan Bobic wrote:
On Fri, 2 Aug 2013 11:07:35 +0200, Andrea Brugiolo
<andrea@xxxxxxxxxxxx> wrote:
>On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk
>>On Mon, Jul 29, 2013 at 10:02:03AM +0100, Ian Campbell wrote:
>>> On Fri, 2013-07-26 at 12:32 +0200, Andrea Brugiolo wrote:
>>> > Good Morning
>>> >
>>> > I cannot do pciback anymore for both my second scsi
>>controller and my
>>> > second network card: when I try to pass the device to the
>>domU I get
>>> > this error in system logs:
>>> >
>>> >   ... address space collision: [mem ...] conflicts with
>>System RAM [mem ...]
>>> By eliding the actually addresses you've omitted something
>>which I think
>>> might be interesting:
>>>         [mem 0xf9e00000-0xf9e1ffff 64bit] conflicts with
>>System RAM [mem 0x00100000-0x4007fffff]
>>> Note that there is not any actual overlap in those two sets of
>>I think it is:
>>mem 0xf9e00000-0xf9e1ffff
>>mem 0x00100000-0x4007fffff
>>The RAM region is pretty much all of the memory. This looks like
>>the 'e820_hole'
>>parameter is not being used? (It only works for xl btw).

Where is the e820_hole option documented and what does it do?

It should be in the manpage (man xl.cfg). Here is a copy-n-paste:
Selects whether to expose the host e820 (memory map) to the guest
        via the virtual e820. When this option is false (0) the guest
pseudo-physical address space consists of a single contiguous RAM region. When this option is specified the virtual e820 instead reflects the host e820 and contains the same PCI holes. The total amount of RAM represented by the memory map is always the same, this
        option configures only how it is laid out.

Exposing the host e820 to the guest gives the guest kernel the opportunity to set aside the required part of its pseudo-physical address space in order to provide address space to map passedthrough PCI devices. It is guest Operating System dependent whether this
        option is required, specifically it is required when using a
mainline Linux ("pvops") kernel. This option defaults to true (1) if any PCI passthrough devices are configured and false (0) otherwise. If you do not configure any passthrough devices at domain creation time but expect to hotplug devices later then you should set this option. Conversely if your particular guest kernel does not require this behaviour then it is safe to allow this to be enabled but you
        may wish to disable it anyway.

Ah, so this was a typo above. s/e820_hole/e820_host/

Thanks for clarifying.


Xen-devel mailing list



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