All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Sergio Lopez <slp@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Shannon Zhao <shannon.zhaosl@gmail.com>,
	qemu-arm@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v3 14/22] microvm: use 2G split unconditionally
Date: Wed, 27 May 2020 14:25:45 +0200	[thread overview]
Message-ID: <20200527142545.32e91049@redhat.com> (raw)
In-Reply-To: <20200526044839.bncj6iltugnzgfmy@sirius.home.kraxel.org>

On Tue, 26 May 2020 06:48:39 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> > > Well, I think we can (should) drop max-ram-below-4g too.  There is
> > > no reason to use that with microvm, other that shooting yourself into
> > > the foot (by making mmio overlap with ram).
> > > 
> > > With that being gone too there isn't much logic left ...  
> > 
> > I wonder if we need 2G split for microvm at all?
> > Can we map 1 contiguous big blob from 0 GPA and overlay bios & other x86 TOLUD stuff?  
> 
> I think it would work, but it has some drawbacks:
> 
>   (1) we loose a bit of memory.
          it's probably not a big enough to care about, we do similar ovarlay mapping on pc/q35
          at the beginning of RAM
>   (2) we loose a gigabyte page.
          I'm not sure waht exactly we loose in this case.
          Lets assume we allocating guest 5G of continuous RAM using 1G huge pages,
          in this case I'd think that on host side MMIO overlay won't affect RAM blob
          on guest side pagetables will be fragmented due to MMIO holes, but guest still
          could use huge pages smaller ones in fragmented area and 1G where there is no fragmentation.

>   (3) we wouldn't have guard pages (unused address space) between
>       between ram and mmio space.
           if it's holes' mmio,then do we really need them (access is going to be terminated
           either in always valid RAM or in valid mmio hole)?
> 
> take care,
>   Gerd
> 
> 



  reply	other threads:[~2020-05-27 12:26 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 13:19 [PATCH v3 00/22] microvm: add acpi support Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 01/22] microvm: name qboot binary qboot.bin Gerd Hoffmann
2020-05-20 13:25   ` Philippe Mathieu-Daudé
2020-05-25 11:02     ` Gerd Hoffmann
2020-05-25 12:26       ` Philippe Mathieu-Daudé
2020-05-20 13:19 ` [PATCH v3 02/22] [testing] seabios: update submodule to master snapshot Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 03/22] [testing] seabios: update config & build rules Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 04/22] [testing] seabios: update binaries to master snapshot Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 05/22] acpi: make build_madt() more generic Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 06/22] acpi: create acpi-common.c and move madt code Gerd Hoffmann
2020-05-20 13:31   ` Philippe Mathieu-Daudé
2020-05-20 13:19 ` [PATCH v3 07/22] acpi: madt: skip pci override on pci-less systems Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 08/22] acpi: fadt: add hw-reduced sleep register support Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 09/22] acpi: ged: rename event memory region Gerd Hoffmann
2020-05-20 13:33   ` Philippe Mathieu-Daudé
2020-05-21  7:58   ` Igor Mammedow
2020-05-20 13:19 ` [PATCH v3 10/22] acpi: ged: add control regs Gerd Hoffmann
2020-05-21  8:58   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 11/22] acpi: ged: add x86 device variant Gerd Hoffmann
2020-05-21  9:01   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 12/22] acpi: move acpi_dsdt_add_power_button() to ged Gerd Hoffmann
2020-05-20 13:32   ` Philippe Mathieu-Daudé
2020-05-21  9:03   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 13/22] x86: coldplug cpus Gerd Hoffmann
2020-05-20 14:07   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 14/22] microvm: use 2G split unconditionally Gerd Hoffmann
2020-05-20 13:34   ` Philippe Mathieu-Daudé
2020-05-21  9:14   ` Igor Mammedov
2020-05-21  9:29   ` Igor Mammedov
2020-05-25 11:45     ` Gerd Hoffmann
2020-05-25 16:36       ` Igor Mammedov
2020-05-26  4:48         ` Gerd Hoffmann
2020-05-27 12:25           ` Igor Mammedov [this message]
2020-05-27 13:06             ` Paolo Bonzini
2020-05-27 14:26               ` Igor Mammedov
2020-05-27 14:35                 ` Igor Mammedov
2020-05-27 14:54                 ` Paolo Bonzini
2020-05-28  7:19               ` Gerd Hoffmann
2020-05-28  7:17             ` Gerd Hoffmann
2020-05-20 13:19 ` [PATCH v3 15/22] microvm: make virtio irq base runtime configurable Gerd Hoffmann
2020-05-20 13:29   ` Philippe Mathieu-Daudé
2020-05-25 11:49     ` Gerd Hoffmann
2020-05-25 12:27       ` Philippe Mathieu-Daudé
2020-05-20 13:19 ` [PATCH v3 16/22] microvm/acpi: add minimal acpi support Gerd Hoffmann
2020-05-21 10:09   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 17/22] microvm/acpi: add acpi_dsdt_add_virtio() for x86 Gerd Hoffmann
2020-05-21 10:12   ` Igor Mammedov
2020-05-20 13:19 ` [PATCH v3 18/22] microvm/acpi: use GSI 16-23 for virtio Gerd Hoffmann
2020-05-21 10:13   ` Igor Mammedov
2020-05-20 13:20 ` [PATCH v3 19/22] microvm/acpi: use seabios with acpi=on Gerd Hoffmann
2020-05-21 10:14   ` Igor Mammedov
2020-05-20 13:20 ` [PATCH v3 20/22] microvm/acpi: disable virtio-mmio cmdline hack Gerd Hoffmann
2020-05-20 13:20 ` [PATCH v3 21/22] [RfC] acpi: add per machine type acpi default Gerd Hoffmann
2020-05-21 10:26   ` Igor Mammedov
2020-05-20 13:20 ` [PATCH v3 22/22] [RfC] acpi: flip default to off for microvm Gerd Hoffmann
2020-05-21 10:36   ` Igor Mammedov
2020-05-25 12:11     ` Gerd Hoffmann
2020-05-20 15:46 ` [PATCH v3 00/22] microvm: add acpi support no-reply
2020-05-20 15:50 ` no-reply
2020-05-20 15:51 ` no-reply
2020-05-20 15:53 ` no-reply

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=20200527142545.32e91049@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=shannon.zhaosl@gmail.com \
    --cc=slp@redhat.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.