All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: George Dunlap <dunlapg@umich.edu>, Don Slutz <dslutz@verizon.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [RFC PATCH 1/1] Add pci_hole_min_size
Date: Tue, 04 Mar 2014 13:57:26 -0500	[thread overview]
Message-ID: <53162216.8070607@terremark.com> (raw)
In-Reply-To: <CAFLBxZZSt-eMdDRGkKp=UN2rTH0+7HHBLOpXiK+LMATBp++=-g@mail.gmail.com>

On 03/04/14 08:25, George Dunlap wrote:
> On Fri, Feb 28, 2014 at 8:15 PM, Don Slutz <dslutz@verizon.com> wrote:
>> This allows growing the pci_hole to the size needed.
> You mean, it allows the pci hole size to be specified at boot

Yes.

>   -- the
> pci hole still cannot be enlarged dynamically in hvmloader, correct?

If I am correctly understanding you, this is in reference to:

/*
      * At the moment qemu-xen can't deal with relocated memory regions.
      * It's too close to the release to make a proper fix; for now,
      * only allow the MMIO hole to grow large enough to move guest memory
      * if we're running qemu-traditional.  Items that don't fit will be
      * relocated into the 64-bit address space.   */


so the answer is no, however using pci_hole_min_size can mean that allow_memory_relocate is not needed for upstream QEMU.



> What's your intended use case for this?
>
>   -George

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.

    -Don Slutz

  reply	other threads:[~2014-03-04 18:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 20:15 [RFC PATCH 0/1] Add pci_hole_min_size Don Slutz
2014-02-28 20:15 ` [RFC PATCH 1/1] " Don Slutz
2014-02-28 22:07   ` Boris Ostrovsky
2014-03-03 15:30     ` Don Slutz
2014-03-03 16:07       ` Boris Ostrovsky
2014-03-03 20:43         ` Don Slutz
2014-03-03 22:54           ` Boris Ostrovsky
2014-03-04 13:25   ` George Dunlap
2014-03-04 18:57     ` Don Slutz [this message]
2014-03-07 19:28       ` Konrad Rzeszutek Wilk
2014-03-11 12:54         ` George Dunlap
2014-03-11 17:16           ` Don Slutz
  -- strict thread matches above, loose matches on Subject: below --
2014-03-11 17:01 [RFC PATCH 0/1] " Don Slutz
2014-03-11 17:01 ` [RFC PATCH 1/1] " Don Slutz

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=53162216.8070607@terremark.com \
    --to=dslutz@verizon.com \
    --cc=dunlapg@umich.edu \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --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.