Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> >IMO a single entity should be in control of the memory layout, and
> >that's the toolstack.
> >
> >Ideally we should not allow the firmware to change the layout at all.
> 
> This approach is terribly wrong, I don't know why opinions like this
> so common at Citrix. The toolstack is a least informed side. If
> MMIO/memory layout should be immutable, it must be calculated
> considering all factors, like chipset-specific MMIO ranges or ranges
> which cannot be used for the MMIO hole.
> 

Why is this approach wrong? Code running in the guest is non-privileged and we 
really don't want it messing around with memory layout. We really want to be in 
a position to e.g. build ACPI tables in the toolstack and we cannot do this 
until the layout becomes immutable.

> We need to know all resource requirements of device-model's and PT
> PCI devices, all chipset-specific MMIO ranges (which belong to a device
> model), all RMRRs (host's property) and all device-model invisible
> ranges like VRAM backing store (another device model's property).

Yes, indeed we do.

> And we need to know in which manner hvmloader will be allocating BARs
> to the MMIO hole -- eg. either in a forward direction starting from some
> base or moving backwards from the end of 4Gb (minus hardcoded ranges).

Eventually we want to get rid of hvmloader. Why do we need to know anything 
about its enumeration of BARs? After all they could be completely re-enumerated 
by the guest OS during or after boot (and indeed Windows does precisely that).

> Basically this means that we have to depend on hvmloader code/version
> too in the toolstack, which is wrong on its own -- we should have a
> freedom to modify the BAR allocation algo in hvmloader at any time.
> 

It should be irrelevant. The toolstack should decide on the sizes and locations 
of the MMIO holes and they should remain fixed, and be enforced by Xen. This 
avoids issues that we currently have such as guests populating RAM inside MMIO 
holes.

  Paul

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