All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Ben Widawsky" <ben.widawsky@intel.com>,
	linuxarm@huawei.com, shameerali.kolothum.thodi@huawei.com
Subject: RFC: x86 memory map, where to put CXL ranges?
Date: Fri, 3 Dec 2021 17:57:34 +0000	[thread overview]
Message-ID: <20211203175734.00002212@Huawei.com> (raw)

Hi All,

For CXL emulation we require a couple of types of memory range that
are then provided to the OS via the CEDT ACPI table.

1) CXL Host Bridge Structures point to CXL Host Bridge Component Registers.
Small regions for each CXL Host bridge that are mapped into the memory space.
64k each.  In theory we may have a huge number of these but in reality I
think 16 will do for any reasonable system.

2) CXL Fixed Memory Window Structures (CFMWS)
Large PA space ranges (multiple TB) to which various CXL devices can be assigned
and their address decoders appropriately programmed.
Each such CFMWS will have particular characteristics such as interleaving across
multiple host bridges.  The can potentially be huge but are a system
characteristic.  For emulation purposes it won't matter if they move around
dependent on what else is the machine has configured. So I'd like to
just configure their size rather than fully specify them at the command line
and possibly clash on PA space with something else.  Alternatively could
leave them as fully specified at the command line (address and size) and just
error out if the hit memory already in use for something else.

Now unfortunately there are no systems out there yet that we can just
copy the memory map from...

Coming form an Arm background I have only a vague idea of how this should be
done for x86 so apologies if it is a stupid question.

My current approach is to put these above device_memory and moving
the pci hole up appropriately.

Is that the right choice?

On Arm I currently have the Host Bridge Structures low down in the MemMap and the CFMWS
can go above the device memory.  Comments on that also welcome.

In Ben's RFC the host bridge component register location was marked as a TODO
and a arbitrary address used in the meantime so time to figure out how to clean
that up.

Thanks,

Jonathan




             reply	other threads:[~2021-12-03 17:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03 17:57 Jonathan Cameron via [this message]
2021-12-09 14:19 ` RFC: x86 memory map, where to put CXL ranges? Alex Bennée
2021-12-09 15:47   ` Jonathan Cameron via

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=20211203175734.00002212@Huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=alex.bennee@linaro.org \
    --cc=ben.widawsky@intel.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=linuxarm@huawei.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=richard.henderson@linaro.org \
    --cc=shameerali.kolothum.thodi@huawei.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.