On Thu, Jun 22, 2023 at 03:28:14PM +0200, Jan Beulich wrote:
> > Unless I'm missing some non-obvious piece of the puzzle, I'd say that for a
> > truly general compressor we'd need some kind of loop over the hole mask.
>
> Well, further compression might be possible that way, yes, but that's
> enti
On 22.06.2023 14:39, Alejandro Vallejo wrote:
> On Thu, Jun 22, 2023 at 11:15:17AM +0200, Jan Beulich wrote:
> + * This is a technique to avoid wasting memory on machines known to have
> + * split their machine address space in two big discontinuous and highly
> + * disjoint chunks.
>>>
On Thu, Jun 22, 2023 at 11:15:17AM +0200, Jan Beulich wrote:
> >>> --- a/xen/include/xen/mm.h
> >>> +++ b/xen/include/xen/mm.h
> >>> @@ -31,6 +31,22 @@
> >>> * (i.e. all devices assigned to) a guest share a single DMA address
> >>> space
> >>> * and, by default, Xen will ensure dfn == pfn.
On 21.06.2023 16:25, Alejandro Vallejo wrote:
> On Mon, Jun 19, 2023 at 05:30:20PM +0200, Jan Beulich wrote:
>>> @@ -57,9 +99,25 @@ uint64_t __init pdx_init_mask(uint64_t base_addr)
>>> (uint64_t)1 << (MAX_ORDER + PAGE_SHIFT)) - 1);
>>> }
>>>
>>> -u64 __init pdx_region_
On Mon, Jun 19, 2023 at 05:30:20PM +0200, Jan Beulich wrote:
> > + * ma_{top,bottom}_mask is simply a shifted pfn_{top,pdx_bottom}_mask
> > where the
> > + * bottom one shifts in 1s rather than 0s.
> > + */
>
> Nit: That 2nd bottom variable is ma_va_bottom_mask.
Sure
>
> > @@ -57,9 +99,25 @@ ui
On 15.06.2023 18:27, Alejandro Vallejo wrote:
> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -20,13 +20,55 @@
> #include
> #include
>
> -/* Parameters for PFN/MADDR compression. */
> +/*
> + * Diagram to make sense of the following variables. The masks and shifts
> + * are done on mfn
Document the behaviour of the pdx machinery in Xen. Some logic is fairly
opaque and hard to follow without it being documented anywhere. This
explains the rationale behind compression and its relationship to
frametable indexing and directmap management.
While modifying the file:
* Convert u64 ->
