public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Aaron Lewis <aaronlewis@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com
Subject: Re: [PATCH v2 4/6] KVM: selftests: Add string formatting options to ucall
Date: Mon, 5 Jun 2023 14:44:52 -0700	[thread overview]
Message-ID: <ZH5XVOIb2GtwAKNC@google.com> (raw)
In-Reply-To: <20230424225854.4023978-5-aaronlewis@google.com>

On Mon, Apr 24, 2023, Aaron Lewis wrote:
> Add more flexibility to guest debugging and testing by adding
> GUEST_PRINTF() and GUEST_ASSERT_FMT() to the ucall framework.
> 
> A buffer to hold the formatted string was added to the ucall struct.
> That allows the guest/host to avoid the problem of passing an
> arbitrary number of parameters between themselves when resolving the
> string.  Instead, the string is resolved in the guest then passed
> back to the host to be logged.
> 
> The formatted buffer is set to 1024 bytes which increases the size
> of the ucall struct.  As a result, this will increase the number of
> pages requested for the guest.
> 
> The buffer size was chosen to accommodate most use cases, and based on
> similar usage.  E.g. printf() uses the same size buffer in
> arch/x86/boot/printf.c.

...
>  #define UCALL_MAX_ARGS 7
> +#define UCALL_BUFFER_LEN 1024
>  
>  struct ucall {
>  	uint64_t cmd;
>  	uint64_t args[UCALL_MAX_ARGS];
> +	char buffer[UCALL_BUFFER_LEN];

...

> diff --git a/tools/testing/selftests/kvm/lib/ucall_common.c b/tools/testing/selftests/kvm/lib/ucall_common.c
> index 77ada362273d..c09e57c8ef77 100644
> --- a/tools/testing/selftests/kvm/lib/ucall_common.c
> +++ b/tools/testing/selftests/kvm/lib/ucall_common.c
> @@ -55,6 +55,7 @@ static struct ucall *ucall_alloc(void)
>  		if (!test_and_set_bit(i, ucall_pool->in_use)) {
>  			uc = &ucall_pool->ucalls[i];
>  			memset(uc->args, 0, sizeof(uc->args));
> +			memset(uc->buffer, 0, sizeof(uc->buffer));

The use in boot/printf.c isn't a great reference point.  That "allocation" is
on-stack and effectively free, whereas the use here "requires" zeroing the buffer
during allocation.  I usually tell people to not worry about selftests performance,
but zeroing 1KiB on every ucall seems a bit excessive.

However, that's more of an argument to not zero than it is to try and squeak by
with a smaller size.  The guest really should explicitly tell the host how much
of the buffer.  And with that, there should be no need to zero the buffer because
the host isn't relying on the memory being zeroed.

On a somehwat related topic, this patch should also introduce a macro/helper to
retrieve and print the buffer on the backend.  Partly to reduce copy+paste, partly
to make it easier to review (i.e. show the end-to-end), and partly so that the
ucall code can craft a more explicit contract.

  reply	other threads:[~2023-06-05 21:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24 22:58 [PATCH v2 0/6] Add printf and formatted asserts in the guest Aaron Lewis
2023-04-24 22:58 ` [PATCH v2 1/6] KVM: selftests: Add strnlen() to the string overrides Aaron Lewis
2023-04-24 22:58 ` [PATCH v2 2/6] KVM: selftests: Add kvm_snprintf() to KVM selftests Aaron Lewis
2023-06-06  0:05   ` Sean Christopherson
2023-04-24 22:58 ` [PATCH v2 3/6] KVM: selftests: Add additional pages to the guest to accommodate ucall Aaron Lewis
2023-06-05 20:43   ` Sean Christopherson
2023-04-24 22:58 ` [PATCH v2 4/6] KVM: selftests: Add string formatting options to ucall Aaron Lewis
2023-06-05 21:44   ` Sean Christopherson [this message]
2023-06-07 16:55     ` Aaron Lewis
2023-04-24 22:58 ` [PATCH v2 5/6] KVM: selftests: Add ucall_fmt2() Aaron Lewis
2023-06-05 22:41   ` Sean Christopherson
2023-06-07 16:55     ` Aaron Lewis
2023-04-24 22:58 ` [PATCH v2 6/6] KVM: selftests: Add a selftest for guest prints and formatted asserts Aaron Lewis

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=ZH5XVOIb2GtwAKNC@google.com \
    --to=seanjc@google.com \
    --cc=aaronlewis@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.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