Re: [Xen-devel] [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2012-11-06 at 12:51 +0000, Jan Beulich wrote:
> > Right. But moving the fault handling code to softirq should have already
> > helped solving/mitigating that, hasn't it?
> 
> It helps keeping Xen alive, but doesn't for any specific domain
> (including Dom0).
> 
Ok. Yes, now I remember... That was the main purpose of that work.
Thanks and sorry. :-P

> > When implementing and testing that, I wasn't able to reproduce any
> > livelock situation (although I can't exclude that to be at least partly
> > due to my inexperience, especially at the time, with I/O
> > virtualization)... Jan, have you (after killing the 'disable
> > bus-mastering part' of course)?
> 
> No, I haven't - you'd have to have a device that doesn't stop I/O
> after a finite amount was done (or program one that way, e.g. by
> handing it a cyclic list of SG descriptors or alike). Wasn't it at your
> (Citrix) end that the problem was actually observed/reported?
> 
Yes but, as Tim said, I was never able to get in touch with the original
faulting behavior/piece of hardware. Trying to simulate that as you're
suggesting is basically what I did, but, at that time, I was using a
passed-to-a-guest device, and wasn't bypassing (for anyone) the
~BUS_MASTERING thing... That's why I asked whether you observed a
different behaviour.

Anyway, I see that we're talking about different issues and understand
(now) what you're trying to solve and why that is needed, so, again,
sorry for dragging the discussion a bit out of scope. :-)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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