Re: [Xen-devel] (v2) Design proposal for RMRR fix

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.01.15 at 10:36, <kevin.tian@xxxxxxxxx> wrote:
> We'll need to make that skeleton ready first. Then regarding to config 
> interface, how about making some simplification by only considering
> statically-assigned device and hotplug now (leaving migration to future 
> based on necessity, and extending that doesn't change low level skeleton)?
> 
> pci option can be extended as:
>       pci = [ 'bdf, rmrr_check=force/try' ]
> domain_create queries Xen hypervisor about RMRRs associated with
> assigned devices, and then mark each region with user specified override. 
> 
> User can also specify a rmrr_host option as:
>       rmrr = [ 'host, check=force/try' ]
> when rmrr_host is specified, domain_create queries all RMRRs reported
> in this platform, and mark per-region policy accordingly. 
> 
> per-device override is always favored if a conflicting setting in rmrr_host.
>  
> The composed reserved region list is then passed to domain builder,
> which tries to detect and avoid conflicts when populating guest RAM.
> To avoid breaking lowmem/highmem layout, we can define a 
> lowmem_guard so if making hole for a region would make lowmem_top
> below lowmem_guard we'll treat this region as a conflict. We may
> either just hardcode the value like 2G (or other reasonable value in your
> mind), or allow user to config e.g.:
>       rmrr = [ 'host, check=force/try', 'lowmem_boundary=2G' ]

To me it looks like lowmem_boundary makes sense only when
check=try.

> after domain builder, libxl will request actual device assignment to
> Xen hypervisor. At that point, current assignment hypercall needs
> to be extended to include the override value, so Xen will handle
> conflict accordingly when setting up identity map.
> 
> last step is in hvmloader, which is passed with all the necessary RMRR
> information, and then handles potential conflicts accordingly.
> 
> In the future when we think necessary to allow user specify random
> regions for migration usage, it can be easily extended and we can
> argue whether to introduce same override.
> 
> If above high level flow can be agreed, then we can move forward to
> discuss next level detail e.g. how to pass the rmrr list cross different
> components. :-)

Apart from the minor detail mentioned I think the above is a good
representation of what we want/need.

Jan


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