public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ackerley Tng <ackerleytng@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	marcorr@google.com, seanjc@google.com, michael.roth@amd.com,
	thomas.lendacky@amd.com, joro@8bytes.org, mizhang@google.com,
	pbonzini@redhat.com, andrew.jones@linux.dev, pgonda@google.com,
	vannapurve@google.com
Subject: Re: [PATCH V5 5/7] KVM: selftests: add library for creating/interacting with SEV guests
Date: Wed, 21 Dec 2022 13:13:48 -0800	[thread overview]
Message-ID: <diqz3598v4s3.fsf@google.com> (raw)
In-Reply-To: <20221018205845.770121-6-pgonda@google.com> (message from Peter Gonda on Tue, 18 Oct 2022 13:58:43 -0700)


> +static void encrypt_region(struct kvm_vm *vm, struct  
> userspace_mem_region *region)
> +{
> +	const struct sparsebit *protected_phy_pages =
> +		region->protected_phy_pages;
> +	const uint64_t memory_size = region->region.memory_size;
> +	const vm_paddr_t gpa_start = region->region.guest_phys_addr;
> +	sparsebit_idx_t pg = 0;
> +
> +	sev_register_user_region(vm, region);
> +
> +	while (pg < (memory_size / vm->page_size)) {
> +		sparsebit_idx_t nr_pages;
> +
> +		if (sparsebit_is_clear(protected_phy_pages, pg)) {
> +			pg = sparsebit_next_set(protected_phy_pages, pg);
> +			if (!pg)
> +				break;
> +		}
> +
> +		nr_pages = sparsebit_next_clear(protected_phy_pages, pg) - pg;
> +		if (nr_pages <= 0)
> +			nr_pages = 1;

I think this may not be correct in the case where the sparsebit has the
range [x, 2**64-1] (inclusive) set. In that case, sparsebit_next_clear()
will return 0, but the number of pages could be more than 1.

> +
> +		sev_launch_update_data(vm, gpa_start + pg * vm->page_size,

Computing the beginning of the gpa range with

gpa_start + pg * vm->page_size

only works if this memory region's gpa_start is 0.

> +				       nr_pages * vm->page_size);
> +		pg += nr_pages;
> +	}
> +}

Here's a suggestion (I'm using this on a TDX version of this patch)


/**
  * Iterate over set ranges within sparsebit @s. In each iteration,
  * @range_begin and @range_end will take the beginning and end of the set  
range,
  * which are of type sparsebit_idx_t.
  *
  * For example, if the range [3, 7] (inclusive) is set, within the  
iteration,
  * @range_begin will take the value 3 and @range_end will take the value 7.
  *
  * Ensure that there is at least one bit set before using this macro with
  * sparsebit_any_set(), because sparsebit_first_set() will abort if none are
  * set.
  */
#define sparsebit_for_each_set_range(s, range_begin, range_end)		\
	for (range_begin = sparsebit_first_set(s),			\
		     range_end =					\
		     sparsebit_next_clear(s, range_begin) - 1;		\
	     range_begin && range_end;					\
	     range_begin = sparsebit_next_set(s, range_end),		\
		     range_end =					\
		     sparsebit_next_clear(s, range_begin) - 1)
/*
  * sparsebit_next_clear() can return 0 if [x, 2**64-1] are all set, and the  
-1
  * would then cause an underflow back to 2**64 - 1. This is expected and
  * correct.
  *
  * If the last range in the sparsebit is [x, y] and we try to iterate,
  * sparsebit_next_set() will return 0, and sparsebit_next_clear() will try  
and
  * find the first range, but that's correct because the condition expression
  * would cause us to quit the loop.
  */


static void encrypt_region(struct kvm_vm *vm, struct userspace_mem_region  
*region)
{
	const struct sparsebit *protected_phy_pages =
		region->protected_phy_pages;
	const vm_paddr_t gpa_base = region->region.guest_phys_addr;
	const sparsebit_idx_t lowest_page_in_region = gpa_base >> vm->page_shift;

	sparsebit_idx_t i;
	sparsebit_idx_t j;

	if (!sparsebit_any_set(protected_phy_pages))
		return;

	sev_register_user_region(vm, region);

	sparsebit_for_each_set_range(protected_phy_pages, i, j) {
		const uint64_t size_to_load = (j - i + 1) * vm->page_size;
		const uint64_t offset = (i - lowest_page_in_region) * vm->page_size;
		const uint64_t gpa = gpa_base + offset;

		sev_launch_update_data(vm, gpa, size_to_load);
	}
}

  reply	other threads:[~2022-12-21 21:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 20:58 [PATCH V5 0/7] KVM: selftests: Add simple SEV test Peter Gonda
2022-10-18 20:58 ` [PATCH V5 1/7] KVM: selftests: sparsebit: add const where appropriate Peter Gonda
2022-10-18 20:58 ` [PATCH V5 2/7] KVM: selftests: add hooks for managing protected guest memory Peter Gonda
2022-10-18 20:58 ` [PATCH V5 3/7] KVM: selftests: handle protected bits in page tables Peter Gonda
2022-10-18 20:58 ` [PATCH V5 4/7] KVM: selftests: add support for protected vm_vaddr_* allocations Peter Gonda
2022-10-18 20:58 ` [PATCH V5 5/7] KVM: selftests: add library for creating/interacting with SEV guests Peter Gonda
2022-12-21 21:13   ` Ackerley Tng [this message]
2023-01-09 21:19     ` Peter Gonda
2022-12-22 22:19   ` Vishal Annapurve
2023-01-09 21:20     ` Peter Gonda
2022-10-18 20:58 ` [PATCH V5 6/7] KVM: selftests: Update ucall pool to allocate from shared memory Peter Gonda
2022-10-18 20:58 ` [PATCH V5 7/7] KVM: selftests: Add simple sev vm testing Peter Gonda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=diqz3598v4s3.fsf@google.com \
    --to=ackerleytng@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcorr@google.com \
    --cc=michael.roth@amd.com \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox