Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

[Alexey G <x1917x@xxxxxxxxx>]

On Thu, 3 May 2018 15:02:36 +0100
Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:

>On Thu, May 03, 2018 at 10:02:47PM +1000, Alexey G wrote:
>> On Thu, 3 May 2018 12:15:18 +0100
>> Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>   
>> >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote:  
>> >> On Thu, 3 May 2018 10:56:40 +0100
>> >> Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote:
>> >>     
>> >> >When running as PVH Dom0 the native memory map is used in order
>> >> >to craft a tailored memory map for Dom0 taking into account it's
>> >> >memory limit.
>> >> >
>> >> >Dom0 memory is always going to be smaller than the total amount
>> >> >of memory present on the host, so in order to prevent Dom0 from
>> >> >relocating PCI BARs over RAM regions mark all the RAM regions not
>> >> >available to Dom0 as RESERVED in the memory map.
>> >> >---
>> >> >NB: I haven't seen any system where Dom0 would relocate the BARs
>> >> >over RAM regions, but AFAICT given the current memory map
>> >> >provided to Dom0 this is a possibility that should be
>> >> >avoided.    
>> >> 
>> >> Guest OSes typically use information from ACPI to learn where PCI
>> >> BARs can (or cannot) be relocated.    
>> >
>> >I think it's better to be safe than sorry, so IMO the host RAM
>> >regions should be added to the memory map as RESERVED.
>> >
>> >Roger.  
>> 
>> I assume host's DSDT passed through to PVH Dom0 as is? In this case
>> Dom0 will see PCI holes matching those of the host and shouldn't make
>> any attempts to place BARs outside provided PCI holes (except "nocrs"
>> given).
>> 
>> As long as Dom0 P2M map prevent using these host ranges we shouldn't
>> worry if it is marked as reserved in e820 map I think. It's kinda
>> excessive information for Dom0 -- knowing about host RAM ranges which
>> he cannot touch anyway due to lack of corresponding p2m mappings.  
>
>Dom0 could attempt to relocate a BAR over a RAM region and Xen won't
>prevent it, because Dom0 is trusted. The same could happen with a PV
>Dom0, but in the PV case Dom0 is provided with the unmodified host
>memory map.
>

In worst case the physical device won't work if it will be relocated
outside the host MMIO hole -- the system won't decode accesses to it.
If the reason just to tell dom0 allowable limits where PCI MMIO BARs can
be safely relocated without breaking their decoding -- then _CRS should
have priority over e820 map as it is the primary source of MMIO hole
information on ACPI-capable systems. Anyway, this patch might be useful
in situations like running kernel with nocrs/noacpi to workaround some
platform issues.

Other than that, there should be no critical issues due to PCI BAR
relocation over host RAM. Dom0 can't just create some arbitrary mapping
to host memory if it doesn't belong to any running domain. Even
attempting to map host RAM to dom0 as MMIO won't work IIRC -- p2m/mm
code will prohibit this. Don't remember the exact reason, but AFAIR it
should complain about wannabe-MMIO ranges not belonging to dom_io,
something like that. So there will be no corresponding p2m mappings
available for dom0 to gain access to host RAM ranges where relocated
BARs point, even if dom0 can control these BARs.

>I don't see how providing this UNUSABLE/RESERVED ranges is going to
>cause any issues to Dom0, so I think we should just do it.
>
>Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel