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

Re: [PATCH] x86/dpci: remove the dpci EOI timer



On 14.01.2021 13:33, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 12:45:27PM +0100, Jan Beulich wrote:
>> On 14.01.2021 11:22, Roger Pau Monné wrote:
>>> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
>>>> On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
>>>>> I guess I'd also need to disable MSI for the two devices to ensure
>>>>> they are both using the GSI?
>>>>
>>>> lspci in dom0 shows the USB xhci controller, iwlwifi, and e1000e
>>>> devices all with IRQ 16 and all with MSI disabled ("MSI: Enabled-").
>>>> The two linux HVMs run with (PV) linux stubdoms, and the HVM kernels
>>>> were started with pci=nosmi.  Networking through the iwlwifi device
>>>> works for that VM while a mouse attached to the xhci controller is
>>>> also working in the second VM.  Is there something else I should test?
>>>
>>> Not really, I think that test should be good enough, the issue is that
>>> we don't know which OS was seeing the issues noted by Kevin.
>>
>> Why a specific OS? Isn't this also guarding against malice?
> 
> No, I don't think this protects against any kind of malice (at least
> that I can think of). It just deasserts the guest virtual line
> periodically if the guest itself hasn't done so. It will also attempt
> to EOI the physical interrupt, but that's already done by the
> eoi_timer in irq_guest_action_t (which would be the part that protects
> against malice IMO).

Hmm, yes, there's certainly some overlap. And indeed the EOI
timer is set 1ms in the future, while the timer here allows
for 8ms to pass before taking action.

What I'm uncertain about is the interaction between both: It
would seem to me that the pirq_guest_eoi() invocation from
here could undermine the purpose of the EOI timer. In which
case it would in fact be a win to get rid of this timer here.

> It's my understanding that according to what Kevin pointed out this
> was done because when sharing a pirq amongst different guests a guest
> can get interrupts delivered before it has properly setup the device,
> and not deasserting those by Xen would get the guest into some kind of
> stuck state, where it's not deasserting the line for itself.
> 
> TBH I'm still trying to figure out how that scenario would look like,
> and why would just deasserting the line fix it. On the vIO-APIC case
> you would need to forcefully clean the IRR bit in order to receive
> further interrupts on that pin, so maybe the issue is that switching a
> vIO-APIC pin from level to trigger mode (which clears the IRR bit)
> should also deassert the line?

I suppose this was directed at Kevin - I'm struggling as well.

Jan



 


Rackspace

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