qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 0/5] ARM: add query-gic-capabilities SMP comm


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v5 0/5] ARM: add query-gic-capabilities SMP command
Date: Tue, 22 Mar 2016 15:20:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Xu <address@hidden> writes:

> v5 changes:
> - patch 2: moved to target-arm/monitor.c (from target-arm/machine.c)
>            [Peter]
> - patch 3: splitted into three patches: [all from Peter's comments]
>   - patch 3 (new): leverage kvm_arm_create_scratch_host_vcpu(), tiny
>     enhancement of old one to suite our need
>   - patch 4: introduce kvm_support_device() in kvm-all.c
>   - patch 5: do the implementation.
>
> v4 changes:
> - all: rename query-gic-capability to query-gic-capabilities [Andrea]
> - patch 3: rename helper function to kvm_support_device, make it
>   inline and lighter. [Drew]
>
> v3 changes:
> - patch 2: remove func declaration, add qmp header [Drew]
> - patch 3: being able to detect KVM GIC capabilities even without
>   kvm enabled [Andrea]: this is a little bit hacky, need some more
>   review on this.
>
> v2 changes:
> - result layout change: use array and dict for the capability bits
>   rather than a single array of strings [Andrea/Markus]
> - spelling out what GIC is in doc [Eric]
>
> This patch is to add ARM-specific command "query-gic-capability".
>
> The new command can report which kind of GIC device the host/QEMU
> support. The returned result is in the form of array.
>
> Sample command and output:
>
> {"execute": "query-gic-capability"}
> {"return": [{"emulated": false, "version": 3, "kernel": false},
>             {"emulated": true, "version": 2, "kernel": true}]}
>
> Testing:
>
> Smoke tests on both x86 (emulated) and another moonshot ARM server.

We discussed the need for a yet another ad hoc query command.  Can you
please summarize the discussion and its conclusion?  Explaining *why* a
feature is needed is always a good idea.  Cover letter and commit
messages are good places for it.



reply via email to

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