Re: [Xen-devel] Powerdown problem on XEN | ACPI S5

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/08/13 21:54, Atom2 wrote:
> Andrew,
> that does not sound too promising at the moment. Is there anything
> else I could provide to come to a resolution given that I/O
> virtualization is what the system is supposed to do.
>
> You mention ACPI tables - I have no clue how to provide those, but I
> am more than happy to do what I can?
>
> Ian (Campbell) originally diverted me to Jan (Beulich) who seemed to
> have an idea before you thankfully jumped in. Jan's idea seemed to
> also revolve around ACPI - although not tables, but registers:
>
> quote from Jan Beulich:
> > It would be particularly interesting to know whether perhaps
> > some of the ACPI registers live in memory space on that
> > system - I already have a patch queued up (but not submitted
> > yet) that fixes problems in that case.
>
> @Jan: would it make sense to go down that route?
>
> Thanks again to everybody for their help so far.

I would first start with the suggestion from Ben & Konrad, especially as
this smells the same in terms of breakage.

If that fails, you can get at the acpi tables using `acpidump` which
looks to live in the pmtools package in gentoo.

~Andrew

>
>
> Am 14.08.13 22:38, schrieb Andrew Cooper:
>> On 14/08/13 21:24, Atom2 wrote:
>>> Am 14.08.13 22:18, schrieb Andrew Cooper:
>>> [...]
>>>>
>>>> Ok thanks.
>>>>
>>>> Do you mind confirming whether S5 works with "iommu=off" on the Xen
>>>> command line?
>>>>
>>>> ~Andrew
>>>>
>>> Yes, that works: The system powers off after issuing
>>>      shutdown -h now
>>> from the dom0.
>>
>> So it is certainly an iommu interaction issue, which was sadly suspected
>> given that we have seen similar problems in the past.
>>
>> Curiously, there are two IOMMUs on the system.  I am not familiar enough
>> with Cougar Point chipsets to know how they are layed out.  Perhaps the
>> ACPI tables might have more information.
> I'm just curios, but where did you see two IOMMUs?

(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed

I added the iommu index into that loop because we found multi-socket
servers with multiple iommus, but I was not expecting to see two iommus
on a single socket workstation chipset.

>>
>> ACPI interaction with Xen is tricky at the best of times.  Xen as no AML
>> interpreter, so relies on Linux in dom0 to most of the ACPI legwork.
>>
>> My best guess at the moment is that something in the ACPI code for S5 is
>> turning off enough of the PCH that Xen can no longer talk to the one of
>> the IOMMUs.
>>
>> ~Andrew
>>


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