Wei Wang2
2009-Oct-28 16:32 UTC
[Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
Using a global interrupt remapping table shared by all devices has better compatibility with certain old BIOSes. Per-device interrupt remapping table can still be enabled by using a new parameter "amd-iommu-perdev-intremap". Thanks, Wei Signed-off-by: Wei Wang <wei.wang2@amd.com> -- AMD GmbH, Germany Operating System Research Center Legal Information: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34 85609 Dornach b. München Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Jul-19 14:14 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
Wei, Can you be more specific about which BIOSes behave poorly with per-device intremap tables, and why? The problem with a global intremap table is that, AFAICT, it''s not fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, different devices may end up with interrupts mapped to different cpus but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B mapped to cpu 12 vector 67). This is by design; the whole point of the per-cpu IDTs is to avoid restricting the number of IRQs to the number of vectors. But it seems that the intremap table only maps vectors, not destination IDs; so in the example above, both devices'' interrupts would end up being remapped to the same place, causing one device driver to get both sets of interrupts, and the other to get none. Do I understand correctly? If so, it seems like we should switch to per-device intremap tables by default; and if we''re using a global intremap table, we need to somehow make sure that vectors are not shared across cpus. -George On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote:> Using a global interrupt remapping table shared by all devices has better > compatibility with certain old BIOSes. Per-device interrupt remapping table > can still be enabled by using a new parameter "amd-iommu-perdev-intremap". > Thanks, > Wei > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > -- > AMD GmbH, Germany > Operating System Research Center > > Legal Information: > Advanced Micro Devices GmbH > Karl-Hammerschmidt-Str. 34 > 85609 Dornach b. München > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > Registergericht München, HRB Nr. 43632 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wei Wang2
2011-Jul-20 09:52 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Tuesday 19 July 2011 16:14:31 George Dunlap wrote:> Wei, > > Can you be more specific about which BIOSes behave poorly with > per-device intremap tables, and why?We found that, in some case, SATA device uses different device ids for dma remapping and interrupt remapping. Some early BIOSes cannot handle this situation correctly, so if SATA uses device id for DMA to lookup device table entry for intremap table and if intremap table is per-device configured, SATA device won''t get the right table.> The problem with a global intremap table is that, AFAICT, it''s not > fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, > different devices may end up with interrupts mapped to different cpus > but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B > mapped to cpu 12 vector 67). This is by design; the whole point of > the per-cpu IDTs is to avoid restricting the number of IRQs to the > number of vectors. But it seems that the intremap table only maps > vectors, not destination IDs; so in the example above, both devices'' > interrupts would end up being remapped to the same place, causing one > device driver to get both sets of interrupts, and the other to get > none.Yes, obviously a problem...Using shared intremap table, devices uses the same vector and delivery mode will end up to the same remapping entry. Is per-cpu IDTs enable by default in Xen?> Do I understand correctly? If so, it seems like we should switch to > per-device intremap tables by default; and if we''re using a global > intremap table, we need to somehow make sure that vectors are not > shared across cpus.I agree to use per-device table by default, since BIOS issue has been fixed and per-device table also has some security advantages. Thanks, Wei> -George > > On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote: > > Using a global interrupt remapping table shared by all devices has better > > compatibility with certain old BIOSes. Per-device interrupt remapping > > table can still be enabled by using a new parameter > > "amd-iommu-perdev-intremap". Thanks, > > Wei > > > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > > -- > > AMD GmbH, Germany > > Operating System Research Center > > > > Legal Information: > > Advanced Micro Devices GmbH > > Karl-Hammerschmidt-Str. 34 > > 85609 Dornach b. München > > > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > > Registergericht München, HRB Nr. 43632 > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jul-20 10:50 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Wed, 2011-07-20 at 10:52 +0100, Wei Wang2 wrote:> On Tuesday 19 July 2011 16:14:31 George Dunlap wrote: > > Wei, > > > > Can you be more specific about which BIOSes behave poorly with > > per-device intremap tables, and why? > We found that, in some case, SATA device uses different device ids for dma > remapping and interrupt remapping. Some early BIOSes cannot handle this > situation correctly, so if SATA uses device id for DMA to lookup device table > entry for intremap table and if intremap table is per-device configured, SATA > device won''t get the right table.Was this issue present in production BIOSes or do you mean early as in pre-production? IOW can we drop the support non-share remapping table altogether or do we need to fix things in this mode to force the IDT to be identical across CPUs (either by resharing the IDT in that case, ick, or by enforcing that the contents are the same for devices with this property)? OOI was the issue a confusion between the SATA PCI device and the legacy PCI IDE facet of the same device?> > The problem with a global intremap table is that, AFAICT, it''s not > > fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, > > different devices may end up with interrupts mapped to different cpus > > but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B > > mapped to cpu 12 vector 67). This is by design; the whole point of > > the per-cpu IDTs is to avoid restricting the number of IRQs to the > > number of vectors. But it seems that the intremap table only maps > > vectors, not destination IDs; so in the example above, both devices'' > > interrupts would end up being remapped to the same place, causing one > > device driver to get both sets of interrupts, and the other to get > > none. > > Yes, obviously a problem...Using shared intremap table, devices uses the same > vector and delivery mode will end up to the same remapping entry. Is per-cpu > IDTs enable by default in Xen?I didn''t think it was even optional these days, but I didn''t check.> > Do I understand correctly? If so, it seems like we should switch to > > per-device intremap tables by default; and if we''re using a global > > intremap table, we need to somehow make sure that vectors are not > > shared across cpus. > I agree to use per-device table by default, since BIOS issue has been fixed > and per-device table also has some security advantages. > > Thanks, > Wei > > > -George > > > > On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote: > > > Using a global interrupt remapping table shared by all devices has better > > > compatibility with certain old BIOSes. Per-device interrupt remapping > > > table can still be enabled by using a new parameter > > > "amd-iommu-perdev-intremap". Thanks, > > > Wei > > > > > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > > > -- > > > AMD GmbH, Germany > > > Operating System Research Center > > > > > > Legal Information: > > > Advanced Micro Devices GmbH > > > Karl-Hammerschmidt-Str. 34 > > > 85609 Dornach b. München > > > > > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > > > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > > > Registergericht München, HRB Nr. 43632 > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wei Wang2
2011-Jul-20 12:34 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
Wednesday 20 July 2011 12:50:25 Ian Campbell wrote:> On Wed, 2011-07-20 at 10:52 +0100, Wei Wang2 wrote: > > On Tuesday 19 July 2011 16:14:31 George Dunlap wrote: > > > Wei, > > > > > > Can you be more specific about which BIOSes behave poorly with > > > per-device intremap tables, and why? > > > > We found that, in some case, SATA device uses different device ids for > > dma remapping and interrupt remapping. Some early BIOSes cannot handle > > this situation correctly, so if SATA uses device id for DMA to lookup > > device table entry for intremap table and if intremap table is per-device > > configured, SATA device won''t get the right table. > > Was this issue present in production BIOSes or do you mean early as in > pre-production? IOW can we drop the support non-share remapping table > altogether or do we need to fix things in this mode to force the IDT to > be identical across CPUs (either by resharing the IDT in that case, ick, > or by enforcing that the contents are the same for devices with this > property)? > > OOI was the issue a confusion between the SATA PCI device and the legacy > PCI IDE facet of the same device?Yes, using shared intremap table is the workaround for this issue. Ideally, BIOS should create 2 IVRS entries for SATA devices in IDE combined mode, one for DMA the other for interrupt. But this setup is not strict compatible with iommu specification. So recent BIOS should have IDE combined mode disabled in this case. So I believe that remove the global table is safe from now on. I could send patches. Thanks, Wei> > > The problem with a global intremap table is that, AFAICT, it''s not > > > fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, > > > different devices may end up with interrupts mapped to different cpus > > > but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B > > > mapped to cpu 12 vector 67). This is by design; the whole point of > > > the per-cpu IDTs is to avoid restricting the number of IRQs to the > > > number of vectors. But it seems that the intremap table only maps > > > vectors, not destination IDs; so in the example above, both devices'' > > > interrupts would end up being remapped to the same place, causing one > > > device driver to get both sets of interrupts, and the other to get > > > none. > > > > Yes, obviously a problem...Using shared intremap table, devices uses the > > same vector and delivery mode will end up to the same remapping entry. Is > > per-cpu IDTs enable by default in Xen? > > I didn''t think it was even optional these days, but I didn''t check. > > > > Do I understand correctly? If so, it seems like we should switch to > > > per-device intremap tables by default; and if we''re using a global > > > intremap table, we need to somehow make sure that vectors are not > > > shared across cpus. > > > > I agree to use per-device table by default, since BIOS issue has been > > fixed and per-device table also has some security advantages. > > > > Thanks, > > Wei > > > > > -George > > > > > > On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote: > > > > Using a global interrupt remapping table shared by all devices has > > > > better compatibility with certain old BIOSes. Per-device interrupt > > > > remapping table can still be enabled by using a new parameter > > > > "amd-iommu-perdev-intremap". Thanks, > > > > Wei > > > > > > > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > > > > -- > > > > AMD GmbH, Germany > > > > Operating System Research Center > > > > > > > > Legal Information: > > > > Advanced Micro Devices GmbH > > > > Karl-Hammerschmidt-Str. 34 > > > > 85609 Dornach b. München > > > > > > > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > > > > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > > > > Registergericht München, HRB Nr. 43632 > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Jul-20 13:01 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Wed, 2011-07-20 at 13:34 +0100, Wei Wang2 wrote:> Wednesday 20 July 2011 12:50:25 Ian Campbell wrote: > > On Wed, 2011-07-20 at 10:52 +0100, Wei Wang2 wrote: > > > On Tuesday 19 July 2011 16:14:31 George Dunlap wrote: > > > > Wei, > > > > > > > > Can you be more specific about which BIOSes behave poorly with > > > > per-device intremap tables, and why? > > > > > > We found that, in some case, SATA device uses different device ids for > > > dma remapping and interrupt remapping. Some early BIOSes cannot handle > > > this situation correctly, so if SATA uses device id for DMA to lookup > > > device table entry for intremap table and if intremap table is per-device > > > configured, SATA device won''t get the right table. > > > > Was this issue present in production BIOSes or do you mean early as in > > pre-production? IOW can we drop the support non-share remapping table > > altogether or do we need to fix things in this mode to force the IDT to > > be identical across CPUs (either by resharing the IDT in that case, ick, > > or by enforcing that the contents are the same for devices with this > > property)? > > > > OOI was the issue a confusion between the SATA PCI device and the legacy > > PCI IDE facet of the same device? > > Yes, using shared intremap table is the workaround for this issue. Ideally, > BIOS should create 2 IVRS entries for SATA devices in IDE combined mode, one > for DMA the other for interrupt. But this setup is not strict compatible with > iommu specification. So recent BIOS should have IDE combined mode disabled in > this case. So I believe that remove the global table is safe from now on. I > could send patches.Please do. Ian.> Thanks, > Wei > > > > > The problem with a global intremap table is that, AFAICT, it''s not > > > > fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, > > > > different devices may end up with interrupts mapped to different cpus > > > > but the same vector (i.e., device A mapped to cpu 9 vector 67, cpu B > > > > mapped to cpu 12 vector 67). This is by design; the whole point of > > > > the per-cpu IDTs is to avoid restricting the number of IRQs to the > > > > number of vectors. But it seems that the intremap table only maps > > > > vectors, not destination IDs; so in the example above, both devices'' > > > > interrupts would end up being remapped to the same place, causing one > > > > device driver to get both sets of interrupts, and the other to get > > > > none. > > > > > > Yes, obviously a problem...Using shared intremap table, devices uses the > > > same vector and delivery mode will end up to the same remapping entry. Is > > > per-cpu IDTs enable by default in Xen? > > > > I didn''t think it was even optional these days, but I didn''t check. > > > > > > Do I understand correctly? If so, it seems like we should switch to > > > > per-device intremap tables by default; and if we''re using a global > > > > intremap table, we need to somehow make sure that vectors are not > > > > shared across cpus. > > > > > > I agree to use per-device table by default, since BIOS issue has been > > > fixed and per-device table also has some security advantages. > > > > > > Thanks, > > > Wei > > > > > > > -George > > > > > > > > On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com> wrote: > > > > > Using a global interrupt remapping table shared by all devices has > > > > > better compatibility with certain old BIOSes. Per-device interrupt > > > > > remapping table can still be enabled by using a new parameter > > > > > "amd-iommu-perdev-intremap". Thanks, > > > > > Wei > > > > > > > > > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > > > > > -- > > > > > AMD GmbH, Germany > > > > > Operating System Research Center > > > > > > > > > > Legal Information: > > > > > Advanced Micro Devices GmbH > > > > > Karl-Hammerschmidt-Str. 34 > > > > > 85609 Dornach b. München > > > > > > > > > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > > > > > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > > > > > Registergericht München, HRB Nr. 43632 > > > > > > > > > > _______________________________________________ > > > > > Xen-devel mailing list > > > > > Xen-devel@lists.xensource.com > > > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wei Wang2
2011-Jul-20 15:56 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
George & Ian, Patch attached. This patch removes global interrupt remapping table and uses per-device table instead. This should work with per-cpu IDTs. We are safe to remove global table since SATA device id issue dose not appear in recent production BIOS. Thanks, Wei Signed-off-by: Wei Wang <wei.wang2@amd.com> -- Advanced Micro Devices GmbH Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 WEEE Registrierungsnummer 129 19551 Geschäftsführer: Alberto BozzoOn Wednesday 20 July 2011 15:01:35 Ian Campbell wrote:> On Wed, 2011-07-20 at 13:34 +0100, Wei Wang2 wrote: > > Wednesday 20 July 2011 12:50:25 Ian Campbell wrote: > > > On Wed, 2011-07-20 at 10:52 +0100, Wei Wang2 wrote: > > > > On Tuesday 19 July 2011 16:14:31 George Dunlap wrote: > > > > > Wei, > > > > > > > > > > Can you be more specific about which BIOSes behave poorly with > > > > > per-device intremap tables, and why? > > > > > > > > We found that, in some case, SATA device uses different device ids > > > > for dma remapping and interrupt remapping. Some early BIOSes cannot > > > > handle this situation correctly, so if SATA uses device id for DMA to > > > > lookup device table entry for intremap table and if intremap table is > > > > per-device configured, SATA device won''t get the right table. > > > > > > Was this issue present in production BIOSes or do you mean early as in > > > pre-production? IOW can we drop the support non-share remapping table > > > altogether or do we need to fix things in this mode to force the IDT to > > > be identical across CPUs (either by resharing the IDT in that case, > > > ick, or by enforcing that the contents are the same for devices with > > > this property)? > > > > > > OOI was the issue a confusion between the SATA PCI device and the > > > legacy PCI IDE facet of the same device? > > > > Yes, using shared intremap table is the workaround for this issue. > > Ideally, BIOS should create 2 IVRS entries for SATA devices in IDE > > combined mode, one for DMA the other for interrupt. But this setup is not > > strict compatible with iommu specification. So recent BIOS should have > > IDE combined mode disabled in this case. So I believe that remove the > > global table is safe from now on. I could send patches. > > Please do. > > Ian. > > > Thanks, > > Wei > > > > > > > The problem with a global intremap table is that, AFAICT, it''s not > > > > > fundamentally compatible with per-cpu IDTs. With per-cpu IDTs, > > > > > different devices may end up with interrupts mapped to different > > > > > cpus but the same vector (i.e., device A mapped to cpu 9 vector 67, > > > > > cpu B mapped to cpu 12 vector 67). This is by design; the whole > > > > > point of the per-cpu IDTs is to avoid restricting the number of > > > > > IRQs to the number of vectors. But it seems that the intremap > > > > > table only maps vectors, not destination IDs; so in the example > > > > > above, both devices'' interrupts would end up being remapped to the > > > > > same place, causing one device driver to get both sets of > > > > > interrupts, and the other to get none. > > > > > > > > Yes, obviously a problem...Using shared intremap table, devices uses > > > > the same vector and delivery mode will end up to the same remapping > > > > entry. Is per-cpu IDTs enable by default in Xen? > > > > > > I didn''t think it was even optional these days, but I didn''t check. > > > > > > > > Do I understand correctly? If so, it seems like we should switch > > > > > to per-device intremap tables by default; and if we''re using a > > > > > global intremap table, we need to somehow make sure that vectors > > > > > are not shared across cpus. > > > > > > > > I agree to use per-device table by default, since BIOS issue has been > > > > fixed and per-device table also has some security advantages. > > > > > > > > Thanks, > > > > Wei > > > > > > > > > -George > > > > > > > > > > On Wed, Oct 28, 2009 at 4:32 PM, Wei Wang2 <wei.wang2@amd.com>wrote:> > > > > > Using a global interrupt remapping table shared by all devices > > > > > > has better compatibility with certain old BIOSes. Per-device > > > > > > interrupt remapping table can still be enabled by using a new > > > > > > parameter "amd-iommu-perdev-intremap". Thanks, > > > > > > Wei > > > > > > > > > > > > Signed-off-by: Wei Wang <wei.wang2@amd.com> > > > > > > -- > > > > > > AMD GmbH, Germany > > > > > > Operating System Research Center > > > > > > > > > > > > Legal Information: > > > > > > Advanced Micro Devices GmbH > > > > > > Karl-Hammerschmidt-Str. 34 > > > > > > 85609 Dornach b. München > > > > > > > > > > > > Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni > > > > > > Sitz: Dornach, Gemeinde Aschheim, Landkreis München > > > > > > Registergericht München, HRB Nr. 43632 > > > > > > > > > > > > _______________________________________________ > > > > > > Xen-devel mailing list > > > > > > Xen-devel@lists.xensource.com > > > > > > http://lists.xensource.com/xen-devel > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Jul-21 09:07 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Wed, Jul 20, 2011 at 4:56 PM, Wei Wang2 <wei.wang2@amd.com> wrote:> George & Ian, > Patch attached. This patch removes global interrupt remapping table and uses > per-device table instead. This should work with per-cpu IDTs. We are safe to > remove global table since SATA device id issue dose not appear in recent > production BIOS.Exactly how "recent" are these BIOSes? Or I guess alternately, how old are the BIOSes that broke? We still have customers who seem to have hardware that''s several years old; if the answer isn''t something like "8 years", it may be better to just change the default setting. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wei Wang2
2011-Jul-21 10:38 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Thursday 21 July 2011 11:07:40 George Dunlap wrote:> On Wed, Jul 20, 2011 at 4:56 PM, Wei Wang2 <wei.wang2@amd.com> wrote: > > George & Ian, > > Patch attached. This patch removes global interrupt remapping table and > > uses per-device table instead. This should work with per-cpu IDTs. We > > are safe to remove global table since SATA device id issue dose not > > appear in recent production BIOS. > > Exactly how "recent" are these BIOSes? Or I guess alternately, how > old are the BIOSes that broke?George, Actually, we encountered this issue about 2 years ago and fixed this in BIOS. There should be very less productions shipped the mark at that time (probably none) and all newer products after that should absorb this fix. Even without BIOS fix, user can always disable IDE mode from BIOS menu manually if they were hit by this issue. So basically, I think removing global table is also reasonable. Thanks Wei> We still have customers who seem to have hardware that''s several years > old; if the answer isn''t something like "8 years", it may be better to > just change the default setting. > > -George_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Jul-21 14:36 UTC
Re: [Xen-devel] [PATCH] AMD IOMMU: Use global interrupt remapping table by default
On Thu, Jul 21, 2011 at 11:38 AM, Wei Wang2 <wei.wang2@amd.com> wrote:> On Thursday 21 July 2011 11:07:40 George Dunlap wrote: >> On Wed, Jul 20, 2011 at 4:56 PM, Wei Wang2 <wei.wang2@amd.com> wrote: >> > George & Ian, >> > Patch attached. This patch removes global interrupt remapping table and >> > uses per-device table instead. This should work with per-cpu IDTs. We >> > are safe to remove global table since SATA device id issue dose not >> > appear in recent production BIOS. >> >> Exactly how "recent" are these BIOSes? Or I guess alternately, how >> old are the BIOSes that broke? > > George, > Actually, we encountered this issue about 2 years ago and fixed this in BIOS. > There should be very less productions shipped the mark at that time (probably > none) and all newer products after that should absorb this fix. Even without > BIOS fix, user can always disable IDE mode from BIOS menu manually if they > were hit by this issue. So basically, I think removing global table is also > reasonable.Sounds reasonable to me. Acked-by: George Dunlap <george.dunlap@eu.citirx.com>> Thanks > Wei > >> We still have customers who seem to have hardware that''s several years >> old; if the answer isn''t something like "8 years", it may be better to >> just change the default setting. >> >> -George > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel