Re: [Xen-devel] [PATCH v2 4/4] x86: fix pinned cache attribute handling

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Fri, 2014-03-28 at 13:27 +0000, Jan Beulich wrote:
> >>> On 28.03.14 at 14:19, <JBeulich@xxxxxxxx> wrote:
> > - make sure UC- is only used for PAT purposes (MTRRs and hence EPT
> >   don't have this type)
> > - add order input to "get", and properly handle conflict case (forcing
> >   an EPT page split)
> > - properly detect (and refuse) overlaps during "set"
> > - properly use RCU constructs
> > - support deleting ranges through a special type input to "set"
> > - set ignore-PAT flag in epte_get_entry_emt() when "get" succeeds
> > - set "get" output to ~0 (invalid) rather than 0 (UC) on error (the
> >   caller shouldn't be looking at it anyway)
> > - move struct hvm_mem_pinned_cacheattr_range from header to C file
> >   (used only there)
> > 
> > Note that the code (before and after this change) implies the GFN
> > ranges passed to the hypercall to be inclusive, which is in contrast
> > to the sole current user in qemu (all variants). It is not clear to me
> > at which layer (qemu, libxc, hypervisor) this would best be fixed.
> 
> Actually I think I should point you guys more explicitly at the above
> (forgot to Cc you when sending the patch).

This is about XEN_DOMCTL_pin_mem_cacheattr?

Is it the case that we are failing to set the cacheattrs of the last
page in the range?

I think it is generally better if libxc remains a pretty thin layer over
the hypercall, so adjustments to the inclusiveness of the arguments
don't really belong there IMHO.

What is considered more normal for our hypercall interfaces, in- or
exclusive?

For the cacheflush thing I added recently you suggested to use a nrpages
instead of end which nicely sidestepped the issue. Is that an option
here while you are changing things anyway?

Ian.


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