On 10/19/24 06:30, Zhi Wang wrote:
On 04/10/2024 14.40, Jonathan Cameron wrote:
External email: Use caution opening links or attachments
Presumably, the host creates one large CXL region that covers the entire
DPA, while QEMU can virtually partition it into different regions and
map them to different virtual CXL region if QEMU presents multiple HDM
decoders to the guest.
I'm not sure why it would do that. Can't think why you'd break up
a host region - maybe I'm missing something.
It is mostly concerning about a device can have multiple HDM decoders.
In the current design, a large physical CXL (pCXL) region with the whole
DPA will be passed to the userspace. Thinking that the guest will see
the virtual multiple HDM decoders, which usually SW is asking for, the
guest SW might create multiple virtual CXL regions. In that case QEMU
needs to map them into different regions of the pCXL region.
Don't let the guest see multiple HDM decoders?
There is no obvious reason why it would want them other than type
differences.
Why is it useful for a type 2 device to be setup for multiple CXL regions?
It shouldn't be a performance thing. Might be convenient for management
I guess, but the driver can layer it's own allocator etc on top of a single
region so I'm not sure I see a reason to do this...
Sorry for the late reply as I were confirming the this requirement with
folks. It make sense to have only one HDM decoder for the guest CXL
type-2 device driver. I think it is similar to efx_cxl according to the
code. Alejandro, it would be nice you can confirm this.
Not sure if how sfc does this should be taken as any confirmation of
expected behavior/needs, but we plan to have just one HDM decoder and
one region covering it all.
But maybe it is important to make clear the distinction between an HDM
decoder and CXL regions linked to it. In other words, I can foresee
different regions programmed by the driver because the way coherency is
going to be handled by the device changes for each region. So supporting
multiple regions makes sense with just one decoder. Not sure if we
should rely on an use case for supporting more than one region ...
Thanks,
Zhi.
Jonathan
