Re: [Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.04.17 at 10:58, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Apr 25, 2017 at 03:32:50AM -0600, Jan Beulich wrote:
>> >>> On 25.04.17 at 11:25, <roger.pau@xxxxxxxxxx> wrote:
>> > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote:
>> >> My understanding is BARs may be allocated by the kernel because the 
> firmware
>> >> didn't do it. This is the current case on ARM (and I guess x86) where 
>> >> Linux
>> >> will always go through the BARs.
>> > 
>> > No, on x86 BARs are allocated by the firmware. Linux or whatever OS will 
> scan
>> > the BARs in order to get it's position/size, but will not try to move them
>> > AFAIK.
>> 
>> That depends. Firmware is not required to set up all of them (only
>> such on devices needed for booting obviously need to be set up).
>> And Linux may (voluntarily or forced via command line option) still
>> move BARs.
> 
> The spec seems more strict here:
> 
> "Power-up software needs to build a consistent address map before booting the
> machine to an operating system. This means it has to determine how much memory
> is in the system, and how much address space the I/O controllers in the system
> require. After determining this information, power-up software can map the I/O
> controllers into reasonable locations and proceed with system boot."

I don't view this as more strict: Note how the last sentence says
"can map", not "has to" or "will". There are actually downsides to
firmware doing it for all devices: Firmware can't know whether the
OS is capable of dealing with 64-bit BARs, yet it is undesirable
(and perhaps impossible) to place all of them below 4Gb.

> Moving the BARs is not a huge problem, this series already allows the guest to
> move where the BARs are mapped in it's p2m, allowing a guest to set the 
> initial
> BAR position would also be feasible, but I haven't been able to find any 
> device
> on my boxes that's not initialized by the firmware, hence it would be hard for
> me to test that.

Well, you could zap some instead of mapping them into Dom0's p2m,
you'd just need to be careful not to zap any which Dom0 needs for
booting (in Linux this may be no more than the graphics card and, if
used, a plug-in serial card, as everything else ought to come from
the initrd).

Jan


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