On Tue, 11 Oct 2022 13:22:40 -0400
Gregory Price wrote:
> I'll push the patches to qemu-cxl and linux-cxl today or tomorrow, I
> wanted to get them into a state on gitlab for Jonathan to rebase and
> merge into his work. He'll likely end up pushing the entire series at
> the end of the day.
>
I'll push the patches to qemu-cxl and linux-cxl today or tomorrow, I
wanted to get them into a state on gitlab for Jonathan to rebase and
merge into his work. He'll likely end up pushing the entire series at
the end of the day.
Will update the tests/docs accordingly.
re: changelog - i'm new
On Mon, 10 Oct 2022, Gregory Price wrote:
I've pushed 5 new commits to this branch here (@Jonathan I've also made
a merge request to pull them into your branch).
https://gitlab.com/gourry.memverge/qemu/-/commits/cxl-2022-10-09
This series could perhaps be posted as a reply to the CDAT
I've pushed 5 new commits to this branch here (@Jonathan I've also made
a merge request to pull them into your branch).
https://gitlab.com/gourry.memverge/qemu/-/commits/cxl-2022-10-09
They're built on top of Jonathan's extensions for the CDAT since the
CDAT has memory region relevant entries
On Mon, 10 Oct 2022, Jonathan Cameron wrote:
I wonder if we care to emulate beyond 1 volatile and 1 persistent.
Sure devices might exist, but if we can exercise all the code paths
with a simpler configuration, perhaps we don't need to handle the
more complex ones?
Yes, I completely agree. 1
> > but i'm not sure of what to do with this info. We have some proof
> > that real hardware works with this no problem, and the only difference
> > is that the EFI/bios/firmware is setting the memory regions as `usable`
> > or `soft reserved`, which would imply the EDK2 is the blocker here
> >
On Mon, 10 Oct 2022 11:20:05 -0400
Gregory Price wrote:
> > >
> > > Maybe we should consider 2 new options:
> > > --persistent-memdevs=pm1 pm2 pm3
> > > --volatile-memdevs=vm1 vm2 vm3
> > >
> > > etc, and deprecate --memdev, and go with your array of memdevs idea.
> > >
> > > I think I could
>
> https://gitlab.com/jic23/qemu/-/commits/cxl-2022-10-09
> There are a few messy corners in that tree but it should work. I'll be
> pushing out a new version in a few days.
>
> I updated that in latest version to build the tables based on the
> memdev provided. We'll want to add the volatile
> >
> > Maybe we should consider 2 new options:
> > --persistent-memdevs=pm1 pm2 pm3
> > --volatile-memdevs=vm1 vm2 vm3
> >
> > etc, and deprecate --memdev, and go with your array of memdevs idea.
> >
> > I think I could probably whip that up in a day or two. Thoughts?
>
> I wonder if we care
On Fri, 7 Oct 2022 10:50:12 -0400
Gregory Price wrote:
> Now that i've had some time to look at the spec, the DVSEC CXL Capability
> register (8.1.3.1 in 3.0 spec)
> only supports enabling two HDM ranges at the moment, which to me means we
> should implement
>
> memdev0=..., memdev1=...
That
>
> I was unaware that an SLD could be comprised of multiple regions
> of both persistent and volatile memory. I was under the impression that
> it could only be one type of memory. Of course that makes sense in the
> case of a memory expander that simply lets you plug DIMMs in *facepalm*
>
On Fri, 07 Oct 2022, Gregory Price wrote:
Spec says that volatile devices `may` implement an lsa.
Right you are.
Get LSA (Opcode 4102h)
The Label Storage Area (LSA) shall be supported by a memory device
that provides persistent memory capacity and may be supported by a
device that provides
On Thu, 06 Oct 2022, Jonathan Cameron wrote:
One of the blockers for volatile support was that we had no means to poke
it properly as the kernel doesn't yet support volatile capacity and
no one has done the relevant work in EDK2 or similar to do it before the kernel
boots.
There has been some
On Fri, Oct 07, 2022 at 11:16:19AM -0700, Davidlohr Bueso wrote:
>
> Yeah, putting this back together was on my todo list, but happy to see
> patches are out. Recollecting my thoughts on this, my original approach
> was also to support only volatile or persistent capacities, but through
> two
On Thu, 06 Oct 2022, Jonathan Cameron wrote:
3) Upstream linux drivers haven't touched ram configurations yet. I
just configured this with Dan Williams yesterday on IRC. My
understanding is that it's been worked on but nothing has been
upstreamed, in part because there are only a very small
Now that i've had some time to look at the spec, the DVSEC CXL Capability
register (8.1.3.1 in 3.0 spec)
only supports enabling two HDM ranges at the moment, which to me means we
should implement
memdev0=..., memdev1=...
Yesterday I pushed a patch proposal that separated the regions into
On Thu, Oct 06, 2022 at 05:42:14PM +0100, Jonathan Cameron wrote:
> >
> > 1) The PCI device type is set prior to realize/attributes, and is
> > currently still set to PCI_CLASS_STORAGE_EXPRESS. Should this instead
> > be PCI_CLASS_MEMORY_CXL when presenting as a simple memory expander?
>
> We
On Thu, Oct 06, 2022 at 09:50:07AM +0100, Jonathan Cameron wrote:
> On Thu, 6 Oct 2022 09:45:57 +0100
> Jonathan Cameron wrote:
>
> > Great to see this.
> >
> > Missing Signed-off by so we can't apply this (no developer certificate of
> > origin) Probably want your from address to match that
On Thu, 6 Oct 2022 11:52:06 -0400
Gregory Price wrote:
> On Thu, Oct 06, 2022 at 09:50:07AM +0100, Jonathan Cameron wrote:
> > On Thu, 6 Oct 2022 09:45:57 +0100
> > Jonathan Cameron wrote:
> >
> > > Great to see this.
> > >
> > > Missing Signed-off by so we can't apply this (no developer
On Thu, 6 Oct 2022 09:45:57 +0100
Jonathan Cameron wrote:
> On Wed, 5 Oct 2022 20:01:03 -0400
> Gourry wrote:
>
> > Type 3 devices were hard-coded to always present as persistent memory
> > devices.
> > This patch adds the "is_pmem" attribute which can be used to instantiate
> > a device as
On Wed, 5 Oct 2022 20:01:03 -0400
Gourry wrote:
> Type 3 devices were hard-coded to always present as persistent memory devices.
> This patch adds the "is_pmem" attribute which can be used to instantiate
> a device as either a pmem or vmem.
Hi Gourry,
Great to see this.
Missing Signed-off by
Type 3 devices were hard-coded to always present as persistent memory devices.
This patch adds the "is_pmem" attribute which can be used to instantiate
a device as either a pmem or vmem.
Right now it is only possible to choose one or the other, but future
devices may present both (such as
22 matches
Mail list logo
