Re: [Xen-devel] IOMMU initialization failure when using linux-as-bootloader

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/08/16 13:45, Jan Beulich wrote:
>>>> On 29.08.16 at 14:00, <s.munaut@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel