All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
Cc: "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>
Subject: Re: DCD region base address
Date: Mon, 24 Jul 2023 10:03:42 +0100	[thread overview]
Message-ID: <20230724100342.00005c7b@Huawei.com> (raw)
In-Reply-To: <DM6PR18MB2844A8A869CFB8932782DD67AF3EA@DM6PR18MB2844.namprd18.prod.outlook.com>

On Thu, 20 Jul 2023 01:43:34 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Hello All,
> 
> I am adding FM-API support to add DCD extents in QEMU. The current code is not making sense to me.  According to CXL3.0 spec (Table 8-126), region_base should be the DPA and not the size, decode_length is the total region length which is used to program HDM decoders, region_len is the usable length meaning as extents are added the region_len increases up to a max of decode_length. So should be 0 before we add any extents. 
> 
> This is what it should look like in my opinion. Am I correct ?
> 
> --- hw/mem/cxl_type3_old.c    2023-07-19 18:18:54.211748475 -0700
> +++ hw/mem/cxl_type3.c  2023-07-19 18:27:13.468602825 -0700
> @@ -747,10 +747,10 @@
>  static int cxl_create_toy_regions(CXLType3Dev *ct3d)
>  {
>       int i;
> -     uint64_t region_base = ct3d->hostvmem?ct3d->hostvmem->size
> -           :ct3d->hostpmem->size;
> -     uint64_t region_len = 1024*1024*1024;
> -     uint64_t decode_len = 4; /* 4*256MB */
> +    MemoryRegion *mr = host_memory_backend_get_memory(ct3d->dc.host_dc);
> +    uint64_t region_base = (uint64_t)memory_region_get_ram_ptr(mr);
> +     uint64_t region_len = 0;
> +     uint64_t decode_len = ct3d->dc.host_dc->size / ct3d->dc.num_regions / (256*1024*1024);
>       uint64_t blk_size = 2*1024*1024;
>       struct CXLDCD_Region *region;

What code are we looking at here?

Anyhow, the DPA here is relative to the device which isn't connected to the QEMU implementation
at all.  The address decoder stuff in QEMU will map to the right region wherever it is, we
just need to pretend the go:

[RAM region] [PMem Region] [DC Region]
where any of these are optional and where the Qemu emulation doesn't currently support
sizes that require any padding.

So the offsets above look wrong anyway as it seems to be assuming we either have
volatile or persistent regions but not both.

Jonathan

  reply	other threads:[~2023-07-24  9:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20  1:43 DCD region base address Shesha Bhushan Sreenivasamurthy
2023-07-24  9:03 ` Jonathan Cameron [this message]
2023-07-24 17:10   ` Fan Ni

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=20230724100342.00005c7b@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=sheshas@marvell.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.