IOMMU initialization failure when using linux-as-bootloader

IOMMU initialization failure when using linux-as-bootloader

[Sylvain Munaut]

Hello,


I'm trying to use "linux as a bootloader", i.e. kexec into Xen 4.7 and
I've been struggling for the past week. I've been able to debug and
fix some issues on my own ( ELF header issue, invalid BDA entries,
some kexec-tools bugs, ...) but I've been stuck on this one with no
idea how to even debug it.

Basically what I'm getting now is :

(XEN) DMAR_IQA_REG = 47ad78002
(XEN) DMAR_IQH_REG = 440
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************

If I try with iommu=off, then xen actually loads the dom0 kernel but
it fails with various IO errors and not managing to access the drives,
USB and so on. So obviously something is not quite initialized right,
but I have no idea what.

I should also not that kexec'ing into the dom0 kernel directly,
without xen, works just fine.

Does anyone have any clue what could be going on, or what I could do next ?

Below is the full xen serial console output. And you can also find a
diff of a native (from grub) boot vs a kexec one :
http://pastebin.com/M3X2ZvPx

If you need more info, please ask, I can test or post more details if needed.


Cheers,

   Sylvain Munaut




(XEN) Xen version 4.7.0 (whatever@dev.office.whatever-company.com)
(gcc (Debian 4.9.2-10) 4.9.2) debug=n Fri Aug 26 09:07:38 UTC 2016
(XEN) Latest ChangeSet:
(XEN) Bootloader: kexec 2.0.13
(XEN) Command line: loglvl=all guest_loglvl=all noreboot=true
console=com2 no-real-mode edd=off iommu_dev_iotlb_timeout=5000
iommu_inclusive_mapping=1 iommu=verbose,debug
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Multiboot-e820 RAM map:
(XEN)  0000000000000100 - 000000000009ac00 (usable)
(XEN)  000000000009ac00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000796f0000 (usable)
(XEN)  00000000796f0000 - 00000000798bf000 (reserved)
(XEN)  00000000798bf000 - 00000000799b8000 (usable)
(XEN)  00000000799b8000 - 000000007bdb1000 (reserved)
(XEN)  000000007bdb1000 - 000000007bdb2000 (usable)
(XEN)  000000007bdb2000 - 000000007be38000 (reserved)
(XEN)  000000007be38000 - 000000007c000000 (usable)
(XEN)  0000000080000000 - 0000000090000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000480000000 (usable)
(XEN) ACPI: RSDP 000F0580, 0024 (r2 SUPERM)
(XEN) ACPI: XSDT 79A000A0, 00BC (r1 SUPERM SMCI--MB  1072009 AMI     10013)
(XEN) ACPI: FACP 79A17EC0, 010C (r5 SUPERM SMCI--MB  1072009 AMI     10013)
(XEN) ACPI: DSDT 79A001F0, 17CCE (r2 SUPERM SMCI--MB  1072009 INTL 20091013)
(XEN) ACPI: FACS 79E59F80, 0040
(XEN) ACPI: APIC 79A17FD0, 00C8 (r3 SUPERM SMCI--MB  1072009 AMI     10013)
(XEN) ACPI: FPDT 79A18098, 0044 (r1 SUPERM SMCI--MB  1072009 AMI     10013)
(XEN) ACPI: FIDT 79A180E0, 009C (r1 SUPERM SMCI--MB  1072009 AMI     10013)
(XEN) ACPI: SPMI 79A18180, 0040 (r5 SUPERM SMCI--MB        0 AMI.        0)
(XEN) ACPI: MCFG 79A181C0, 003C (r1 SUPERM SMCI--MB  1072009 MSFT       97)
(XEN) ACPI: UEFI 79A18200, 0042 (r1                        0             0)
(XEN) ACPI: DBG2 79A18248, 0072 (r0 SUPERM SMCI--MB        0 INTL 20091013)
(XEN) ACPI: HPET 79A182C0, 0038 (r1 SUPERM SMCI--MB        1 INTL 20091013)
(XEN) ACPI: WDDT 79A182F8, 0040 (r1 SUPERM SMCI--MB        0 INTL 20091013)
(XEN) ACPI: SSDT 79A18338, ED8B (r1    AMI    PmMgt        1 INTL 20120913)
(XEN) ACPI: SSDT 79A270C8, 2285 (r2 SUPERM SpsNm           2 INTL 20120913)
(XEN) ACPI: SSDT 79A29350, 0064 (r2 SUPERM SpsNvs          2 INTL 20120913)
(XEN) ACPI: PRAD 79A293B8, 0102 (r2 SUPERM SMCI--MB        2 INTL 20120913)
(XEN) ACPI: DMAR 79A294C0, 00D4 (r1 SUPERM SMCI--MB        1 INTL 20091013)
(XEN) ACPI: HEST 79A29598, 00A8 (r1 SUPERM SMCI--MB        1 INTL        1)
(XEN) ACPI: BERT 79A29640, 0030 (r1 SUPERM SMCI--MB        1 INTL        1)
(XEN) ACPI: ERST 79A29670, 0230 (r1 SUPERM SMCI--MB        1 INTL        1)
(XEN) ACPI: EINJ 79A298A0, 0130 (r1 SUPERM SMCI--MB        1 INTL        1)
(XEN) System RAM: 16281MB (16672048kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000480000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fd9b0
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT -
79e59f80/0000000000000000, using 32
(XEN) ACPI:             wakeup_vec[79e59f8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high level lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high level lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x09] address[0xfec01000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 9, version 32, address 0xfec01000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000
(XEN) [VT-D]Host address width 46
(XEN) [VT-D]found ACPI_DMAR_DRHD:
(XEN) [VT-D]  dmaru->address = fbffc000
(XEN) [VT-D]drhd->address = fbffc000 iommu->reg = ffff82c000201000
(XEN) [VT-D]cap = 8d2078c106f0466 ecap = f020de
(XEN) [VT-D] IOAPIC: 0000:f0:1f.7
(XEN) [VT-D] IOAPIC: 0000:00:05.4
(XEN) [VT-D] MSI HPET: 0000:f0:0f.0
(XEN) [VT-D]  flags: INCLUDE_ALL
(XEN) [VT-D]found ACPI_DMAR_RMRR:
(XEN) [VT-D] endpoint: 0000:00:14.0
(XEN) [VT-D] endpoint: 0000:00:1a.0
(XEN) [VT-D] endpoint: 0000:00:1d.0
(XEN) [VT-D]  RMRR region: base_addr 7bb24000 end_address 7bb32fff
(XEN) [VT-D]found ACPI_DMAR_ATSR:
(XEN) [VT-D]  atsru->all_ports: 0
(XEN) [VT-D] bridge: 0000:00:01.0 start=0 sec=1 sub=1
(XEN) [VT-D] bridge: 0000:00:01.1 start=0 sec=2 sub=2
(XEN) [VT-D] bridge: 0000:00:02.0 start=0 sec=3 sub=3
(XEN) [VT-D] bridge: 0000:00:02.2 start=0 sec=4 sub=5
(XEN) [VT-D] bridge: 0000:00:03.0 start=0 sec=6 sub=6
(XEN) [VT-D] bridge: 0000:00:03.2 start=0 sec=7 sub=7
(XEN) [VT-D]found ACPI_DMAR_RHSA:
(XEN) [VT-D]  rhsau->address: fbffc000 rhsau->proximity_domain: 0
(XEN) Xen ERST support is initialized.
(XEN) HEST: Table parsing has been initialized
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 1504 MSI/MSI-X
(XEN) Not enabling x2APIC (upon firmware request)
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) CPU0 CMCI LVT vector (0xf9) already installed
(XEN) Thermal LVT vector (0xfa) already installed
(XEN) Intel machine check reporting enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2200.039 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table ffff82d0802b3890 -> ffff82d0802b4e08
(XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buses 00 - ff
(XEN) PCI: MCFG area at 80000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-ff
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control 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 Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) DMAR_IQA_REG = 47ad78002
(XEN) DMAR_IQH_REG = 440
(XEN) DMAR_IQT_REG = 20
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)

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

