Re: [RFC 00/13] vfio: introduce vfio-cxl to support CXL type-2 accelerator passthrough

Alejandro Lucero Palau
2024-10-21T11:07:10Z

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
>>
>>