qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 8/9] plugins: new hwprofile plugin


From: Alex Bennée
Subject: Re: [PATCH v1 8/9] plugins: new hwprofile plugin
Date: Wed, 03 Jun 2020 18:26:31 +0100
User-agent: mu4e 1.5.1; emacs 28.0.50

Robert Foley <robert.foley@linaro.org> writes:

> On Wed, 3 Jun 2020 at 07:43, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Robert Foley <robert.foley@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.foley@linaro.org>
>> > Tested-by: Robert Foley <robert.foley@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]