Re: IOMMU initialization failure when using linux-as-bootloader

[Andrew Cooper]

On 26/08/16 10:57, Sylvain Munaut wrote:
> Hello,
>
>
> I'm trying to use "linux as a bootloader", i.e. kexec into Xen 4.7 and
> I've been struggling for the past week. I've been able to debug and
> fix some issues on my own ( ELF header issue, invalid BDA entries,
> some kexec-tools bugs, ...) but I've been stuck on this one with no
> idea how to even debug it.
>
> Basically what I'm getting now is :
>
> (XEN) DMAR_IQA_REG = 47ad78002
> (XEN) DMAR_IQH_REG = 440
> (XEN) DMAR_IQT_REG = 20
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) queue invalidate wait descriptor was not executed
> (XEN) ****************************************
>
> If I try with iommu=off, then xen actually loads the dom0 kernel but
> it fails with various IO errors and not managing to access the drives,
> USB and so on. So obviously something is not quite initialized right,
> but I have no idea what.
>
> I should also not that kexec'ing into the dom0 kernel directly,
> without xen, works just fine.
>
> Does anyone have any clue what could be going on, or what I could do next ?

We gave a queued invalidation request to the IOMMU, and it didn't respond.

Given the position in the log, this is likely the very first time we 
have tried interacting with the IOMMU, and given the fact you used kexec 
to get here, it is likely that it is already set up from Linux's use.

