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: Tian, Kevin
> Sent: Thursday, November 20, 2014 4:51 PM
> 
> > 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.
> 

Jan are you OK with this? In previous approach we reserved all the
RMRR regions so hotplug scenario is covered automatically. Now since
we want to do BDF specific filtering, this new interface is actually
necessary for hotplug support. If OK, Tiejun will send out a new 
series to see whether it's ready for 4.5 check-in.

Thanks
Kevin

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