Re: [Xen-devel] [PATCH] PCI uart: fix boot hang, and second S3 resume inactive timer list corruption

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.13 at 17:09, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
> On 08/26/2013 03:52 PM, Jan Beulich wrote:
>>>>> On 26.08.13 at 15:25, Tomasz Wroblewski<tomasz.wroblewski@xxxxxxxxxx>  
>>>>> wrote:
>>>> Nevertheless, the approach of your patch in simply giving up
>>>> the device (even if only termporarily) looks questionable to me
>>>> We'd rather need to restore full access to it I would think. But
>>>> yes, this hypervisor and Dom0 playing with the same device is
>>>> sort of a gray area.
>>> Restore ioport access at the start of poll routine (if not on) and
>>> disable it again at the end (if was not on)? I might do that (if you
>>> really prefer), but intuitively that seems more likely to produce side
>>> effects in dom0 kernel than skipping a poll in xen
>> As long as it's guaranteed to only be a poll (or a few of them) being
>> affected, this is fine. But what if an interrupt is being used?
> I'm probably missing something so can you elaborate on this? Probably 
> not what you are asking, but ns16550_interrupt function currently 
> doesn't hang when ioports are disabled as a byproduct of the     "while 
> ( !(ns_read_reg(uart, IIR) & IIR_NOINT) )" test in there, which already 
> causes it to break out on 0xFF regs

My question was along the lines of "If I/O port access is disabled,
isn't the whole driver screwed (even if only temporarily)?" And if
the answer to this is "yes" (I can't see it to be "no"), dealing with
this likely requires more than the change you proposed.

Jan


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