Re: PVH dom0 creation fails - the system freezes

[<bercarug@amazon.com>]

On 08/08/2018 11:51 AM, Roger Pau Monné wrote:
> On Wed, Aug 08, 2018 at 09:43:39AM +0100, Paul Durrant wrote:
>>> -----Original Message-----
>>> From: Roger Pau Monne
>>> Sent: 08 August 2018 09:08
>>> To: bercarug@amazon.com
>>> Cc: Paul Durrant <Paul.Durrant@citrix.com>; xen-devel <xen-
>>> devel@lists.xenproject.org>; David Woodhouse <dwmw2@infradead.org>;
>>> Jan Beulich <JBeulich@suse.com>; Belgun, Adrian <abelgun@amazon.com>
>>> Subject: Re: [Xen-devel] PVH dom0 creation fails - the system freezes
>>>
>>> On Wed, Aug 08, 2018 at 10:46:40AM +0300, bercarug@amazon.com wrote:
>>>> On 08/02/2018 04:55 PM, Roger Pau Monné wrote:
>>>>> Please try to avoid top posting.
>>>>>
>>>>> On Thu, Aug 02, 2018 at 11:36:26AM +0000, Bercaru, Gabriel wrote:
>>>>>> I applied the match mentioned, but the system fails to boot. Instead, it
>>>>>> drops to a BusyBox shell. It seems to be a file system issue.
>>>>> So you have applied 173c7803592065d27bf2e60d50e08e197a0efa83 and it
>>>>> causes a regression for you?
>>>>>
>>>>> As I understand it, before applying 173c780359206 you where capable of
>>>>> booting the PVH Dom0, albeit with non-working USB?
>>>>>
>>>>> And after applying 173c780359206 you are no longer able to boot?
>>>> Right, after applying 173c780359206 the system fails to boot (it drops to
>>>> the BusyBox shell).
>>>>>> Following is a sequence of the boot log regarding the file system issue.
>>>>> At least part of the issue seems to be that the IO-APIC information
>>>>> provided to Dom0 is wrong (from the attached log):
>>>>>
>>>>> [    0.000000] IOAPIC[0]: apic_id 2, version 152, address 0xfec00000, GSI 0-
>>> 0
>>>>> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
>>>>> [    0.000000] Failed to find ioapic for gsi : 2
>>>>> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
>>>>> [    0.000000] Failed to find ioapic for gsi : 9
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 1
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 2
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 3
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 4
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 5
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 6
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 7
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 8
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 9
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 10
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 11
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 12
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 13
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 14
>>>>> [    0.000000] ERROR: Unable to locate IOAPIC for GSI 15
>>>>>
>>>>> Can you try to boot with just the staging branch (current commit is
>>>>> 008a8fb249b9d433) and see how that goes?
>>>>>
>>>>> Thanks, Roger.
>>>>>
>>>> I recompiled Xen using the staging branch, commit 008a8fb249b9d433 and
>>> the
>>>> system boots,
>>> OK, so your issues where not caused by 173c780359206 then?
>>>
>>> 008a8fb249b9d433 already contains 173c780359206 because it was
>>> committed earlier. In any case it's good to know you are able to boot
>>> (albeit with issues) using the current staging branch.
>>>
>>>> however the USB problem persists. I was able to log in using the serial port
>>>> and after executing
>>> Yes, the fixes for this issue have not been committed yet, see:
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2018-
>>> 08/msg00528.html
>>>
>>> If you want you can give this branch a try, it should hopefully solve
>>> your USB issues.
>>>
>>>> "xl list -l" the memory decrease problem appeared.
>>> Yup, I will look into this now in order to find some kind of
>>> workaround.
>>>
>>>> I attached the boot log. Following are some lines extracted from the log,
>>>> regarding the USB
>>>>
>>>> devices problem:
>>>>
>>>> [    5.864084] usb 1-1: device descriptor read/64, error -71
>>>>
>>>> [    7.564025] usb 1-1: new full-speed USB device number 4 using xhci_hcd
>>>> [    7.571347] usb 1-1: Device not responding to setup address.
>>>>
>>>> [    8.008031] usb 1-1: device not accepting address 4, error -71
>>>>
>>>> [    8.609623] usb 1-1: device not accepting address 5, error -71
>>>>
>>>>
>>>> At the beginning of the log, there is a message regarding
>>>> iommu_inclusive_mapping:
>>>>
>>>>
>>>> (XEN) [VT-D]found ACPI_DMAR_RMRR:
>>>> (XEN) [VT-D]  RMRR address range 3e2e0000..3e2fffff not in reserved
>>> memory;
>>>> need "iommu_inclusive_mapping=1"?
>>>> (XEN) [VT-D] endpoint: 0000:00:14.0
>>>>
>>>>
>>>> I mention that I tried to boot again using this command line option, but
>>>> this message and the
>>>>
>>>> USB messages persist.
> Does USB work despite of the warning message?
No, it does not.
>
>>> Yes, iommu_inclusive_mapping doesn't work for PVH, that's what my
>>> patch series is trying to address. The error is caused by
>>> missing/wrong RMRR regions in the ACPI tables.
>>>
>> Looks like this warning is suggesting that there is an RMRR that falls outside of an E820 reserved region. For PV I guess that 'inclusive' will fix this, but for PVH 'reserved' isn't going to fix it. I hope that the range at least falls in a hole, so maybe we also need a dom0_iommu=holes option too? Ugly, but maybe necessary.
> I wanted to avoid adding such option because I think it's going to
> interact quite badly with BAR mappings.
>
> Maybe it would make sense to add RMRR regions as long as they don't
> reside in a RAM region and just print the warning message?
>
> As a side note, it would be good that you report this to the vendor,
> the firmware they are providing is broken and should be fixed.
>
> Thanks, Roger.





Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel