[Yunhong Jiang]
> Espen Skoglund <mailto:espen.skoglund@xxxxxxxxxxxxx> wrote:
>> [Yunhong Jiang]
>>> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
>>>> You're right in that Linux does not currently support this. You
>>>> can, however, allocate multiple interrupts using MSI-X. Anyhow,
>>>> I was not envisioning this feature being used directly for
>>>> passthrough device access. Rather, I was considering the case
>>>> where a device could be configured to communicate data directly
>>>> into a VM (e.g., using multi-queue NICs) and deliver the
>>>> interrupt to the appropriate VM. In this case the frontend in
>>>> the guest would not need to see a multi-message MSI device, only
>>>> the backend in dom0/the driver domain would need to be made aware
>>>> of it.
>>
>>> Although I don't know if any device has such usage model (Intel's
>>> VMDq is using MSI-X ), but yes, your usage model will be helpful.
>>> To achive this, maybe we need change the protocol between pci
>>> backend and pci frontend, in fact, maybe the
>>> pci_enable_msi/pci_enable_msix can be commbind, with a flag to
>>> determin if the vector should be continous or not.
>>
>> This is similar to my initial idea as well. In addition to being
>> contigous the multi-message MSI request would also need to allocate
>> vectors that are properly aligned.
> Yes, but don't think we need add the implementation now. We can
> change the xen_pci_op to accomondate this requirement, otherwise,
> this will cause more difference with upstream Linux. (Maybe the
> hypercall need changed for this requirement also).
Isn't this more of a PHYSDEVOP_alloc_irq_vector thing? That is, dom0
should be able to request a region of contigous vectors. As for
upstream Linux differences, we should get away with only a few
modifications to the MSI specific parts in dom0. Also, if contigous
vector regions are wanted, the vector allocation alogorithm in Xen
should be changed to avoid spreading the allocations all over place.
> As for set_irq_affinity, I think it is a general issue, not MSI
> related, we can follow up on it continously.
Agreed.
eSk
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home