From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>,
wei.huang2@amd.com, Tim Deegan <tim@xen.org>,
xen-devel <xen-devel@lists.xen.org>,
weiwang.dd@gmail.com, xiantao.zhang@intel.com
Subject: Re: [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0
Date: Tue, 6 Nov 2012 15:24:22 +0100 [thread overview]
Message-ID: <1352211862.2155.13.camel@Solace> (raw)
In-Reply-To: <509915CD02000078000A6ABF@nat28.tlf.novell.com>
[-- Attachment #1.1: Type: text/plain, Size: 1843 bytes --]
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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-11-06 14:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 16:53 [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0 Jan Beulich
2012-11-05 17:15 ` Keir Fraser
2012-11-06 9:08 ` Jan Beulich
2012-11-06 9:44 ` Tim Deegan
2012-11-06 10:19 ` Jan Beulich
2012-11-06 12:08 ` Dario Faggioli
2012-11-06 12:38 ` Jan Beulich
2012-11-06 12:06 ` Dario Faggioli
2012-11-06 12:51 ` Jan Beulich
2012-11-06 13:58 ` Tim Deegan
2012-11-06 14:16 ` Dario Faggioli
2012-11-06 14:17 ` Jan Beulich
2012-11-06 14:29 ` Dario Faggioli
2012-11-08 12:42 ` Tim Deegan
2012-11-06 14:24 ` Dario Faggioli [this message]
2012-11-07 16:05 ` [PATCH, v2] IOMMU: don't immediately disable bus mastering on faults Jan Beulich
2012-11-08 12:46 ` Tim Deegan
2012-11-08 13:46 ` Jan Beulich
2012-11-08 14:23 ` Tim Deegan
2012-11-08 18:07 ` Dario Faggioli
2012-11-30 9:42 ` [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0 Keir Fraser
2012-11-30 9:50 ` Jan Beulich
2012-12-03 6:08 ` Zhang, Xiantao
2012-12-03 7:36 ` Jan Beulich
2012-12-04 0:55 ` Zhang, Xiantao
2012-12-04 8:19 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1352211862.2155.13.camel@Solace \
--to=dario.faggioli@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=wei.huang2@amd.com \
--cc=weiwang.dd@gmail.com \
--cc=xen-devel@lists.xen.org \
--cc=xiantao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.