public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Will Deacon <will@kernel.org>
Cc: maz@kernel.org, andre.przywara@arm.com,
	jean-philippe.brucker@arm.com, suzuki.poulose@arm.com,
	kvm@vger.kernel.org, julien.thierry.kdev@gmail.com,
	apatel@ventanamicro.com, oliver.upton@linux.dev,
	catalin.marinas@arm.com, kernel-team@android.com
Subject: Re: [PATCH kvmtool 0/3] Change what --nodefaults does and a revert
Date: Wed, 11 Oct 2023 15:56:53 +0100	[thread overview]
Message-ID: <ZSa3tQ830HcQgPwD@monolith> (raw)
In-Reply-To: <169503375704.3755487.15995711453259792866.b4-ty@kernel.org>

Hi Will,

Sorry for the late reply, was on holiday.

On Mon, Sep 18, 2023 at 12:05:14PM +0100, Will Deacon wrote:
> On Thu, 7 Sep 2023 18:16:52 +0100, Alexandru Elisei wrote:
> > The first two patches revert "virtio-net: Don't print the compat warning
> > for the default device" because using --network mode=none disables the
> > device and lets the user know that it can use that to disable the default
> > virtio-net device. I don't think the changes are controversial.
> > 
> > And the last patch is there to get the conversation going about changing
> > what --nodefaults does. Details in the patch.
> > 
> > [...]
> 
> Applied first two to kvmtool (master), thanks!
> 
> [1/3] Revert "virtio-net: Don't print the compat warning for the default device"
>       https://git.kernel.org/will/kvmtool/c/4498eb7400c6
> [2/3] builtin-run: Document mode=none for -n/--network
>       https://git.kernel.org/will/kvmtool/c/c7b7a542cdcd
> 
> I'm also not sure about the final RFC patch:
> 
> [3/3] builtin-run: Have --nodefaults disable the default virtio-net device
> 
> so it would be great to hear if anybody else has an opinion on that. IIRC,
> we introduced this for some EFI work, so perhaps those folks might have
> an opinion?

It was actually introduced to allow kvmtool to load a kvm-unit-tests test
file using --kernel instead of --firmware [1].

The user can specify parameters for a test using two methods: using the
kernel command line (for selecting a specific test from a test file with
multiple tests, for example) and from an initrd (for environment variables,
in a key=value format). --firmware cannot load an initrd, so the only
option is to use --kernel. But kvmtool mangles the kernel command line by
prepending several kernel options, which breaks kvm-unit-tests' command
line parser. Until --defaults there was no way to disable this behaviour.

To the point of running kvm-unit-tests, it makes no functional difference
if a test is run with --nodefaults --network mode=none or with --nodefaults
only. It's just that I think that --nodefaults disabling the default
configuration options is slightly more intuitive, but I'm not sure the
effort of changing the semantics is worth it (need to inspect all the code
that sets the default configuration options, then possibly adding new
kvmtool command line parameters to bring back those options if there's no
other way of changing them - I suspect this can get rather tedious).

[1] https://lore.kernel.org/all/20210923144505.60776-1-alexandru.elisei@arm.com/

Thanks,
Alex

> 
> Cheers,
> -- 
> Will
> 
> https://fixes.arm64.dev
> https://next.arm64.dev
> https://will.arm64.dev

  reply	other threads:[~2023-10-11 14:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07 17:16 [PATCH kvmtool 0/3] Change what --nodefaults does and a revert Alexandru Elisei
2023-09-07 17:16 ` [PATCH kvmtool 1/3] Revert "virtio-net: Don't print the compat warning for the default device" Alexandru Elisei
2023-09-07 17:16 ` [PATCH kvmtool 2/3] builtin-run: Document mode=none for -n/--network Alexandru Elisei
2023-09-07 17:16 ` [PATCH RFC kvmtool 3/3] builtin-run: Have --nodefaults disable the default virtio-net device Alexandru Elisei
2023-09-18 11:05 ` [PATCH kvmtool 0/3] Change what --nodefaults does and a revert Will Deacon
2023-10-11 14:56   ` Alexandru Elisei [this message]
2023-10-11 16:15     ` Suzuki K Poulose

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=ZSa3tQ830HcQgPwD@monolith \
    --to=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=apatel@ventanamicro.com \
    --cc=catalin.marinas@arm.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /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