All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey G <x1917x@gmail.com>
To: "Zhang, Xiong Y" <xiong.y.zhang@intel.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Bug]  Intel RMRR support with upstream Qemu
Date: Tue, 25 Jul 2017 02:24:41 +1000	[thread overview]
Message-ID: <20170725022441.00004e55@gmail.com> (raw)
In-Reply-To: <8082FF9BCB2B054996454E47167FF4EC1C56BA5F@SHSMSX104.ccr.corp.intel.com>

Hi,

On Mon, 24 Jul 2017 08:07:02 +0000
"Zhang, Xiong Y" <xiong.y.zhang@intel.com> wrote:

> [Zhang, Xiong Y] Thanks for your suggestion.
> Indeed, if I set mmi_hole >= 4G - RMRR_Base, this could fix my issue.
> For this I still have two questions, could you help me ?
> 1) If hvmloader do low memory relocation, hvmloader and qemu will see a
> different guest memory layout . So qemu ram maybe overlop with mmio, does
> xen have plan to fix this ?
> 
> 2) Just now, I did an experiment: In hvmloader, I set
> HVM_BELOW_4G_RAM_END to 3G and reserve one area for qemu_ram_allocate
> like 0xF0000000 ~ 0xFC000000; In Qemu, I modified xen_ram_alloc() to make
> sure it only allocate gfn in 0xF0000000 ~ 0xFC000000. In this case
> qemu_ram won't overlap with mmio, but this workaround couldn't fix my
> issue. It seems qemu still has another interface to allocate gfn except
> xen_ram_alloc(), do you know this interface ?

Please share your 'xl dmesg' output, to have a look at your guest's MMIO
map and which RMRRs and PCI MBARs are present there.

If RMRR range happens to overlap some guest's RAM below pci_start
(dictated by lack of relocation support and low_mem_pgend value), I think
your problem might be solved by sacrificing some part of guest RAM which is
overlapped by RMRR -- by changing the E820 map in hvmloader.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-07-24 16:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 10:57 [Bug] Intel RMRR support with upstream Qemu Zhang, Xiong Y
2017-07-21 13:28 ` Alexey G
2017-07-21 13:56   ` Alexey G
2017-07-24  8:07     ` Zhang, Xiong Y
2017-07-24  9:53       ` Igor Druzhinin
2017-07-24 10:49         ` Zhang, Xiong Y
2017-07-24 16:42         ` Alexey G
2017-07-24 17:01           ` Andrew Cooper
2017-07-24 18:34             ` Alexey G
2017-07-24 20:39           ` Igor Druzhinin
2017-07-25  7:03             ` Zhang, Xiong Y
2017-07-25 14:13               ` Igor Druzhinin
2017-07-25 16:49                 ` Alexey G
2017-07-25 16:40             ` Alexey G
2017-07-25 17:04               ` Igor Druzhinin
2017-07-25 17:47               ` Andrew Cooper
2017-07-24 16:24       ` Alexey G [this message]
2017-07-25  2:52         ` Zhang, Xiong Y

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=20170725022441.00004e55@gmail.com \
    --to=x1917x@gmail.com \
    --cc=xen-devel@lists.xen.org \
    --cc=xiong.y.zhang@intel.com \
    /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.