Re: [Xen-devel] [v7][RFC][PATCH 06/13] hvmloader/ram: check if guest memory is out of reserved device memory maps

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, November 20, 2014 4:04 PM
> 
> >>> On 20.11.14 at 08:45, <kevin.tian@xxxxxxxxx> wrote:
> > Yang and I did some discussion here. We understand your point to
> > avoid introducing new interface if we can leverage existing code.
> > However it's not a trivial effort to move device assignment before
> > populating p2m, and there is no other benefit of doing so except
> > for this purpose. So we'd not suggest this way.
> 
> "It's not a trivial effort" is pretty vague: What specifically is it that
> makes this difficult? I wouldn't expect there to be any strong
> dependencies on the ordering of these two operations...

I'll leave to Yang to answer this part, who did a detail investigation
on that, e.g. on IOMMU page table setup, etc. But what really matters
here is not only about complexity, but also flexibility. Doing so will 
tie the policy to assigned device only, which removes the option to
support hotpluggable device.

> 
> > Current option sounds a reasonable one, i.e. passing a list of BDFs
> > assigned to this VM before populating p2m, and then having
> > hypervisor to filter out reserved regions associated with those
> > BDFs. This way libxc teaches Xen to create reserved regions once,
> > and then later the filtered info is returned upon query.
> 
> Reasonable, but partly redundant. The positive aspect being that
> it permits this list and the list of actually being assigned devices to
> be different, i.e. allowing holes to be set up for devices that only
> _may_ get assigned at some point.

redundant if we think the list only exactly matching the statically 
assigned devices. but that's just current point.

reasonable if we think there may be other policies impacting the list
(e.g. if hotplugable device may have a config option and then we have
a potential list larger than static assigned devices). From this angle
I think the new interface actually makes sense for this very purpose.

> 
> > The limitation of wasted memory due to confliction can be
> > mitigated, and we considered further enhancement can be made
> > later in libxc that when populating p2m, the reserved regions
> > can be skipped explicitly at initial p2m creation phase and then
> > there would be no waste at all. But this optimization takes some
> > time and can be built incrementally on current patch and interface,
> > post 4.5 release. For now let's focus on the very correctness first.
> 
> I agree, as long as the optimization part doesn't get dropped after
> the correctness part went in.

definitely. after putting so much effort in last months from Tiejun, 
you can see our willingness to make it correct and continuously 
improved.

Thanks
Kevin

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