Robert Foley <robert.fo...@linaro.org> writes:
> On Wed, 3 Jun 2020 at 07:43, Alex Bennée <alex.ben...@linaro.org> wrote: >> >> >> Robert Foley <robert.fo...@linaro.org> writes: >> > <snip> >> > >> > When testing out the options, I noticed that >> > if we supply arguments of "read", and "write", then we will only get >> > the last one set, "write", since rw gets overwritten. >> > One option would be to error out if more than one of these read/write >> > args is supplied. >> >> Yeah the option parsing is a little clunky although given the way you >> pass them from the QEMU command line perhaps not too worth finessing. >> The default is rw so you make a conscious decision to only care about one >> or the other. >> >> All you can really do is fail to initialise the plugin. Hopefully the >> output should be enough clue. >> >> > >> > Reviewed-by: Robert Foley <robert.fo...@linaro.org> >> > Tested-by: Robert Foley <robert.fo...@linaro.org> >> >> Thanks. >> >> Out of interest what did you measure? Are there any useful use cases you can >> think of? > > We did some testing where we booted an aarch64 VM and an i386 VM a few times > with differentcore counts (up to 64), and viewed the counters. We > also did a test where > we inserted another device (a virtfs mount), booted up and checked > that there was another > device listed (for virtio-9p). > > There are a few useful use cases we are thinking of, in general for debug/perf > testing of PCI devices/drivers. > For example, debug and performance test of a case where we use a queue pair, > (maybe for something like DPDK/SPDK), this plugin would be interesting for > checking that the quantity and locations of accesses are expected. So one thing that has come up in the VIRT-366 discussion is the potential efficiencies of the various kick models for MMIO based hypervisors. Each interaction with a trapped region of memory triggers a vmexit and one thing I wanted to understand for example was the difference between "normal" IRQs and MSIs. -- Alex Bennée
