Re: [Xen-devel] [PATCH 3/3] x86/AMD-Vi: Fix IVRS HPET special->handle override

[Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>]

On 9/25/2013 1:12 AM, Jan Beulich wrote:
> > > > On 25.09.13 at 01:26, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
> > > > wrote:
> > Ok, after looking into Intel HPET specification, I can see that the spec
> > allows a particular system
> > to have multiple HPETs.  And Jan was correct that only one is required
> > to be listed in the APCI HPET table.
> > The rest are listed in ACPI namespace.
> >
> > I look at the "arch/x86/hpet.c" and saw that this supports discovery in
> > the ACPI HPET table.
> > However, there is only one "hpet_address" and "hpet_blockid", which are
> > initialized in the
> > "arch/x86/acpi/boot.c: acpi_parse_hpet()".  If the code were to support
> > more than one HPET,
> > this would have to be changed also.  Do you expect these to change as well?
> This second paragraph contradicts what you correctly describe in
> the first: There's only one required to be listed in the ACPI HPET
> table, and hence that code isn't expected to change.
>
> > Also, I don't see the code that would walk the ACPI namespace anywhere.
> > Does it exist?
> In Dom0, yes. But the information not getting passed down is of
> no relevance here: All we care about is how to correctly find the
> IOMMU for the one HPET we use, which ought to work no matter
> how many HPETs there are in the system.
>
> Jan
Actually, I found out that "struct hpet_sbdf.iommu" is not used 
anywhere.  We should be able
to get rid of this, and it should now be simpler logic.  I'll remove 
this in my next patch.
Suravee


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