Re: [PATCH v8 11/16] x86/virt/tdx: Designate reserved areas for all TDMRs

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

 



On 12/8/22 22:52, Kai Huang wrote:
> +static int tdmr_add_rsvd_area(struct tdmr_info *tdmr, int *p_idx, u64 addr,
> +			      u64 size, u16 max_reserved_per_tdmr)
> +{
> +	struct tdmr_reserved_area *rsvd_areas = tdmr->reserved_areas;
> +	int idx = *p_idx;
> +
> +	/* Reserved area must be 4K aligned in offset and size */
> +	if (WARN_ON(addr & ~PAGE_MASK || size & ~PAGE_MASK))
> +		return -EINVAL;
> +
> +	if (idx >= max_reserved_per_tdmr)
> +		return -E2BIG;
> +
> +	rsvd_areas[idx].offset = addr - tdmr->base;
> +	rsvd_areas[idx].size = size;
> +
> +	*p_idx = idx + 1;
> +
> +	return 0;
> +}

It's probably worth at least a comment here to say:

	/*
	 * Consume one reserved area per call.  Make no effort to
	 * optimize or reduce the number of reserved areas which are
	 * consumed by contiguous reserved areas, for instance.
	 */

I think the -E2BIG is also wrong.  It should be ENOSPC.  I'd also add a
pr_warn() there.  Especially with how lazy this whole thing is, I can
start to see how the reserved areas might be exhausted.  Let's be kind
to our future selves and make the error (and the fix) easier to find.

It's probably also worth noting *somewhere* that there's a balance to be
had between TDMRs and reserved areas.  A system that is running out of
reserved areas in a TDMR could split a TDMR to get more reserved areas.
A system that has run out of TDMRs could relatively easily coalesce two
adjacent TDMRs (before the PAMTs are allocated) and use a reserved area
if there was a gap between them.

I'm *really* close to acking this patch once those are fixed up.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux