public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: passt-dev@passt.top
Subject: Re: [PATCH 0/5] qrap: Fix a number of issues
Date: Fri, 24 Feb 2023 11:36:51 -0800	[thread overview]
Message-ID: <CABJz62NDWdL_qK4a+x_d1sHLacZ=K9x829QEDk6NAOhjFwwaDg@mail.gmail.com> (raw)
In-Reply-To: <20230224184949.518615-1-abologna@redhat.com>

On Fri, Feb 24, 2023 at 07:49:44PM +0100, Andrea Bolognani wrote:
> Andrea Bolognani (5):
>   qrap: Fix limits for PCI addresses
>   qrap: Fix support for pc machines
>   qrap: Drop args in JSON format
>   qrap: Introduce machine-specific PCI address base
>   qrap: Generate -netdev as JSON
>
>  qrap.c | 47 +++++++++++++++++++++++++++++++++++------------
>  1 file changed, 35 insertions(+), 12 deletions(-)

Some information about testing.

In order to convince myself that the changes I was working on were
correct, I have created a few quick and dirty test scripts. You can
find them here:

  https://gitlab.com/abologna/passt/-/commits/qrap-tests

The commit contains a few YAML files:

  vmi-small-q35-passt.yaml # q35 VM with few devices
  vmi-small-pc-passt.yaml  #  pc VM with few devices
  vmi-big-q35-passt.yaml   # q35 VM with many devices
  vmi-big-pc-passt.yaml    #  pc VM with many devices

Each one of those, fed into KubeVirt, results in qrap being called
with a bunch of command line arguments. These are normally passed to
the actual QEMU binary, but in my case I've hacked qrap so that
they're simply printed out.

For each of the scenarios, there are three files:

  vm.in  # arguments passed to qrap
  vm.exp # arguments generated by the current version of qrap
  vm.sh  # test script

Running vm.sh results in qrap being called with the same arguments
contained in vm.in (but quoted for shell consumption), with the
output collected into the temporary file vm.out. This file is then
compared with both vm.in (to highlight changes made by qrap) and with
vm.exp (to highlight changes in behavior compared to the current
version of qrap).


Running these tests before applying my patches should result in
vm.out being identical to vm.ext whereas, after my patches have been
applied, the following important changes will be visible:

  --- pc-small.exp	2023-02-24 20:11:14.559711296 +0100
  +++ pc-small.out	2023-02-24 20:26:53.557307727 +0100
  @@ -75,6 +75,6 @@
   -msg
   timestamp=on
   -device
  -virtio-net-pci,bus=pci.0,addr=0x2,netdev=hostnet0,x-txburst=4096
  +{"driver":"virtio-net-pci","bus":"pci.0","addr":"0x8","netdev":"hostnet0","x-txburst":4096}

(addresses of other devices are now parsed correctly, so qrap's
interface will be assigned to slot 8, which is available, instead of
slot 2, which isn't)

  --- q35-big.exp	2023-02-24 20:11:14.560711288 +0100
  +++ q35-big.out	2023-02-24 20:27:20.632094269 +0100
  @@ -159,6 +159,6 @@
   -msg
   timestamp=on
   -device
  -{"driver":"virtio-net-pci","bus":"pci.a","addr":"0x0","netdev":"hostnet0","x-txburst":4096}
  +{"driver":"virtio-net-pci","bus":"pci.15","addr":"0x0","netdev":"hostnet0","x-txburst":4096}

(pci.15 is correctly identified as the bus where qrap's interface
should be placed instead of the non-existing pci.a bus)

  --- pc-big.exp	2023-02-24 20:11:14.559711296 +0100
  +++ pc-big.out	2023-02-24 20:27:37.124964240 +0100
  @@ -129,6 +129,6 @@
   -msg
   timestamp=on
   -device
  -virtio-net-pci,bus=pci.0,addr=0x2,netdev=hostnet0,x-txburst=4096
  +{"driver":"virtio-net-pci","bus":"pci.0","addr":"0x11","netdev":"hostnet0","x-txburst":4096}

(again, an available slot will be picked)

Note how the q35-small test sees no differences. That's the one
scenario that was already working, so the lack of changes there is a
very good thing :)


In addition to these crude test scripts, I've also made a custom
RPM build of passt with these patches applied and integrated it into
KubeVirt. Using it, I was able to successfully submit all the YAML
files mentioned earlier and get working VMs, with functional network
connection, as a result.

I also ran the passt tests from KubeVirt's own functional test suite,
and they all passed except for one. That one's about IPv6
connectivity, and I think the lack of IPv6 connectivity in my own
machine / network is to blame for the failure. This specific test
fails with the non-patched version of passt too, further validating
this theory.

-- 
Andrea Bolognani / Red Hat / Virtualization


  parent reply	other threads:[~2023-02-24 19:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 18:49 [PATCH 0/5] qrap: Fix a number of issues Andrea Bolognani
2023-02-24 18:49 ` [PATCH 1/5] qrap: Fix limits for PCI addresses Andrea Bolognani
2023-02-26 23:54   ` David Gibson
2023-02-24 18:49 ` [PATCH 2/5] qrap: Fix support for pc machines Andrea Bolognani
2023-02-26 23:55   ` David Gibson
2023-02-24 18:49 ` [PATCH 3/5] qrap: Drop args in JSON format Andrea Bolognani
2023-02-26 23:56   ` David Gibson
2023-02-24 18:49 ` [PATCH 4/5] qrap: Introduce machine-specific PCI address base Andrea Bolognani
2023-02-26 23:58   ` David Gibson
2023-02-24 18:49 ` [PATCH 5/5] qrap: Generate -netdev as JSON Andrea Bolognani
2023-02-27  0:00   ` David Gibson
2023-02-24 19:36 ` Andrea Bolognani [this message]
2023-02-27 10:25   ` [PATCH 0/5] qrap: Fix a number of issues Stefano Brivio
2023-02-27 13:59     ` Andrea Bolognani
2023-02-27 21:54 ` Stefano Brivio

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='CABJz62NDWdL_qK4a+x_d1sHLacZ=K9x829QEDk6NAOhjFwwaDg@mail.gmail.com' \
    --to=abologna@redhat.com \
    --cc=passt-dev@passt.top \
    /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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).