It is probably something like we aren't resetting it, and either 
interacting with it in a mismatch between polled or interrupt mode, or 
that it has interrupts set up and they are going to an unexpected location.

>
> Below is the full xen serial console output. And you can also find a
> diff of a native (from grub) boot vs a kexec one :
> http://pastebin.com/M3X2ZvPx
>
> If you need more info, please ask, I can test or post more details if needed.
>
>
> Cheers,
>
>     Sylvain Munaut
>
>
>
>
> (XEN) Xen version 4.7.0 (whatever@dev.office.whatever-company.com)
> (gcc (Debian 4.9.2-10) 4.9.2) debug=n Fri Aug 26 09:07:38 UTC 2016

Please always  use a debug version of Xen to develop with.

~Andrew

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

Re: IOMMU initialization failure when using linux-as-bootloader

[Sylvain Munaut]

Hi,

>> (XEN) DMAR_IQA_REG = 47ad78002
>> (XEN) DMAR_IQH_REG = 440
>> (XEN) DMAR_IQT_REG = 20
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) queue invalidate wait descriptor was not executed
>> (XEN) ****************************************
>>
>
> We gave a queued invalidation request to the IOMMU, and it didn't respond.
>
> Given the position in the log, this is likely the very first time we have
> tried interacting with the IOMMU, and given the fact you used kexec to get
> here, it is likely that it is already set up from Linux's use.
>
> It is probably something like we aren't resetting it, and either interacting
> with it in a mismatch between polled or interrupt mode, or that it has
> interrupts set up and they are going to an unexpected location.

Ah, thanks for the hint.

I tried to boot the first stage using intremap=off to prevent it from
using interrupt remapping and that seemed to work around the issue !

I had a quick look into the xen code and I could see two path that
enable interrupt remapping :
 - Through iommu_enable_x2apic_IR
 - Through init_vtd_hw

In the first path, Xen will force disable interrupt remapping and
queued invalidation in case the BIOS had them on and then will
re-initialize them properly.
In the second path, Xen doesn't seem to do that.

And presumably in my system the second path is taken because the BIOS
opts-out of x2APIC according to the linux boot messages.

So I tried to just do the same pre-cleanup in init_vtd_hw than in
iommu_enable_x2apic_IR (see diff below) and this seemed to work just
fine.

I'll test this in more detail next week to make sure things really
work as expected (atm I'm just testing if dom0 boots properly). And if
things turn OK and you think this is a proper fix for the issue and
safe to apply, I can send the patch properly to the list.


Cheers,

    Sylvain Munaut

-----

diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 48f120b..5f79609 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2102,6 +2102,9 @@ static int __must_check init_vtd_hw(void)

         clear_fault_bits(iommu);

+        disable_intremap(iommu);
+        disable_qinval(iommu);
+
         spin_lock_irqsave(&iommu->register_lock, flags);
         sts = dmar_readl(iommu->reg, DMAR_FECTL_REG);
         sts &= ~DMA_FECTL_IM;

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

Re: IOMMU initialization failure when using linux-as-bootloader

[Jan Beulich]

>>> On 27.08.16 at 12:40, <s.munaut@whatever-company.com> wrote:
> I'll test this in more detail next week to make sure things really
> work as expected (atm I'm just testing if dom0 boots properly). And if
> things turn OK and you think this is a proper fix for the issue and
> safe to apply, I can send the patch properly to the list.

I think this is reasonable, despite it certainly being unexpected for
the BIOS to turn such on when not putting the system into x2APIC
mode. Considering you're not talking about a BIOS here, may I
nevertheless ask why it's not instead Linux/kexec which get fixed
to not leave these features enabled before handing off control?

Jan

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2102,6 +2102,9 @@ static int __must_check init_vtd_hw(void)
> 
>          clear_fault_bits(iommu);
> 
> +        disable_intremap(iommu);
> +        disable_qinval(iommu);
> +
>          spin_lock_irqsave(&iommu->register_lock, flags);
>          sts = dmar_readl(iommu->reg, DMAR_FECTL_REG);
>          sts &= ~DMA_FECTL_IM;



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

Re: IOMMU initialization failure when using linux-as-bootloader

[Sylvain Munaut]

Hi Jan,


> I think this is reasonable, despite it certainly being unexpected for
> the BIOS to turn such on when not putting the system into x2APIC
> mode.

It seems that linux doesn't use x2APIC because the BIOS explicitly
"opts out" of it :

"DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit."


> Considering you're not talking about a BIOS here, may I
> nevertheless ask why it's not instead Linux/kexec which get fixed
> to not leave these features enabled before handing off control?

I think both should be done.

Xen should tolerate that case and not assume that if it's enabled it's
been enabled by Xen.
Especially since that "pre-cleanup" already exists in one path and not
the other.

But the kernel should definitely clean up as much as possible after
itself before reboot.
I've actually been looking into that this morning but didn't come up
with a solution yet.

The Xen case was easy because I just had to copy the missing calls
from one codepath to the other, for the linux path I'm still looking
how & where to do that. If I'm still no closer to an answer by
tomorrow, I'll ask on the kexec mailing list if anyone has any
suggestion.


Cheers,

    Sylvain

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

Re: IOMMU initialization failure when using linux-as-bootloader

[Jan Beulich]

>>> On 29.08.16 at 14:00, <s.munaut@whatever-company.com> wrote:
>> I think this is reasonable, despite it certainly being unexpected for
>> the BIOS to turn such on when not putting the system into x2APIC
>> mode.
> 
> It seems that linux doesn't use x2APIC because the BIOS explicitly
> "opts out" of it :
> 
> "DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit."

Note the "not" in my earlier reply. Or otherwise I don't understand
what you're trying to tell me.

>> Considering you're not talking about a BIOS here, may I
>> nevertheless ask why it's not instead Linux/kexec which get fixed
>> to not leave these features enabled before handing off control?
> 
> I think both should be done.
> 
> Xen should tolerate that case and not assume that if it's enabled it's
> been enabled by Xen.

That's debatable, but as said, your draft patch looks reasonable.
The problem here is that (as so many things in this area) what
state a kernel is allowed to expect the system to be in when
handled control for the first time.

> Especially since that "pre-cleanup" already exists in one path and not
> the other.

On that other path it's a requirement, since firmware can indeed
be expected to turn on interrupt remapping when coming up in
x2APIC mode. Plus ...

> But the kernel should definitely clean up as much as possible after
> itself before reboot.
> I've actually been looking into that this morning but didn't come up
> with a solution yet.
> 
> The Xen case was easy because I just had to copy the missing calls
> from one codepath to the other, for the linux path I'm still looking
> how & where to do that. If I'm still no closer to an answer by
> tomorrow, I'll ask on the kexec mailing list if anyone has any
> suggestion.

... this makes clear that you're acting phenomenologically. For us
to be safe in this regard, however, it would require that we put
back into a clean state _everything_ that the firmware (or Linux in
your present case) may have (pre-)initialized.

Jan


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

Re: IOMMU initialization failure when using linux-as-bootloader

[Andrew Cooper]

On 29/08/16 13:45, Jan Beulich wrote:
>>>> On 29.08.16 at 14:00, <s.munaut@whatever-company.com> wrote:
>>> I think this is reasonable, despite it certainly being unexpected for
>>> the BIOS to turn such on when not putting the system into x2APIC
>>> mode.
>> It seems that linux doesn't use x2APIC because the BIOS explicitly
>> "opts out" of it :
>>
>> "DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit."
> Note the "not" in my earlier reply. Or otherwise I don't understand
> what you're trying to tell me.
>
>>> Considering you're not talking about a BIOS here, may I
>>> nevertheless ask why it's not instead Linux/kexec which get fixed
>>> to not leave these features enabled before handing off control?
>> I think both should be done.
>>
>> Xen should tolerate that case and not assume that if it's enabled it's
>> been enabled by Xen.
> That's debatable, but as said, your draft patch looks reasonable.
> The problem here is that (as so many things in this area) what
> state a kernel is allowed to expect the system to be in when
> handled control for the first time.
>
>> Especially since that "pre-cleanup" already exists in one path and not
>> the other.
> On that other path it's a requirement, since firmware can indeed
> be expected to turn on interrupt remapping when coming up in
> x2APIC mode. Plus ...
>
>> But the kernel should definitely clean up as much as possible after
>> itself before reboot.
>> I've actually been looking into that this morning but didn't come up
>> with a solution yet.
>>
>> The Xen case was easy because I just had to copy the missing calls
>> from one codepath to the other, for the linux path I'm still looking
>> how & where to do that. If I'm still no closer to an answer by
>> tomorrow, I'll ask on the kexec mailing list if anyone has any
>> suggestion.
> ... this makes clear that you're acting phenomenologically. For us
> to be safe in this regard, however, it would require that we put
> back into a clean state _everything_ that the firmware (or Linux in
> your present case) may have (pre-)initialized.

Kexec + IOMMU is a complicated problem.

Simply disabling DMA/Interrupt remapping while outstanding actions are
ongoing is a surefire recipe for memory corruption.

Linux takes the approach that it is safer to leave the IOMMU in its
present state, than to try altering it, as the kexec kernel is in a
better position to re-initalise things.

This is an area which I would like to improve in Xen as well, but it is
complicated by the fact that lots of older Linux kernels won't tolerate
being entered with IOMMU remapping still active.

~Andrew

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