[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> From: George Dunlap
> Sent: Friday, January 09, 2015 12:00 AM
> >>>>>3.3 Policies
> >> ----
> >> An intuitive thought is to fail immediately upon a confliction, however
> >> it is not flexible regarding to different requirments:
> >>
> >> a) it's not appropriate to fail libxc domain builder just because such
> >> confliction. We still want the guest to boot even w/o assigned device;
> >
> > I don't think that's right (and I believe this was discussed before):
> > When device assignment fails, VM creation should fail too. It is the
> > responsibility of the host admin in that case to remove some or all
> > of the to be assigned devices from the guest config.
> Yes; basically, if we get to domain build time and we haven't reserved
> the RMRRs, then it's a bug in libxl (since it's apparently told Xen
> one thing and libxc another thing).  Having libxc fail in that case is
> a perfectly sensible thing to do.

I'd like a way either throwing warning and then move forward, or just fails 
the device assignment (i.e. not exposing to guest) instead of failing the 
whole guest, to mimic native behavior.

> >> We propose report-all as the simple solution (different from last sent
> >> version which used report-sel), regarding to the below facts:
> >>
> >>   - 'warn' policy in user space makes report-all not harmful
> >>   - 'report-all' still means only a few entries in reality:
> >>     * RMRR reserved regions should be avoided or limited by platform
> >> designers, per VT-d specification;
> >>     * RMRR reserved regions are only a few on real platforms, per our
> >> current observations;
> >
> > Few yes, but in the IGD example you gave the region is quite large,
> > and it would be fairly odd to have all guests have a strange, large
> > hole in their address spaces. Furthermore remember that these
> > holes vary from machine to machine, so a migrateable guest would
> > needlessly end up having a hole potentially not helping subsequent
> > hotplug at all.
> Yes, I think that by default VMs should have no RMRRs set up on domain
> creation.  The only way to get RMRRs in your address space should be
> to opt-in at domain creation time (either by statically assigning
> devices, or by requesting your memory layout to mirror the host's).

ideally yes, but I'm thinking how bad it is to create some unnecessary
holes compared to the complexity of accurate control.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.