Re: [Xen-devel] [PATCH 1/6] xen: extend XEN_DOMCTL_memory_mapping to handle cacheability

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.02.19 at 00:07, <sstabellini@xxxxxxxxxx> wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq {
>  */
>  #define DPCI_ADD_MAPPING         1
>  #define DPCI_REMOVE_MAPPING      0
> +#define CACHEABILITY_DEVMEM      0 /* device memory, the default */
> +#define CACHEABILITY_MEMORY      1 /* normal memory */
>  struct xen_domctl_memory_mapping {
>      uint64_aligned_t first_gfn; /* first page (hvm guest phys page) in range 
> */
>      uint64_aligned_t first_mfn; /* first page (machine page) in range */
>      uint64_aligned_t nr_mfns;   /* number of pages in range (>0) */
>      uint32_t add_mapping;       /* add or remove mapping */
> -    uint32_t padding;           /* padding for 64-bit aligned structure */
> +    uint32_t cache_policy;      /* cacheability of the memory mapping */
>  };

I don't think DEVMEM and MEMORY are anywhere near descriptive
enough, nor - if we want such control anyway - flexible enough. I
think what you want is to actually specify cachability, allowing on
x86 to e.g. map frame buffers or alike WC. The attribute then
would (obviously and necessarily) be architecture specific.

In vPCI code the question then will become whether prefetchable
BARs shouldn't be mapped e.g. WT instead of UC (and whatever
the Arm equivalent is, assuming PCI support will eventually get
added to Arm64, as it seems it has been the intention for quite
some time).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel