Re: [PATCH v8 04/46] hw/cxl/device: Introduce a CXL device (8.2.8)

[Jonathan Cameron <Jonathan.Cameron@huawei.com>]

...

> > > > > 
> > > > > Can we switch this to mem_size and drop the persistent comment? It is my 
> > > > > understanding that HDM is independent of persistence.    
> > > > 
> > > > Discussed in the other branch of this thread.  Short answer is we don't
> > > > support non persistent yet but it's on the todo list.  What exactly
> > > > that looks like is to be determined.  One aspect of that is there
> > > > isn't currently a software stack to test volatile memory.    
> > > 
> > > If you can elaborate more here on what is needed to test the volatile memory 
> > > stack we may be able to help out.  
> > 
> > There are a bunch of different ways this could be done - ultimate we probably
> > want to do all of them.
> > 
> > https://urldefense.com/v3/__https://cdrdv2.intel.com/v1/dl/getContent/643805?wapkw=CXL*20memory*20device*20sw*20guide__;JSUlJQ!!EwVzqGoTKBqv-0DWAJBm!HzD_Dh_I9m9MydppOSSyhuzvwTawlg7LE77bEYiZ1i3AMgxV_YOI56VeZgkg-KuX7XMA$ 
> > has some suggestions (though no one is obliged to follow them!) See 2.4
> > 
> > First assumption is that for volatile devices, a common approach will be to do
> > all the setup in firmware before the OS boots and just present normal SRAT, HMAT
> > and memory tables as if it were any other memory.  If we want to go that way
> > for testing purposes then we'd need an open source firmware to implement
> > setup similar to that done in Linux - probably EDK2.
> > 
> > Of course, volatile memory might be hot added, in which case the OS may be involved.
> > In that case I think the main missing part would be actually doing the final memory
> > hotplug event to expose it to the OS + the necessary dynamic updating of the
> > OS numa description etc. There is work on going to get the information needed
> > but I think we are still some way off actually tying everything together.
> > 
> > Dan / Ben and team may be able to share more status information.  
> 
> Great, thanks for all of the information. We will start planning out our next
> steps. I'll add Luis on cc since he has chatted with me about setting up a 
> test framework for the CXL kernel code that will rely on QEMU.
> 
> >   
> > >   
> > > >     
> > > > >     
> > > > > > +} CXLDeviceState;
> > > > > > +
> > > > > > +/* Initialize the register block for a device */
> > > > > > +void cxl_device_register_block_init(Object *obj, CXLDeviceState *dev);  
> > 
> > ...
> >   
> > > > > +cc Dave, Klaus, Tong
> > > > > Other than the minor issues raised.
> > > > > 
> > > > > Looks good.
> > > > > 
> > > > > Reviewed by: Adam Manzanares <a.manzanares@samsung.com>    
> > > > 
> > > > Btw I haven't accepted all changes, but have been picking up
> > > > your RB.  Shout if that's not fine with you.    
> > > 
> > > Definitely fine with me and was my intention. Let us know how we can help move
> > > the work forward. I am kick starting reviewing and will try to bring others in.  
> > 
> > Great.  For various reasons I'll not bother mention here (see my employer ;)
> > I need to keep any discussions on mailing list or in a 'published' form.
> > So discussion on mailing list + at conferences works best for me but we can
> > organize some suitably hosted public calls if needed to align plans.
> > There is a plan for uconf at Plumbers this year which will hopefully let  
> 
> We would also prefer to keep discussions in the public domain. We have plans to
> attend Plumbers this year, so we look forward to discussing in person. 

Excellent.  If it's useful to have a public discussion before plumbers then the nice
folk at Linaro have been kind enough to host similar discussion in the
past (and deal with posting recordings etc afterwards for those who missed
the live call) and I expect they'd help us out again (Hi Alex ;)

> 
> > us do any longer term planning.  Shorter term my aims around QEMU side of things
> > are:
> > 
> > 1) Get the initial support upstream as I'm getting bored of rebasing :)
> >    I think we are in a fairly good state for doing that once qemu 7.0 is
> >    out.
> > 2) Improved tests so it doesn't break when no one is paying attention.  
> 
> Luis may have some thoughts here. 

Excellent. A testing expert is always useful. It would be nice to think about
getting something beyond a basic 'does it boot' test into the qemu CI but
I've not really looked into how one might do that.

> 
> > 3) Expand out the feature set to keep up with what is going on Linux kernel
> >    wise (personally no other OS of interest, but it would be great if anyone
> >    wanted to help deal with other operating systems that care).
> >   * RAS
> >   * CDAT for switches etc, host table updates for generic port definition
> >    - What ever else I've missed recently.  When the region code finalizes
> >      I suspect we'll want to add a load more tests to stress various corners
> >      of that.
> >   * Alison may help with partitioning support.
> > 4) Expand features where we have currently taken a short cut such as enabling
> >    multiple HDM decoders.
> > 5) Use it as a path for testing spec features before publication (obviously can't
> >    talk about that on list but I've open in appropriate venue about that).
> > 
> > Happy to have help on any of the above, but 'features' that are reasonably separate
> > such as RAS support might be a good place for contributions that won't be
> > greatly affected by any other refactoring going on.
> > 
> > I've pushed all but SPDM support and stuff for which the spec isn't public yet up on
> > https://urldefense.com/v3/__https://gitlab.com/jic23/qemu/-/commits/cxl-v9-draft-1__;!!EwVzqGoTKBqv-0DWAJBm!HzD_Dh_I9m9MydppOSSyhuzvwTawlg7LE77bEYiZ1i3AMgxV_YOI56VeZgkg-EMwmPTV$ 
> > (as you can see CI found a segfault today so I'll push the fix out for that
> >  shortly - that also highlighted a build breakage mid series that I've fixed up.).
> >   
> 
> Once again thanks for all of the pointers. 

You are welcome. It's nice to see this work gain traction :)

Anyhow, v9 is on it's way (slowly) through our firewall (got log anti spam
send rate limits) so fingers crossed we are nearly ready with this first bit
of support to build more fun stuff on top of.

Jonathan

> 
> > Jonathan