Re: Problems in PV dom0 on recent x86 hardware

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.07.2024 16:00, Andrew Cooper wrote:
> On 12/07/2024 2:46 pm, Juergen Gross wrote:
>> On 12.07.24 12:35, Jürgen Groß wrote:
>>> On 09.07.24 15:08, Jason Andryuk wrote:
>>>> After acpixtract & iasl:
>>>>
>>>> $ grep -ir FEEC *
>>>> dsdt.dsl:   OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
>>>> ssdt16.dsl: OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
>>>>
>>>>
>>>> from the DSDT:
>>>>      Scope (\_SB.PCI0.LPC0.EC0)
>>>>      {
>>>>          OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100)
>>>>          Field (ECMM, AnyAcc, Lock, Preserve)
>>>>          {
>>>>              TWBT,   2048
>>>>          }
>>>>
>>>>          Name (BTBF, Buffer (0x0100)
>>>>          {
>>>>               0x00                                             // .
>>>>          })
>>>>          Method (BTIF, 0, NotSerialized)
>>>>          {
>>>>              BTBF = TWBT /* \_SB_.PCI0.LPC0.EC0_.TWBT */
>>>>              Return (BTBF) /* \_SB_.PCI0.LPC0.EC0_.BTBF */
>>>>          }
>>>>      }
>>>>
>>>>  From SSDT16:
>>>> DefinitionBlock ("", "SSDT", 2, "LENOVO", "UsbCTabl", 0x00000001)
>>>> {
>>>>      External (_SB_.PCI0.LPC0.EC0_, DeviceObj)
>>>>
>>>>      Scope (\_SB)
>>>>      {
>>>>          OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30)
>>>>          Field (SUSC, ByteAcc, Lock, Preserve)
>>>>          {
>>>>
>>>>
>>>> This embedded controller (?) seems to live at 0xfeec2xxx.
>>>
>>> What is the takeaway from that?
>>>
>>> Is this a firmware bug (if yes, pointers to a specification saying that
>>> this is an illegal configuration would be nice), or do we need a way to
>>> map this page from dom0?
>>
>> I've found the following in the AMD IOMMU spec [1]:
>>
>>   Received DMA requests without PASID in the 0xFEEx_xxxx address range
>> are
>>   treated as MSI interrupts and are processed using interrupt
>> remapping rather
>>   than address translation.
>>
>> To me this sounds as if there wouldn't be a major risk letting dom0 map
>> physical addresses in this area, as long as "normal" I/Os to this area
>> would
>> result in DMA requests with a PASID. OTOH I'm not familiar with Xen IOMMU
>> handling, so I might be completely wrong.
>>
>> Another question would be whether a device having resources in this
>> area can
>> even work through an IOMMU.
> 
> Address spaces are not fully uniform.  What 0xFEEx_xxxx means/does
> really does differ depending on your point of view.
> 
> The CPU accessing 0xFEEx_xxxx literally does different things than a PCI
> device accessing the same range.
> 
> That's why nothing outside of the CPU can get at the LAPIC MMIO
> registers.  No amount of remapping trickery in the IOMMU pagetables are
> going to change this fact.
> 
> 
> Now - the problem here is that 0xFEEx_xxxx is (for legacy reasons)
> "known" to be the LAPIC MMIO, which has a 4k window at the bottom and
> everything else in the 2M is reserved.
> 
> And it appears that AMD have started putting other things into that
> reserved space, which are only described by AML, and not known to Xen. 

I wouldn't read it like that. The entire range (1M though, not 2M) is the
MSI window for everything non-CPU. They merely emphasize that, imo.

> Xen, generally, is very wary of mappings in and around here, because it
> does need to prevent even dom0 having access to the interrupt controller
> MMIO windows (I'm including IO-APICs too).
> 
> So I expect Xen is saying "that's an interrupt MMIO window, no" without
> knowing that there's actually something else in there.  (But I am just
> guessing.)

That's what we do, yes. At some point we did relax that for the IO-APIC
ranges (to permit Dom0 r/o access). If all else fails, we may need to do
the same for the problems here.

Jan