[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 as pvh boot problem

>>> On 06.01.15 at 23:20, <ufimtseva@xxxxxxxxx> wrote:
> On Mon, Jan 5, 2015 at 3:44 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> >>> Elena Ufimtseva <ufimtseva@xxxxxxxxx> 01/02/15 7:32 PM >>>
>> >The last successful command is the reading status register of second IOMMU
>> >unit:
>> >
>> ><snip from iommu_enable_translation() in
>> >./xen/drivers/passthrough/vtd/iommu.c>
>> >
>> >746:    sts = dmar_readl(iommu->reg, DMAR_GSTS_REG);
>> >747:    dmar_writel(iommu->reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE);
>> >
>> ></snip>
>> >
>> >After dmar_writel for second iommu the machine hangs.
>> That's rather odd - you say it doesn't even reach the IOMMU_WAIT_OP()
>> right after that?
> Thats odd, last tests I did show that it does complete the write to the
> control register
> of the second drhd, but I cannot say if it reaches IOMMU_WAIT_OP() as right
> after this write it hangs.
> I tried to enable iommu's in reverse order with the same result.

"The same" being it hanging on the second one being enabled, or
no hanging on the one getting enabled first?

>> That would suggest a fault or other abnormal condition
>> raised by the translation enabling (i.e. some problem with the page tables,
>> albeit that should then have been a problem for the first IOMMU already).
> I wonder if such problem can be diagnosed without interrupt. Maybe
> reflected in error logging event registers?

Sure - you'd need to poll those registers, which you can't if the
CPU really hangs. Or maybe you could try to monitor the IOMMU
state from another CPU...


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.