xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).