Re: [Xen-devel] [PATCH] V2 pci uart - better cope with UART being temporarily unavailable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.13 at 15:44, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
> On 08/27/2013 02:26 PM, Jan Beulich wrote:
>>>>> On 27.08.13 at 12:15, Tomasz Wroblewski<tomasz.wroblewski@xxxxxxxxxx>  
>>>>> wrote:
>>> @@ -102,12 +107,17 @@ static void __ns16550_poll(struct cpu_user_regs *regs)
>>>       if ( uart->intr_works )
>>>           return; /* Interrupts work - no more polling */
>>>
>>> -    while ( ns_read_reg(uart, UART_LSR)&  UART_LSR_DR )
>>> -        serial_rx_interrupt(port, regs);
>>> +     while ( ns_read_reg(uart, UART_LSR)&  UART_LSR_DR )
>>> +     {
>>> +         serial_rx_interrupt(port, regs);
>>> +         if ( ns16550_ioport_invalid(uart) )
>>> +             goto out;
>>> +     }
>>>
>>>       if ( ns_read_reg(uart, UART_LSR)&  UART_LSR_THRE )
>>>           serial_tx_interrupt(port, regs);
>>>
>>> +out:
>> So serial_rx_interrupt() gets run once in that case, but
>> serial_tx_interrupt() not at all? That not only inconsistent, I also
>> can't see why anything would need to be done here at all in this
>> case. Plus doing the check before the loop would shrink patch
>> size.
> So I presume it is impossible for dom0 code to run on another cpu whilst 
> xen is executing the poll routine, I was not sure at all about this? 
> Would like to avoid the possibility of dom0 disabling device whilst this 
> loop is running.

Of course can a Dom0 vCPU run on another pCPU.

And yes, I hence appreciate reducing the risk window. But then
please do the check before calling serial_rx_interrupt().

Jan


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