[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Draft F] Xen on ARM vITS Handling



On 16/06/15 16:10, Ian Campbell wrote:
>>>
>>>>>> This could happen when the device is not quiescent. We had this issue on
>>>>>> the vexpress at boot time when the network card was trying to send an
>>>>>> interrupt before DOM0 is setup.
>>>>>
>>>>> I don't fully understand the issue you are trying to describe, but do
>>>>> you want to propose a change to the spec?
>>>>
>>>> I actually don't know how to modify it. So it's an open question.
>>>
>>> For SPI too, or just for LPI?
>>
>> Only LPI.
> 
> How is it fixed for SPI?

We queue the SPI but don't inject it (gic_raise_guest_irq) to the guest.

The injection will be done when the guest enable the IRQ.

We can't use it for LPIs as the mapping vLPI -> pLPI may not yet exists.

>>>> vgic_vcpu_inject_irq doesn't queue the interrupt if a VCPU is down. I
>>>> think this is because the state of the VCPU wouldn't be correct.
>>>>
>>>> The process would be something like:
>>>>
>>>>       - Creation of the domain
>>>>    => All vCPUs are down
>>>>
>>>>       - Device is assigned to the guest
>>>>           => Enable physical LPIs
>>>>
>>>>       * physical LPI is received *
>>>>    => Will be ignored and not EOIed (VCPU0 is down)
>>>>           => The LPI will never fired again during the guest life
>>>>
>>>>       -  Domain is started by the toolstack
>>>>            => VCPU0 is online
>>>
>>> Is it sufficient to queue interrupts even for VCPUs which are down? How
>>> does the lack of a vITT entry when this interrupt occurred affect this?
>>
>> Well, in this case we don't know on which vLPI we have to inject it. But 
>> as said above, I guess we don't care if we ensure that the device can't 
>> send an event (by ensuring that the device doesn't know the 
>> GITS_TRANSLATER address is).
> 
> Yes, I think that works.
> 
> I'm not sure where to spell that out though.

We want to find a way to avoid the PCI device to send an event. I see
multiple possibility to do it:
        1) Mask the event MSI-X allow to mask a specific event. There is a
similar feature for MSI but it's optional.
        2) Compose the MSI message only when the vLPI is enabled. That require
Xen/PCI-back to delay the write in the config space.

None of this solution satisfy me. But I don't have much knowledge on how
PCI-passthrough works on Xen.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.