[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] V2 pci uart - better cope with UART being temporarily unavailable
On 08/27/2013 03:59 PM, Jan Beulich wrote:
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().
Ah sure, will repost v4 soon then
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
