From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Gordan Bobic <gordan@bobich.net>
Cc: Xen Developers <xen-devel@lists.xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
Andrea Brugiolo <andrea@cab.unipd.it>
Subject: Re: Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]"
Date: Fri, 2 Aug 2013 08:06:00 -0400 [thread overview]
Message-ID: <20130802120559.GG24540@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <4078b6f7c87fda2adaa7b11f7d10ab6c@mail.shatteredsilicon.net>
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@cab.unipd.it> wrote:
> >On Mon, Jul 29, 2013 at 01:55:16PM -0400, Konrad Rzeszutek Wilk
> >wrote:
> >>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
> >>addresses...
> >>
> >>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:
e820_host=BOOLEAN
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.
>
> Gordan
next prev parent reply other threads:[~2013-08-02 12:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 10:32 Xen pciback not working: "address space collision: [mem ...] conflicts with System RAM [mem ...]" Andrea Brugiolo
2013-07-29 9:02 ` Ian Campbell
2013-07-29 16:01 ` Andrea Brugiolo
2013-07-29 17:55 ` Konrad Rzeszutek Wilk
2013-07-30 9:11 ` Ian Campbell
2013-08-02 9:07 ` Andrea Brugiolo
2013-08-02 9:27 ` Gordan Bobic
2013-08-02 12:06 ` Konrad Rzeszutek Wilk [this message]
2013-08-02 12:19 ` Gordan Bobic
2013-08-02 12:44 ` Konrad Rzeszutek Wilk
2013-08-02 12:04 ` Konrad Rzeszutek Wilk
2013-08-02 12:30 ` Andrea Brugiolo
2013-08-02 12:43 ` Konrad Rzeszutek Wilk
2013-08-20 14:56 ` Andrea Brugiolo
2013-08-23 18:54 ` Konrad Rzeszutek Wilk
2013-08-27 21:03 ` Andrea Brugiolo
2013-08-28 15:45 ` Konrad Rzeszutek Wilk
2013-08-28 16:44 ` Andrea Brugiolo
2013-08-30 16:08 ` Konrad Rzeszutek Wilk
2013-09-04 17:22 ` Andrea Brugiolo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130802120559.GG24540@konrad-lan.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=andrea@cab.unipd.it \
--cc=gordan@bobich.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.