From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: "Ostrovsky, Boris" <Boris.Ostrovsky@amd.com>,
"Huang2, Wei" <Wei.Huang2@amd.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] AMD IOMMU: Fix an interrupt remapping issue
Date: Fri, 8 Apr 2011 16:26:43 +0200 [thread overview]
Message-ID: <201104081626.44096.wei.wang2@amd.com> (raw)
In-Reply-To: <4D9F2D3D020000780003A9AD@vpn.id2.novell.com>
On Friday 08 April 2011 15:43:57 Jan Beulich wrote:
> >>> On 08.04.11 at 13:35, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > Some device could generate bogus interrupts if an IO-APIC RTE and an
> > iommu interrupt remapping entry are not consistent during 2 adjacent
> > 64bits IO-APIC RTE updates. For example, if the 2nd operation updates
> > destination bits in RTE for SATA device and unmask it, in some case, SATA
> > device will assert ioapic pin to generate interrupt immediately using new
> > destination but iommu could still translate it into the old destination,
> > then dom0 would be confused. To fix that, we sync up interrupt remapping
> > entry with IO-APIC IRE on every 32 bits operation and foward IOAPIC RTE
> > updates after interrupt remapping table has been changed.
>
> I don't think this is correct: Without the patch, the filling of ioapic_rte
> takes into account the value already written. Now that you only write
> the value at the end of the function, you should overwrite the
> affected half with "value" immediately before calling
> update_intremap_entry_from_ioapic().
Sorry, not quite understand your point. My thought is, no matter dom0 tried to
updates lower half or upper half of RTE, we always updates interrupt table
from the lower half. This will keep iommu table strictly identically to RTE.
The old code has an assumption that both lower half and upper of RTE should
be updated together. But this might not be always true. If by incident, dom0
only updates the upper half and we don't sync iommu with it, then the
destination in RTE and iommu table will be different.
> (Without knowing which half
> gets written, passing "value" to update_intremap_entry_from_ioapic()
> is pointless, and indeed the function doesn't use that parameter.)
True, I will remove this parameter in update_intremap_entry_from_ioapic().
ioapic_rte should have all information.
> Eliminating the double write if reg == rte_lo would also seem desirable
> (and in no case should you write back the old value after having called
> update_intremap_entry_from_ioapic()).
It not a write back, It just finishes IO-APIC RTE writes. After updating
interrupt remapping table we still have to update RTE. It is just a copy of
__io_apic_write (maybe I should just call it). Old code updates ioapic
earlier than interrupt remapping table and sata device might generate
interrupt right after this, which is not expected.
Thanks,
Wei
> Jan
next prev parent reply other threads:[~2011-04-08 14:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 11:35 [PATCH] AMD IOMMU: Fix an interrupt remapping issue Wei Wang2
2011-04-08 13:43 ` Jan Beulich
2011-04-08 14:26 ` Wei Wang2 [this message]
2011-04-08 14:39 ` Jan Beulich
2011-04-08 15:06 ` Wei Wang2
2011-04-08 16:52 ` [PATCH] AMD IOMMU: Fix an interrupt remapping issue (v2) Wei Wang2
2011-04-11 7:23 ` Jan Beulich
2011-04-11 7:39 ` Wei Wang2
2011-04-11 10:31 ` [PATCH V3] AMD IOMMU: Fix an interrupt remapping issue Wei Wang2
2011-04-11 11:35 ` Jan Beulich
2011-07-19 9:37 ` George Dunlap
2011-07-19 9:59 ` George Dunlap
-- strict thread matches above, loose matches on Subject: below --
2011-04-08 10:52 [PATCH] " Wei Wang2
2011-04-08 11:26 ` 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=201104081626.44096.wei.wang2@amd.com \
--to=wei.wang2@amd.com \
--cc=Boris.Ostrovsky@amd.com \
--cc=JBeulich@novell.com \
--cc=Wei.Huang2@amd.com \
--cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).