Re: XP machine freeze
On 31/03/15 14:29, Saso Slavicic wrote: From: Brad Campbell Sent: Tuesday, March 31, 2015 2:28 AM If someone could give me some hard tests to do along the lines of what Saso is up to I could probably get that done faster. With the right bad kernel I can reproduce this lockup in a matter of hours. Hi, My machine usually (but not always) locks during backup. At around 3AM, a samba machine (a kvm machine on the same server actually) cifs mounts C$ and starts copying files off of it. The last stacktrace also shows network code. Is your machine actively working over network (sharing files)? Better than that, it's recording h264 rtsp streams from 3 CCTV cameras, so there is a constant network load of about 1.5-2MB/s (bytes not bits). Come to think of it, out of the 3 XP VM's I have that are an identical config and actually come from the same qcow2 base image this is the one that hits the network hard. The other 2 hardly touch the network. virtio network interface. I can get it to lock up in hours with the right kernel, and repeat lockups after unlocking it with virt-viewer are usually less than an hour at most. My issue is my first bisect proved to be inconclusive, and the second one is about 3 steps from done, but there are no kvm commits in the current set under investigation. I *know* that 3.15.6 was good as I ran that kernel for months, it all started when I upgraded to a 3.18 and I think I've narrowed it down, but like I said the bisects are just not falling out as plausible, and at 5 days for a good and up to 24 hours for a bad it's slow going. I'll finish this bisect and then have a crack at the good/bad range suggested by Paolo. The issue is being a production box I have to schedule the re-boots. I'm just not sure bisection is the right answer to tracking this down. I just don't have the background to know what to poke to try and debug this any other way. Regards, Brad -- Dolphins are so intelligent that within a few weeks they can train Americans to stand at the edge of the pool and throw them fish. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 07/15] target-s390x: Update linux-headers/asm-s390/kvm.h
On Mon, 30 Mar 2015 21:36:22 +0200
Christian Borntraeger wrote:
> Am 30.03.2015 um 16:28 schrieb Michael Mueller:
> > Signed-off-by: Michael Mueller
> > ---
> > linux-headers/asm-s390/kvm.h | 18 +-
> > 1 file changed, 9 insertions(+), 9 deletions(-)
> >
>
> Looks like a leftover. Drop that patch and rename ibc_range to ibc in the
> other patch.
Will drop the patch and stay with the current name used upstream already.
>
>
> > diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
> > index c5a93eb..bfe6925 100644
> > --- a/linux-headers/asm-s390/kvm.h
> > +++ b/linux-headers/asm-s390/kvm.h
> > @@ -70,8 +70,14 @@ struct kvm_s390_io_adapter_req {
> > #define KVM_S390_VM_TOD_LOW0
> > #define KVM_S390_VM_TOD_HIGH 1
> >
> > +/* kvm attributes for crypto */
> > +#define KVM_S390_VM_CRYPTO_ENABLE_AES_KW 0
> > +#define KVM_S390_VM_CRYPTO_ENABLE_DEA_KW 1
> > +#define KVM_S390_VM_CRYPTO_DISABLE_AES_KW 2
> > +#define KVM_S390_VM_CRYPTO_DISABLE_DEA_KW 3
> > +
> > /* kvm attributes for KVM_S390_VM_CPU_MODEL */
> > -/* processor related attributes are r/w */
> > +/* kvm S390 processor related attributes are r/w */
> > #define KVM_S390_VM_CPU_PROCESSOR 0
> > struct kvm_s390_vm_cpu_processor {
> > __u64 cpuid;
> > @@ -80,22 +86,16 @@ struct kvm_s390_vm_cpu_processor {
> > __u64 fac_list[256];
> > };
> >
> > -/* machine related attributes are r/o */
> > +/* kvm S390 machine related attributes are r/o */
> > #define KVM_S390_VM_CPU_MACHINE1
> > struct kvm_s390_vm_cpu_machine {
> > __u64 cpuid;
> > - __u32 ibc;
> > + __u32 ibc_range;
> > __u8 pad[4];
> > __u64 fac_mask[256];
> > __u64 fac_list[256];
> > };
> >
> > -/* kvm attributes for crypto */
> > -#define KVM_S390_VM_CRYPTO_ENABLE_AES_KW 0
> > -#define KVM_S390_VM_CRYPTO_ENABLE_DEA_KW 1
> > -#define KVM_S390_VM_CRYPTO_DISABLE_AES_KW 2
> > -#define KVM_S390_VM_CRYPTO_DISABLE_DEA_KW 3
> > -
> > /* for KVM_GET_REGS and KVM_SET_REGS */
> > struct kvm_regs {
> > /* general purpose regs for s390 */
> >
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 30 Mar 2015 14:28:01 -0600
Eric Blake wrote:
> On 03/30/2015 08:28 AM, Michael Mueller wrote:
> > The patch adds optional parameters to the QMP command query-cpu-definitions.
> > Thus the signature of routine arch_query_cpu_definitions needs to be changed
> > for the stub function and all target implementations:
> >
> > target-arm
> > target-i386
> > target-ppc
> > target-s390
> >
> > Signed-off-by: Michael Mueller
> > ---
>
> > +++ b/qapi-schema.json
> > @@ -2532,21 +2532,31 @@
> > #
> > # @name: the name of the CPU definition
> > #
> > +# @default: #optional defines if cpu model is the default (since 2.4)
>
> Reads poorly. How about:
>
> # @default: #optional true if cpu model is the default, omitted if false
> (since 2.4)
Yep, will change
>
>
> > +#
> > +# @runnable: #optional defines if cpu model is runnable (since 2.4)
>
> Similarly:
>
> # @runnable: #optional true if cpu model is runnable, omitted if false
> (since 2.4)
here as well
>
> > +#
> > # Since: 1.2.0
> > ##
> > { 'type': 'CpuDefinitionInfo',
> > - 'data': { 'name': 'str' } }
> > + 'data': { 'name': 'str', '*is-default': 'bool', '*runnable': 'bool' } }
> >
> > ##
> > # @query-cpu-definitions:
> > #
> > # Return a list of supported virtual CPU definitions
> > #
> > +# @machine: #optional machine type (since 2.4)
> > +#
> > +# @accel: #optional accelerator id (since 2.4)
>
> Maybe mention that these two fields are for filtering results.
I will add a comment as it is more than filtering, it is execution context
information that allows
to determine if a cpu model is runnable.
Thanks a lot,
Michael
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJVGk/gAAoJELPcPLQSJsKQ9qcQAJiURTXS+NZO/kmKfP1aH18s
RC/bhXyV6gVmfsvZ1X7S0cH5eO4Z7AfpNNT73Mw0lYDIXei+94/Mdby4AplF7S8q
RoPVu9KxWXV6oM1nigEMvExt5n6BxIM3+/xvKt1Rkef4cx8qIRju+rCLNekmBd3E
yJtSs3Oasft8LoG+4ZPEv26jC7uvHa04bp1nZslXhgUmbUJZzRtArRohp0JA0kfl
BIzpFSKJEvGB/xwyj4bvfC4NQJ9nMtel6BhO04oxHgQNXmpaJK4vN5h7wi6PG2ac
I7mKhC/nNFPUXvQUGQ91itWH/ir1fyim4Rjhtd2Pvpq19waEg2M+dHp2YKAqg1xd
YrHpAQA/6MLqlBqrsqYzVS/LHz7juXP3u/sX5azdbZY8LPynAXqnSwqiNinvk2bA
sc3NG/JwZnbtASFrjJEpmrudS29IXuNNycISzGwrL06pwgmrFaJkpyzD6gOkJfnh
UByIMqTYskk3yP8G8K4n6775al0Zx8v39E7En+dQozEnVa/SxA5YdjJMVPOZiEt4
O/szkqCr5kcQHZJ/x42Sz0YFZ5QIidhMkX6jEqeak7q0Ow0awXgreuxXEmPYu6lG
5wHo6WP1h6tdogQnJGnyFXC5kWzp2iBYxVDP86/4aKLGyZViNPS1XDSjhd9NH4X/
9IPbCIOJYwpZF9l5GeG/
=JAwu
-END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 30 Mar 2015 14:19:27 -0600
Eric Blake wrote:
> On 03/30/2015 08:28 AM, Michael Mueller wrote:
> > This patch implements a new QMP request named 'query-cpu-model'.
> > It returns the cpu model of cpu 0 and its backing accelerator.
> >
> > request:
> > {"execute" : "query-cpu-model" }
> >
> > answer:
> > {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> >
> > Alias names are resolved to their respective machine type and GA names
> > already during cpu instantiation. Thus, also a cpu model like 'host'
> > which is implemented as alias will return its normalized cpu model name.
> >
> > Furthermore the patch implements the following function:
> >
> > - s390_cpu_models_used(), returns true if S390 cpu models are in use
> >
> > Signed-off-by: Michael Mueller
> > ---
>
> > +++ b/qapi-schema.json
> > @@ -2516,6 +2516,16 @@
> > { 'command': 'query-machines', 'returns': ['MachineInfo'] }
> >
> > ##
> > +# @AccelId
> > +#
> > +# Defines accelerator ids
> > +#
> > +# Since: 2.4
> > +##
> > +{ 'enum': 'AccelId',
> > + 'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
>
> Unusual spacing (0 spaces after '[' but 2 spaces before closing ']'?),
> but not necessarily wrong.
>
>
> > +##
> > +# @CpuModelInfo:
> > +#
> > +# Virtual CPU model definition.
> > +#
> > +# @name: the name of the CPU model definition
> > +#
> > +# @accel: AccelId (name) of this cpu models accelerator
>
> s/models/model's/
>
>
Will fix both findings...
Thanks,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJVGlM7AAoJELPcPLQSJsKQV1IP/07cv8CB1ggyWFq7pCjo/x4G
A6sjzPziW9sZdrcaMsDb2Px62ddyx+4KymnzzdjKTrKGePZGOBQNd0xwCeIDanw9
Z+hVBG8vzqPiwBM25xKUMYl+NDC7SPeqv6YSFelEBAcbsZGtNb9CBqycjbc8AWtj
Qy8PiLlbPQLxUiFIvnTYe3umW60CtnfUoAiRXs3wQyBkWsUZ7HI7/Rsm8wRIq0tE
HX52/xuD79rQvgqeJi+2zxHyB+WGv0GrvOzIB22d93peMOrdXyQj9GYM6R4Fj7pT
XASifUzztLYlUqNh6MRYmrUaLbsV12ERUKitcd1Cw7l8T7tpIh/NpaOhrm8VosVh
P1Wm9UWha1MfF/rW/u/3sW/82Pv+eQ54a9XYd4H4tD3PFMMmIbZK/9D69BpyxtSZ
45fe4jiKO87bryMtaYPH9oAc8VOmOR9EI94p4q/GK8swaYQ5DGNAPiFlWlfmgg4B
VGXmiHE0VeJOH5dh5+wT/5gjZu3ZmUQNtqhT09rfG0jvMZVUFT0qr5vXQtYXW4Gj
DbK3uir15ovHYBErfun11vs15tUoy4PT3OMsmgelgQl1FQG8T7FD9asj72m3vLUh
UVvRj1KduWET4b4W5SBgzLlMdRyTAcXRPKuDCcSCtqfxE4+jsAp3+mYbLpB2y5Aw
Qjklt025kmr0A7pNrL4d
=ZBtF
-END PGP SIGNATURE-
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¤¾h§¶¡Ü¨}©²Æ
zÚ&j:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢf
Re: XP machine freeze
On 31/03/2015 09:18, Brad Campbell wrote: > Better than that, it's recording h264 rtsp streams from 3 CCTV cameras, > so there is a constant network load of about 1.5-2MB/s (bytes not bits). > Come to think of it, out of the 3 XP VM's I have that are an identical > config and actually come from the same qcow2 base image this is the one > that hits the network hard. The other 2 hardly touch the network. > > virtio network interface. I can get it to lock up in hours with the > right kernel, and repeat lockups after unlocking it with virt-viewer are > usually less than an hour at most. Then it's not so weird that you have no KVM left in your bisect log. We can look at smaller suspicious parts of the repository, until we find the good one. For example, after testing before/after the KVM merge, you could test before/after the net-next merge (that would be commit f4f142ed4ef835709c7e6d12eaca10d190bcebed presumed good, and commit ae045e2455429c418a418a3376301a9e5753a0a8 presumed bad). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Mon, 30 Mar 2015 16:50:20 -0300
Eduardo Habkost wrote:
Hello Eduardo,
> On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> [...]
> > diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
> > index 829945d..1698b52 100644
> > --- a/target-s390x/cpu.c
> > +++ b/target-s390x/cpu.c
> > @@ -37,6 +37,11 @@
> > #define CR0_RESET 0xE0UL
> > #define CR14_RESET 0xC200UL;
> >
> > +static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
> > +{
> > +return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
> > +}
> > +
> > /* generate CPU information for cpu -? */
> > void s390_cpu_list(FILE *f, fprintf_function cpu_fprintf)
> > {
> > @@ -74,6 +79,30 @@ CpuDefinitionInfoList *arch_query_cpu_definitions(Error
> > **errp)
> >
> > return entry;
> > }
> > +
> > +CpuModelInfo *arch_query_cpu_model(Error **errp)
> > +{
> > +CpuModelInfo *info;
> > +S390CPUClass *cc;
> > +
> > +if (!s390_cpu_models_used()) {
> > +return NULL;
> > +}
>
> First question is: why you don't want to just return
> { name: "none", accel: ... }
> when TYPE_S390_CPU ("-cpu none") is used?
That's a good idea, indeed! CPU model "none" is used as well in case option
-cpu is omitted.
>
> Now, assuming that you really want to return NULL if -cpu none is used,
> why don't you just ask for the first CPU (like you already do below) and
> check if it is a named CPU model, instead of adding a new global? e.g.:
>
> static bool s390_cpu_class_is_model(S390CPUClass *cc)
> {
> return cpuid(cc->proc) != 0;
> }
>
> CpuModelInfo *arch_query_cpu_model(Error **errp)
> {
> S390CPUClass *cc;
> S390CPUClass *cc;
>
> cc = S390_CPU_GET_CLASS(s390_cpu_addr2state(0));
> if (!s390_cpu_class_is_model(cc)) {
> return NULL;
> }
> [...]
> }
>
>
> > +info = g_try_new0(CpuModelInfo, 1);
> > +if (!info) {
> > +return NULL;
> > +}
> > +cc = S390_CPU_GET_CLASS(s390_cpu_addr2state(0));
> > +info->name = strdup_s390_cpu_name(cc);
>
> I don't think the current version of strdup_s390_cpu_name() can ever
> return NULL. Do you expect it to return NULL in the future?
No I do not expect this. I will drop the NULL test.
>
> > +if (!info->name) {
> > +g_free(info);
> > +return NULL;
> > +}
> > +if (kvm_enabled()) {
> > +info->accel = ACCEL_ID_KVM;
>
> This could be a CPUState field, added automatically by
> cpu_generic_init() using current_machine->accel.
I will add a CPUState field and see how it works out...
>
> > +}
> > +return info;
> > +}
> > #endif
> >
> > static void s390_cpu_set_pc(CPUState *cs, vaddr value)
> > --
> > 1.8.3.1
> >
>
Thanks a lot,
Michael
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kvm: avoid page allocation failure in kvm_set_memory_region()
On Fri, 20 Mar 2015 12:21:37 +
Igor Mammedov wrote:
> KVM guest can fail to startup with following trace on host:
>
> qemu-system-x86: page allocation failure: order:4, mode:0x40d0
> Call Trace:
> dump_stack+0x47/0x67
> warn_alloc_failed+0xee/0x150
> __alloc_pages_direct_compact+0x14a/0x150
> __alloc_pages_nodemask+0x776/0xb80
> alloc_kmem_pages+0x3a/0x110
> kmalloc_order+0x13/0x50
> kmemdup+0x1b/0x40
> __kvm_set_memory_region+0x24a/0x9f0 [kvm]
> kvm_set_ioapic+0x130/0x130 [kvm]
> kvm_set_memory_region+0x21/0x40 [kvm]
> kvm_vm_ioctl+0x43f/0x750 [kvm]
>
> Failure happens when attempting to allocate pages for
> 'struct kvm_memslots', however it doesn't have to be
> present in physically contiguous (kmalloc-ed) address
> space, change allocation to kvm_kvzalloc() so that
> it will be vmalloc-ed when its size is more then a page.
>
> Signed-off-by: Igor Mammedov
ping
> ---
> v2:
> - alloc initial memslots with vmalloc
> - use kvfree in every place where memslots are freed
>
> TODO:
> - work on follow up patches to allocate space for
>actual amount of memory_slots instead of possible maximum.
> ---
> virt/kvm/kvm_main.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index a2214d9..cc6a25d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -471,7 +471,7 @@ static struct kvm *kvm_create_vm(unsigned long
> type) BUILD_BUG_ON(KVM_MEM_SLOTS_NUM > SHRT_MAX);
>
> r = -ENOMEM;
> - kvm->memslots = kzalloc(sizeof(struct kvm_memslots),
> GFP_KERNEL);
> + kvm->memslots = kvm_kvzalloc(sizeof(struct kvm_memslots));
> if (!kvm->memslots)
> goto out_err_no_srcu;
>
> @@ -522,7 +522,7 @@ out_err_no_srcu:
> out_err_no_disable:
> for (i = 0; i < KVM_NR_BUSES; i++)
> kfree(kvm->buses[i]);
> - kfree(kvm->memslots);
> + kvfree(kvm->memslots);
> kvm_arch_free_vm(kvm);
> return ERR_PTR(r);
> }
> @@ -578,7 +578,7 @@ static void kvm_free_physmem(struct kvm *kvm)
> kvm_for_each_memslot(memslot, slots)
> kvm_free_physmem_slot(kvm, memslot, NULL);
>
> - kfree(kvm->memslots);
> + kvfree(kvm->memslots);
> }
>
> static void kvm_destroy_devices(struct kvm *kvm)
> @@ -871,10 +871,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
> goto out_free;
> }
>
> - slots = kmemdup(kvm->memslots, sizeof(struct kvm_memslots),
> - GFP_KERNEL);
> + slots = kvm_kvzalloc(sizeof(struct kvm_memslots));
> if (!slots)
> goto out_free;
> + memcpy(slots, kvm->memslots, sizeof(struct kvm_memslots));
>
> if ((change == KVM_MR_DELETE) || (change == KVM_MR_MOVE)) {
> slot = id_to_memslot(slots, mem->slot);
> @@ -917,7 +917,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
> kvm_arch_commit_memory_region(kvm, mem, &old, change);
>
> kvm_free_physmem_slot(kvm, &old, &new);
> - kfree(old_memslots);
> + kvfree(old_memslots);
>
> /*
>* IOMMU mapping: New slots need to be mapped. Old slots
> need to be @@ -936,7 +936,7 @@ int __kvm_set_memory_region(struct kvm
> *kvm, return 0;
>
> out_slots:
> - kfree(slots);
> + kvfree(slots);
> out_free:
> kvm_free_physmem_slot(kvm, &new, &old);
> out:
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008
On 03/29/2015, 01:25 AM, Hugh Dickins wrote: > But you are very appositely mistaken: copy_huge_page() used to make > the same mistake, and Dave Hansen fixed it back in v3.13, but the fix > never went to the stable trees. > > Your report was on an Ubuntu "3.11.0-15" kernel: I think Ubuntu have > discontinued their 3.11-stable kernel series, but 3.10-longterm and > 3.12-longterm would benefit from including this fix. I haven't tried > patching and building and testing it there, but it looks reasonable. > > Hugh > > commit 30b0a105d9f7141e4cbf72ae5511832457d89788 > Author: Dave Hansen > Date: Thu Nov 21 14:31:58 2013 -0800 > > mm: thp: give transparent hugepage code a separate copy_page Applied to 3.12. Thanks. -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008
On Sun, Mar 29, 2015 at 3:25 AM, Hugh Dickins wrote:
> On Sat, 28 Mar 2015, Andrey Korolyov wrote:
>> On Tue, Feb 24, 2015 at 3:12 AM, Marcelo Tosatti wrote:
>> > On Wed, Feb 04, 2015 at 08:34:04PM +0400, Andrey Korolyov wrote:
>> >> >Hi,
>> >> >
>> >> >I've seen the problem quite a few times. Before spending more time on
>> >> >it, I'd like to have a quick check here to see if anyone ever saw the
>> >> >same problem? Hope it is a relevant question with this mail list.
>> >> >
>> >> >
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>> >> >kernel NULL pointer dereference at 0008
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.078916] IP: []
>> >> >copy_huge_page+0x8a/0x2a0
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: [#1] SMP
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
>> >> >ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
>> >> >iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> >> >xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> >> >iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
>> >> >drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
>> >> >ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
>> >> >hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
>> >> >mdio pps_core
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
>> >> >qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
>> >> >PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.081705] task: 88102675
>> >> >ti: 881026056000 task.ti: 881026056000
>> >> >Jul 2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
>> >> >0010:[] []
>> >> >copy_huge_page+0x8a/0x2a0
>> >>
>> >>
>> >> Hello,
>> >>
>> >> sorry for possible top-posting, the same issue appears on at least
>> >> 3.10 LTS series. The original thread is at
>> >> http://marc.info/?l=kvm&m=14043742300901.
>> >
>> > Andrey,
>> >
>> > I am unable to access the URL above?
>> >
>> >> The necessary components for failure to reappear are a single running
>> >> kvm guest and mounted large thp: hugepagesz=1G (seemingly the same as
>> >> in initial report). With default 2M pages everything is working well,
>> >> the same for 3.18 with 1G THP. Are there any obvious clues for the
>> >> issue?
>> >>
>> >> Thanks!
>> >
>> >
>>
>> Hello,
>>
>> Marcelo, sorry, I`ve missed your reply in time. The working link, for
>> example is http://www.spinics.net/lists/linux-mm/msg75658.html. The
>> reproducer is a very simple, you need 1G THP and mounted hugetlbfs.
>> What is interesting, if guest is backed by THP like '-object
>> memory-backend-file,id=mem,size=1G,mem-path=/hugepages,share=on' the
>> failure is less likely to occur.
>
> I think you're mistaken when you write of "1G THP": although hugetlbfs
> can support 1G hugepages, we don't support that size with Transparent
> Huge Pages.
>
> But you are very appositely mistaken: copy_huge_page() used to make
> the same mistake, and Dave Hansen fixed it back in v3.13, but the fix
> never went to the stable trees.
>
> Your report was on an Ubuntu "3.11.0-15" kernel: I think Ubuntu have
> discontinued their 3.11-stable kernel series, but 3.10-longterm and
> 3.12-longterm would benefit from including this fix. I haven't tried
> patching and building and testing it there, but it looks reasonable.
>
> Hugh
>
> commit 30b0a105d9f7141e4cbf72ae5511832457d89788
> Author: Dave Hansen
> Date: Thu Nov 21 14:31:58 2013 -0800
>
> mm: thp: give transparent hugepage code a separate copy_page
>
> Right now, the migration code in migrate_page_copy() uses copy_huge_page()
> for hugetlbfs and thp pages:
>
>if (PageHuge(page) || PageTransHuge(page))
> copy_huge_page(newpage, page);
>
> So, yay for code reuse. But:
>
> void copy_huge_page(struct page *dst, struct page *src)
> {
> struct hstate *h = page_hstate(src);
>
> and a non-hugetlbfs page has no page_hstate(). This works 99% of the
> time because page_hstate() determines the hstate from the page order
> alone. Since the page order of a THP page matches the default hugetlbfs
> page order, it works.
>
> But, if you change the default huge page size on the boot command-line
> (say default_hugepagesz=1G), then we might not even *have* a 2MB hstate
> so page_hstate() returns null and copy_huge_page() oopses pretty fast
> since copy_huge_page() dereferences the hstate:
>
> void copy_huge_page(struct page *dst, struct page *src)
> {
> struct hstate *h = page_hstate(src);
> if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
> ...
>
> Mel no
Re: [Qemu-devel] [PATCH v4 10/15] target-s390x: Prepare accelerator during cpu object realization
On Mon, 30 Mar 2015 16:33:51 -0300
Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:23PM +0200, Michael Mueller wrote:
> > This patch implements routine s390_cpu_model_init(). It is called by the
> > realize function during instantiation of an cpu object. Its task is to
> > initialize the current accelerator with the properties of the selected
> > processor model.
> >
> > Signed-off-by: Michael Mueller
> > ---
> > target-s390x/cpu-models.c | 37 +
> > target-s390x/cpu-models.h | 4
> > target-s390x/cpu.c| 1 +
> > 3 files changed, 42 insertions(+)
> >
> > diff --git a/target-s390x/cpu-models.c b/target-s390x/cpu-models.c
> > index 8a877d3..ba873ea 100644
> > --- a/target-s390x/cpu-models.c
> > +++ b/target-s390x/cpu-models.c
> > @@ -111,6 +111,7 @@ typedef struct ParmAddrAddrModeMask {
> > } ParmAddrAddrModeMask;
> >
> > static GSList *s390_cpu_aliases;
> > +static bool cpu_models_used;
> >
> > /* compare order of two cpu classes for ascending sort */
> > gint s390_cpu_class_asc_order_compare(gconstpointer a, gconstpointer b)
> > @@ -670,3 +671,39 @@ uint64_t *s390_current_fac_list_mask(void)
> > return s390_fac_list_mask_by_machine(mc->name);
> > }
> > #endif
> > +
> > +/**
> > + * s390_cpu_model_init:
> > + * @cc: S390 CPU class
> > + *
> > + * This function intitializes the current accelerator with processor
> > + * related properties.
> > + *
> > + * Since: 2.4
> > + */
> > +void s390_cpu_model_init(S390CPUClass *cc)
> > +{
> > +S390ProcessorProps proc;
> > +
> > +/* none cpu model case */
> > +if (!strcmp(object_class_get_name(OBJECT_CLASS(cc)), TYPE_S390_CPU)) {
> > +return;
> > +}
>
> Instead of checking the class name, can't you just check a S390CPUClass
> field that may indicate that s390_cpu_model_init() doesn't need to do
> anything for the class? Maybe (cpuid(cc->proc) == 0)?
That will work as well but excludes cpuid 0 from being a valid cpu id.
>
>
> > +
> > +/* accelerator already prepared */
> > +if (cpu_models_used) {
> > +return;
> > +}
>
> I'm still trying to understand the need for this global. But I will ask
> for more details in the following patches that actually use
> s390_cpu_models_used()?
I'm currently using the variable to avoid multiple calls to
kvm_s390_set_processor_props() as it
sets the processor properties for all vcpus. I will not hurt to call it twice
or more often, it
is just not required and just consumes cpu cycles.
>
> > +
> > +proc.cpuid = cpuid(cc->proc);
> > +proc.ibc = cc->proc.ibc;
> > +bitmap_zero(proc.fac_list, FAC_LIST_ARCH_S390_SIZE_UINT1);
> > +bitmap_copy(proc.fac_list, cc->fac_list[ACCEL_CURRENT],
> > +FAC_LIST_CPU_S390_SIZE_UINT1);
> > +
> > +if (kvm_enabled()) {
> > +if (!kvm_s390_set_processor_props(&proc)) {
> > +cpu_models_used = true;
> > +}
> > +}
> > +}
> > diff --git a/target-s390x/cpu-models.h b/target-s390x/cpu-models.h
> > index 9562088..fe3997f 100644
> > --- a/target-s390x/cpu-models.h
> > +++ b/target-s390x/cpu-models.h
> > @@ -45,6 +45,9 @@
> > #define type_cpuid(x) ((uint64_t)((x) & 0x) << 16)
> > #define id_cpuid(x) ((uint64_t)((x) & 0xff) << 32)
> > #define ver_cpuid(x) ((uint64_t)((x) & 0xff) << 56)
> > +#define cpuid(x) (ver_cpuid(x.ver) | \
> > + id_cpuid(x.id) |\
> > + type_cpuid(x.type))
> >
> > #define oldest_ibc(x) (((uint32_t)(x) >> 16) & 0xfff)
> > #define newest_ibc(x) ((uint32_t)(x) & 0xfff)
> > @@ -108,6 +111,7 @@ void s390_cpu_list_entry(gpointer data, gpointer
> > user_data);
> > bool s390_cpu_classes_initialized(void);
> > uint64_t *s390_fac_list_mask_by_machine(const char *name);
> > uint64_t *s390_current_fac_list_mask(void);
> > +void s390_cpu_model_init(S390CPUClass *cc);
> >
> > extern uint64_t qemu_s390_fac_list_mask[];
> >
> > diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
> > index c33f05e..829945d 100644
> > --- a/target-s390x/cpu.c
> > +++ b/target-s390x/cpu.c
> > @@ -180,6 +180,7 @@ static void s390_cpu_realizefn(DeviceState *dev, Error
> > **errp)
> > CPUState *cs = CPU(dev);
> > S390CPUClass *scc = S390_CPU_GET_CLASS(dev);
> >
> > +s390_cpu_model_init(scc);
> > s390_cpu_gdb_init(cs);
> > qemu_init_vcpu(cs);
> > #if !defined(CONFIG_USER_ONLY)
> > --
> > 1.8.3.1
> >
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP machine freeze
On 31/03/15 16:56, Paolo Bonzini wrote: On 31/03/2015 09:18, Brad Campbell wrote: Better than that, it's recording h264 rtsp streams from 3 CCTV cameras, so there is a constant network load of about 1.5-2MB/s (bytes not bits). Come to think of it, out of the 3 XP VM's I have that are an identical config and actually come from the same qcow2 base image this is the one that hits the network hard. The other 2 hardly touch the network. virtio network interface. I can get it to lock up in hours with the right kernel, and repeat lockups after unlocking it with virt-viewer are usually less than an hour at most. Then it's not so weird that you have no KVM left in your bisect log. We can look at smaller suspicious parts of the repository, until we find the good one. For example, after testing before/after the KVM merge, you could test before/after the net-next merge (that would be commit f4f142ed4ef835709c7e6d12eaca10d190bcebed presumed good, and commit ae045e2455429c418a418a3376301a9e5753a0a8 presumed bad). Paolo Right, so now rather than being a pain on my production machine I know what to concentrate on with my staging machine to see if I can produce a pathological test case. Maybe an XP VM running iPerf. Easter is coming up, so I'll have some time to dedicate to the task. If you look at the bisect point I'm currently at it's a mix of i2c and arm. The only vaguely relevant (as far as I can see) commit is the addition of the getrandom() syscall, so my bisect is looking dodgy at best. If I can come up with a better test case on a non-critical box then I'll be in a better position to try and help get to the bottom of the issue. I can at least replicate the actual VM and conditions on similar hardware to try and reproduce it. Regards, Brad -- Dolphins are so intelligent that within a few weeks they can train Americans to stand at the edge of the pool and throw them fish. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Mon, 30 Mar 2015 17:17:21 -0300
Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> > This patch implements a new QMP request named 'query-cpu-model'.
> > It returns the cpu model of cpu 0 and its backing accelerator.
> >
> > request:
> > {"execute" : "query-cpu-model" }
> >
> > answer:
> > {"return" : {"name": "2827-ga2", "accel": "kvm" }}
>
> If you are returning information about an existing CPU, why not just
> extend the output of "query-cpus"?
>
> (Existing qmp_query_cpus() calls cpu_synchronize_state(), which may be
> undesired. But in this case we could add an optional parameter to
> disable the return of data that requires stopping the VCPU).
Will the cpu_cpu_syncronize_state() really hurt in real life? query-cpus will
be called only once
a while...
I will prepare the extension of query-cpus as an option but initially without
the optional
parameter.
>
> >
> > Alias names are resolved to their respective machine type and GA names
> > already during cpu instantiation. Thus, also a cpu model like 'host'
> > which is implemented as alias will return its normalized cpu model name.
> >
> > Furthermore the patch implements the following function:
> >
> > - s390_cpu_models_used(), returns true if S390 cpu models are in use
> >
> > Signed-off-by: Michael Mueller
> [...]
>
Thanks,
Michael
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XP machine freeze
On 31/03/2015 13:16, Brad Campbell wrote: > > If you look at the bisect point I'm currently at it's a mix of i2c and > arm. The only vaguely relevant (as far as I can see) commit is the > addition of the getrandom() syscall, so my bisect is looking dodgy at > best. If I can come up with a better test case on a non-critical box > then I'll be in a better position to try and help get to the bottom of > the issue. Yes, the bisect went wrong somewhere. Still, the 'bad' commit leave both a net-next and a KVM merge, so it could be worse. :) Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM call agenda for 2015-03-31
Juan Quintela wrote: > Hi > > Please, send any topic that you are interested in covering. As there is no agenda, no call. Have a nice day, Juan. > > > Call details: > > By popular demand, a google calendar public entry with it > > > https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ > > (Let me know if you have any problems with the calendar entry. I just > gave up about getting right at the same time CEST, CET, EDT and DST). > > If you need phone number details, contact me privately > > Thanks, Juan. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2/8] KVM: s390: enable more features that need no hypervisor changes
After some review about what these facilities do, the following
facilities will work under KVM and can, therefore, be reported
to the guest if the cpu model and the host cpu provide this bit.
There are plans underway to make the whole bit thing more readable,
but its not yet finished. So here are some last bit changes and
we enhance the KVM mask with:
9 The sense-running-status facility is installed in the
z/Architecture architectural mode.
---> handled by SIE or KVM
10 The conditional-SSKE facility is installed in the
z/Architecture architectural mode.
---> handled by SIE. KVM will retry SIE
13 The IPTE-range facility is installed in the
z/Architecture architectural mode.
---> handled by SIE. KVM will retry SIE
36 The enhanced-monitor facility is installed in the
z/Architecture architectural mode.
---> handled by SIE
47 The CMPSC-enhancement facility is installed in the
z/Architecture architectural mode.
---> handled by SIE
48 The decimal-floating-point zoned-conversion facility
is installed in the z/Architecture architectural mode.
---> handled by SIE
49 The execution-hint, load-and-trap, miscellaneous-
instruction-extensions and processor-assist
---> handled by SIE
51 The local-TLB-clearing facility is installed in the
z/Architecture architectural mode.
---> handled by SIE
52 The interlocked-access facility 2 is installed.
---> handled by SIE
53 The load/store-on-condition facility 2 and load-and-
zero-rightmost-byte facility are installed in the
z/Architecture architectural mode.
---> handled by SIE
57 The message-security-assist-extension-5 facility is
installed in the z/Architecture architectural mode.
---> handled by SIE
66 The reset-reference-bits-multiple facility is installed
in the z/Architecture architectural mode.
---> handled by SIE. KVM will retry SIE
80 The decimal-floating-point packed-conversion
facility is installed in the z/Architecture architectural
mode.
---> handled by SIE
Signed-off-by: Christian Borntraeger
Tested-by: Michael Mueller
Acked-by: Cornelia Huck
---
arch/s390/kvm/kvm-s390.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 9072127..a130885 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -105,8 +105,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
/* upper facilities limit for kvm */
unsigned long kvm_s390_fac_list_mask[] = {
- 0xff82fffbf4fc2000UL,
- 0x005cUL,
+ 0xffe6fffbfcfdfc40UL,
+ 0x205c8000UL,
};
unsigned long kvm_s390_fac_list_mask_size(void)
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 0/8] KVM: s390: Features and fixes for 4.1 (kvm/next)
Paolo, Marcelo, here is (hopefully) the last bunch of changes for 4.1 in KVM. As we have again new interfaces, please review and consider for kvm/next. Christian The following changes since commit 18280d8b4bcd4a2b174ee3cd748166c6190acacb: KVM: s390: represent SIMD cap in kvm facility (2015-03-17 16:33:14 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-next-20150331 for you to fetch changes up to dee6cea97c02f4f7d6efcfd1a0c8459b2b9adf7a: KVM: s390: migrate vcpu interrupt state (2015-03-31 13:49:18 +0200) Features and fixes for 4.1 (kvm/next) 1. Assorted changes 1.1 allow more feature bits for the guest 1.2 Store breaking event address on program interrupts 2. Interrupt handling rework 2.1 Fix copy_to_user while holding a spinlock (cc stable) 2.2 Rework floating interrupts to follow the priorities 2.3 Allow to inject all local interrupts via new ioctl 2.4 allow to get/set the full local irq state, e.g. for migration and introspection Christian Borntraeger (1): KVM: s390: enable more features that need no hypervisor changes David Hildenbrand (2): KVM: s390: store the breaking-event address on pgm interrupts KVM: s390: cpu timer irq priority Jens Freimann (5): KVM: s390: fix get_all_floating_irqs KVM: s390: deliver floating interrupts in order of priority KVM: s390: add ioctl to inject local interrupts KVM: s390: refactor vcpu injection function KVM: s390: migrate vcpu interrupt state Documentation/virtual/kvm/api.txt | 117 +++ Documentation/virtual/kvm/devices/s390_flic.txt |3 + arch/s390/include/asm/kvm_host.h| 30 +- arch/s390/kvm/interrupt.c | 1075 ++- arch/s390/kvm/kvm-s390.c| 54 +- arch/s390/kvm/kvm-s390.h|6 +- arch/s390/kvm/priv.c|9 +- include/uapi/linux/kvm.h| 14 + virt/kvm/kvm_main.c |2 +- 9 files changed, 908 insertions(+), 402 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 6/8] KVM: s390: add ioctl to inject local interrupts
From: Jens Freimann
We have introduced struct kvm_s390_irq a while ago which allows to
inject all kinds of interrupts as defined in the Principles of
Operation.
Add ioctl to inject interrupts with the extended struct kvm_s390_irq
Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
Documentation/virtual/kvm/api.txt | 56 +++
arch/s390/kvm/kvm-s390.c | 10 +++
include/uapi/linux/kvm.h | 3 +++
virt/kvm/kvm_main.c | 2 +-
4 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 0d7fc66..a7c651d 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2820,6 +2820,62 @@ single frame starting at start_gfn for count frames.
Note: If any architecturally invalid key value is found in the given data then
the ioctl will return -EINVAL.
+4.92 KVM_S390_IRQ
+
+Capability: KVM_CAP_S390_INJECT_IRQ
+Architectures: s390
+Type: vcpu ioctl
+Parameters: struct kvm_s390_irq (in)
+Returns: 0 on success, -1 on error
+Errors:
+ EINVAL: interrupt type is invalid
+ type is KVM_S390_SIGP_STOP and flag parameter is invalid value
+ type is KVM_S390_INT_EXTERNAL_CALL and code is bigger
+than the maximum of VCPUs
+ EBUSY: type is KVM_S390_SIGP_SET_PREFIX and vcpu is not stopped
+ type is KVM_S390_SIGP_STOP and a stop irq is already pending
+ type is KVM_S390_INT_EXTERNAL_CALL and an external call interrupt
+is already pending
+
+Allows to inject an interrupt to the guest.
+
+Using struct kvm_s390_irq as a parameter allows
+to inject additional payload which is not
+possible via KVM_S390_INTERRUPT.
+
+Interrupt parameters are passed via kvm_s390_irq:
+
+struct kvm_s390_irq {
+ __u64 type;
+ union {
+ struct kvm_s390_io_info io;
+ struct kvm_s390_ext_info ext;
+ struct kvm_s390_pgm_info pgm;
+ struct kvm_s390_emerg_info emerg;
+ struct kvm_s390_extcall_info extcall;
+ struct kvm_s390_prefix_info prefix;
+ struct kvm_s390_stop_info stop;
+ struct kvm_s390_mchk_info mchk;
+ char reserved[64];
+ } u;
+};
+
+type can be one of the following:
+
+KVM_S390_SIGP_STOP - sigp stop; parameter in .stop
+KVM_S390_PROGRAM_INT - program check; parameters in .pgm
+KVM_S390_SIGP_SET_PREFIX - sigp set prefix; parameters in .prefix
+KVM_S390_RESTART - restart; no parameters
+KVM_S390_INT_CLOCK_COMP - clock comparator interrupt; no parameters
+KVM_S390_INT_CPU_TIMER - CPU timer interrupt; no parameters
+KVM_S390_INT_EMERGENCY - sigp emergency; parameters in .emerg
+KVM_S390_INT_EXTERNAL_CALL - sigp external call; parameters in .extcall
+KVM_S390_MCHK - machine check interrupt; parameters in .mchk
+
+
+Note that the vcpu ioctl is asynchronous to vcpu execution.
+
+
5. The kvm_run structure
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index dbc9ca3..8bc25d4 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -177,6 +177,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_S390_IRQCHIP:
case KVM_CAP_VM_ATTRIBUTES:
case KVM_CAP_MP_STATE:
+ case KVM_CAP_S390_INJECT_IRQ:
case KVM_CAP_S390_USER_SIGP:
case KVM_CAP_S390_USER_STSI:
case KVM_CAP_S390_SKEYS:
@@ -2391,6 +2392,15 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
long r;
switch (ioctl) {
+ case KVM_S390_IRQ: {
+ struct kvm_s390_irq s390irq;
+
+ r = -EFAULT;
+ if (copy_from_user(&s390irq, argp, sizeof(s390irq)))
+ break;
+ r = kvm_s390_inject_vcpu(vcpu, &s390irq);
+ break;
+ }
case KVM_S390_INTERRUPT: {
struct kvm_s390_interrupt s390int;
struct kvm_s390_irq s390irq;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 1162ef7..e61f49a 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -802,6 +802,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_S390_MEM_OP 108
#define KVM_CAP_S390_USER_STSI 109
#define KVM_CAP_S390_SKEYS 110
+#define KVM_CAP_S390_INJECT_IRQ 111
#ifdef KVM_CAP_IRQ_ROUTING
@@ -1182,6 +1183,8 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_S390_SKEYS */
#define KVM_S390_GET_SKEYS _IOW(KVMIO, 0xb2, struct kvm_s390_skeys)
#define KVM_S390_SET_SKEYS _IOW(KVMIO, 0xb3, struct kvm_s390_skeys)
+/* Available with KVM_CAP_S390_INJECT_IRQ */
+#define KVM_S390_IRQ _IOW(KVMIO, 0xb4, struct kvm_s390_irq)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU(1 << 0)
#define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a109370..34310a8
[GIT PULL 8/8] KVM: s390: migrate vcpu interrupt state
From: Jens Freimann
This patch adds support to migrate vcpu interrupts. Two new vcpu ioctls
are added which get/set the complete status of pending interrupts in one
go. The ioctls are marked as available with the new capability
KVM_CAP_S390_IRQ_STATE.
We can not use a ONEREG, as the number of pending local interrupts is not
constant and depends on the number of CPUs.
To retrieve the interrupt state we add an ioctl KVM_S390_GET_IRQ_STATE.
Its input parameter is a pointer to a struct kvm_s390_irq_state which
has a buffer and length. For all currently pending interrupts, we copy
a struct kvm_s390_irq into the buffer and pass it to userspace.
To store interrupt state into a buffer provided by userspace, we add an
ioctl KVM_S390_SET_IRQ_STATE. It passes a struct kvm_s390_irq_state into
the kernel and injects all interrupts contained in the buffer.
Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
Documentation/virtual/kvm/api.txt | 61 +
arch/s390/kvm/interrupt.c | 140 ++
arch/s390/kvm/kvm-s390.c | 36 ++
arch/s390/kvm/kvm-s390.h | 4 ++
include/uapi/linux/kvm.h | 11 +++
5 files changed, 252 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index a7c651d..18fb763 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2875,6 +2875,67 @@ KVM_S390_MCHK - machine check interrupt; parameters in
.mchk
Note that the vcpu ioctl is asynchronous to vcpu execution.
+4.94 KVM_S390_GET_IRQ_STATE
+
+Capability: KVM_CAP_S390_IRQ_STATE
+Architectures: s390
+Type: vcpu ioctl
+Parameters: struct kvm_s390_irq_state (out)
+Returns: >= number of bytes copied into buffer,
+ -EINVAL if buffer size is 0,
+ -ENOBUFS if buffer size is too small to fit all pending interrupts,
+ -EFAULT if the buffer address was invalid
+
+This ioctl allows userspace to retrieve the complete state of all currently
+pending interrupts in a single buffer. Use cases include migration
+and introspection. The parameter structure contains the address of a
+userspace buffer and its length:
+
+struct kvm_s390_irq_state {
+ __u64 buf;
+ __u32 flags;
+ __u32 len;
+ __u32 reserved[4];
+};
+
+Userspace passes in the above struct and for each pending interrupt a
+struct kvm_s390_irq is copied to the provided buffer.
+
+If -ENOBUFS is returned the buffer provided was too small and userspace
+may retry with a bigger buffer.
+
+4.95 KVM_S390_SET_IRQ_STATE
+
+Capability: KVM_CAP_S390_IRQ_STATE
+Architectures: s390
+Type: vcpu ioctl
+Parameters: struct kvm_s390_irq_state (in)
+Returns: 0 on success,
+ -EFAULT if the buffer address was invalid,
+ -EINVAL for an invalid buffer length (see below),
+ -EBUSY if there were already interrupts pending,
+ errors occurring when actually injecting the
+ interrupt. See KVM_S390_IRQ.
+
+This ioctl allows userspace to set the complete state of all cpu-local
+interrupts currently pending for the vcpu. It is intended for restoring
+interrupt state after a migration. The input parameter is a userspace buffer
+containing a struct kvm_s390_irq_state:
+
+struct kvm_s390_irq_state {
+ __u64 buf;
+ __u32 len;
+ __u32 pad;
+};
+
+The userspace memory referenced by buf contains a struct kvm_s390_irq
+for each interrupt to be injected into the guest.
+If one of the interrupts could not be injected for some reason the
+ioctl aborts.
+
+len must be a multiple of sizeof(struct kvm_s390_irq). It must be > 0
+and it must not exceed (max_vcpus + 32) * sizeof(struct kvm_s390_irq),
+which is the maximum number of possibly pending cpu-local interrupts.
5. The kvm_run structure
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 2f78f1a..ee2dfdc 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -2125,3 +2125,143 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
struct kvm *kvm,
{
return -EINVAL;
}
+
+int kvm_s390_set_irq_state(struct kvm_vcpu *vcpu, void __user *irqstate, int
len)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+ struct kvm_s390_irq *buf;
+ int r = 0;
+ int n;
+
+ buf = vmalloc(len);
+ if (!buf)
+ return -ENOMEM;
+
+ if (copy_from_user((void *) buf, irqstate, len)) {
+ r = -EFAULT;
+ goto out_free;
+ }
+
+ /*
+* Don't allow setting the interrupt state
+* when there are already interrupts pending
+*/
+ spin_lock(&li->lock);
+ if (li->pending_irqs) {
+ r = -EBUSY;
+ goto out_unlock;
+ }
+
+ for (n = 0; n < len / sizeof(*buf); n++) {
+ r = do_inject_vcpu(vcpu, &buf[n]);
+ if (r)
+
[GIT PULL 4/8] KVM: s390: deliver floating interrupts in order of priority
From: Jens Freimann
This patch makes interrupt handling compliant to the z/Architecture
Principles of Operation with regard to interrupt priorities.
Add a bitmap for pending floating interrupts. Each bit relates to a
interrupt type and its list. A turned on bit indicates that a list
contains items (interrupts) which need to be delivered. When delivering
interrupts on a cpu we can merge the existing bitmap for cpu-local
interrupts and floating interrupts and have a single mechanism for
delivery.
Currently we have one list for all kinds of floating interrupts and a
corresponding spin lock. This patch adds a separate list per
interrupt type. An exception to this are service signal and machine check
interrupts, as there can be only one pending interrupt at a time.
Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
arch/s390/include/asm/kvm_host.h | 30 +-
arch/s390/kvm/interrupt.c| 834 ++-
arch/s390/kvm/kvm-s390.c | 4 +-
arch/s390/kvm/kvm-s390.h | 2 +-
arch/s390/kvm/priv.c | 9 +-
5 files changed, 511 insertions(+), 368 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index b8d1e97..d01fc58 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -344,6 +344,11 @@ enum irq_types {
IRQ_PEND_COUNT
};
+/* We have 2M for virtio device descriptor pages. Smallest amount of
+ * memory per page is 24 bytes (1 queue), so (2048*1024) / 24 = 87381
+ */
+#define KVM_S390_MAX_VIRTIO_IRQS 87381
+
/*
* Repressible (non-floating) machine check interrupts
* subclass bits in MCIC
@@ -421,13 +426,32 @@ struct kvm_s390_local_interrupt {
unsigned long pending_irqs;
};
+#define FIRQ_LIST_IO_ISC_0 0
+#define FIRQ_LIST_IO_ISC_1 1
+#define FIRQ_LIST_IO_ISC_2 2
+#define FIRQ_LIST_IO_ISC_3 3
+#define FIRQ_LIST_IO_ISC_4 4
+#define FIRQ_LIST_IO_ISC_5 5
+#define FIRQ_LIST_IO_ISC_6 6
+#define FIRQ_LIST_IO_ISC_7 7
+#define FIRQ_LIST_PFAULT 8
+#define FIRQ_LIST_VIRTIO 9
+#define FIRQ_LIST_COUNT 10
+#define FIRQ_CNTR_IO 0
+#define FIRQ_CNTR_SERVICE 1
+#define FIRQ_CNTR_VIRTIO 2
+#define FIRQ_CNTR_PFAULT 3
+#define FIRQ_MAX_COUNT 4
+
struct kvm_s390_float_interrupt {
+ unsigned long pending_irqs;
spinlock_t lock;
- struct list_head list;
- atomic_t active;
+ struct list_head lists[FIRQ_LIST_COUNT];
+ int counters[FIRQ_MAX_COUNT];
+ struct kvm_s390_mchk_info mchk;
+ struct kvm_s390_ext_info srv_signal;
int next_rr_cpu;
unsigned long idle_mask[BITS_TO_LONGS(KVM_MAX_VCPUS)];
- unsigned int irq_count;
};
struct kvm_hw_wp_info_arch {
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 65b4eee..298d63b 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "kvm-s390.h"
#include "gaccess.h"
#include "trace-s390.h"
@@ -34,11 +35,6 @@
#define PFAULT_DONE 0x0680
#define VIRTIO_PARAM 0x0d00
-static int is_ioint(u64 type)
-{
- return ((type & 0xfffeu) != 0xfffeu);
-}
-
int psw_extint_disabled(struct kvm_vcpu *vcpu)
{
return !(vcpu->arch.sie_block->gpsw.mask & PSW_MASK_EXT);
@@ -74,70 +70,25 @@ static int ckc_interrupts_enabled(struct kvm_vcpu *vcpu)
return 1;
}
-static u64 int_word_to_isc_bits(u32 int_word)
+static inline int is_ioirq(unsigned long irq_type)
{
- u8 isc = (int_word & 0x3800) >> 27;
+ return ((irq_type >= IRQ_PEND_IO_ISC_0) &&
+ (irq_type <= IRQ_PEND_IO_ISC_7));
+}
+static uint64_t isc_to_isc_bits(int isc)
+{
return (0x80 >> isc) << 24;
}
-static int __must_check __interrupt_is_deliverable(struct kvm_vcpu *vcpu,
- struct kvm_s390_interrupt_info *inti)
+static inline u8 int_word_to_isc(u32 int_word)
{
- switch (inti->type) {
- case KVM_S390_INT_EXTERNAL_CALL:
- if (psw_extint_disabled(vcpu))
- return 0;
- if (vcpu->arch.sie_block->gcr[0] & 0x2000ul)
- return 1;
- return 0;
- case KVM_S390_INT_EMERGENCY:
- if (psw_extint_disabled(vcpu))
- return 0;
- if (vcpu->arch.sie_block->gcr[0] & 0x4000ul)
- return 1;
- return 0;
- case KVM_S390_INT_CLOCK_COMP:
- return ckc_interrupts_enabled(vcpu);
- case KVM_S390_INT_CPU_TIMER:
- if (psw_extint_disabled(vcpu))
- return 0;
- if (vcpu->arch.sie_block->gcr[0] & 0x400ul)
- return 1;
- return 0;
- case KVM_S390_INT_SERVICE:
- case KVM_S390_INT_PFAULT_INIT:
- case KVM_S390_INT_PFAULT_DONE:
- case KVM_S390_INT_VIRTIO:
-
[GIT PULL 5/8] KVM: s390: cpu timer irq priority
From: David Hildenbrand
We now have a mechanism for delivering interrupts according to their priority.
Let's inject them using our new infrastructure (instead of letting only hardware
handle them), so we can be sure that the irq priorities are satisfied.
For s390, the cpu timer and the clock comparator are to be checked for common
code kvm_cpu_has_pending_timer(), although the cpu timer is only stepped when
the guest is being executed.
Reviewed-by: Christian Borntraeger
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
arch/s390/kvm/interrupt.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 298d63b..bc13194 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -70,6 +70,26 @@ static int ckc_interrupts_enabled(struct kvm_vcpu *vcpu)
return 1;
}
+static int ckc_irq_pending(struct kvm_vcpu *vcpu)
+{
+ if (!(vcpu->arch.sie_block->ckc <
+ get_tod_clock_fast() + vcpu->arch.sie_block->epoch))
+ return 0;
+ return ckc_interrupts_enabled(vcpu);
+}
+
+static int cpu_timer_interrupts_enabled(struct kvm_vcpu *vcpu)
+{
+ return !psw_extint_disabled(vcpu) &&
+ (vcpu->arch.sie_block->gcr[0] & 0x400ul);
+}
+
+static int cpu_timer_irq_pending(struct kvm_vcpu *vcpu)
+{
+ return (vcpu->arch.sie_block->cputm >> 63) &&
+ cpu_timer_interrupts_enabled(vcpu);
+}
+
static inline int is_ioirq(unsigned long irq_type)
{
return ((irq_type >= IRQ_PEND_IO_ISC_0) &&
@@ -809,12 +829,7 @@ int kvm_s390_vcpu_has_irq(struct kvm_vcpu *vcpu, int
exclude_stop)
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
{
- if (!(vcpu->arch.sie_block->ckc <
- get_tod_clock_fast() + vcpu->arch.sie_block->epoch))
- return 0;
- if (!ckc_interrupts_enabled(vcpu))
- return 0;
- return 1;
+ return ckc_irq_pending(vcpu) || cpu_timer_irq_pending(vcpu);
}
int kvm_s390_handle_wait(struct kvm_vcpu *vcpu)
@@ -918,9 +933,14 @@ int __must_check
kvm_s390_deliver_pending_interrupts(struct kvm_vcpu *vcpu)
/* pending ckc conditions might have been invalidated */
clear_bit(IRQ_PEND_EXT_CLOCK_COMP, &li->pending_irqs);
- if (kvm_cpu_has_pending_timer(vcpu))
+ if (ckc_irq_pending(vcpu))
set_bit(IRQ_PEND_EXT_CLOCK_COMP, &li->pending_irqs);
+ /* pending cpu timer conditions might have been invalidated */
+ clear_bit(IRQ_PEND_EXT_CPU_TIMER, &li->pending_irqs);
+ if (cpu_timer_irq_pending(vcpu))
+ set_bit(IRQ_PEND_EXT_CPU_TIMER, &li->pending_irqs);
+
do {
irqs = deliverable_irqs(vcpu);
/* bits are in the order of interrupt priority */
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/8] KVM: s390: store the breaking-event address on pgm interrupts
From: David Hildenbrand If the PER-3 facility is installed, the breaking-event address is to be stored in the low core. There is no facility bit for PER-3 in stfl(e) and Linux always uses the value at address 272 no matter if PER-3 is available or not. We can't hide its existence from the guest. All program interrupts injected via the SIE automatically store this information if the PER-3 facility is available in the hypervisor. Also the itdb contains the address automatically. As there is no switch to turn this mechanism off, let's simply make it consistent and also store the breaking event address in case of manual program interrupt injection. Reviewed-by: Jens Freimann Signed-off-by: David Hildenbrand Reviewed-by: Christian Borntraeger Signed-off-by: Christian Borntraeger Acked-by: Cornelia Huck --- arch/s390/kvm/interrupt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index 2afec60..2361b8e 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -585,6 +585,8 @@ static int __must_check __deliver_prog(struct kvm_vcpu *vcpu) kvm_s390_rewind_psw(vcpu, ilc); rc |= put_guest_lc(vcpu, ilc, (u16 *) __LC_PGM_ILC); + rc |= put_guest_lc(vcpu, vcpu->arch.sie_block->gbea, +(u64 *) __LC_LAST_BREAK); rc |= put_guest_lc(vcpu, pgm_info.code, (u16 *)__LC_PGM_INT_CODE); rc |= write_guest_lc(vcpu, __LC_PGM_OLD_PSW, -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 7/8] KVM: s390: refactor vcpu injection function
From: Jens Freimann
Let's provide a version of kvm_s390_inject_vcpu() that
does not acquire the local-interrupt lock and skips
waking up the vcpu.
To be used in a later patch for vcpu-local interrupt migration,
where we are already holding the lock.
Reviewed-by: David Hildenbrand
Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
arch/s390/kvm/interrupt.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index bc13194..2f78f1a 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -1514,12 +1514,10 @@ void kvm_s390_clear_stop_irq(struct kvm_vcpu *vcpu)
spin_unlock(&li->lock);
}
-int kvm_s390_inject_vcpu(struct kvm_vcpu *vcpu, struct kvm_s390_irq *irq)
+static int do_inject_vcpu(struct kvm_vcpu *vcpu, struct kvm_s390_irq *irq)
{
- struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
int rc;
- spin_lock(&li->lock);
switch (irq->type) {
case KVM_S390_PROGRAM_INT:
VCPU_EVENT(vcpu, 3, "inject: program check %d (from user)",
@@ -1559,6 +1557,17 @@ int kvm_s390_inject_vcpu(struct kvm_vcpu *vcpu, struct
kvm_s390_irq *irq)
default:
rc = -EINVAL;
}
+
+ return rc;
+}
+
+int kvm_s390_inject_vcpu(struct kvm_vcpu *vcpu, struct kvm_s390_irq *irq)
+{
+ struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
+ int rc;
+
+ spin_lock(&li->lock);
+ rc = do_inject_vcpu(vcpu, irq);
spin_unlock(&li->lock);
if (!rc)
kvm_s390_vcpu_wakeup(vcpu);
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 3/8] KVM: s390: fix get_all_floating_irqs
From: Jens Freimann
This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390:
add floating irq controller").
get_all_floating_irqs() does copy_to_user() while holding
a spin lock. Let's fix this by filling a temporary buffer
first and copy it to userspace after giving up the lock.
Cc: # 3.18+: 69a8d4562638 KVM: s390: no need to hold...
Reviewed-by: David Hildenbrand
Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Acked-by: Cornelia Huck
---
Documentation/virtual/kvm/devices/s390_flic.txt | 3 ++
arch/s390/kvm/interrupt.c | 60 ++---
2 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/s390_flic.txt
b/Documentation/virtual/kvm/devices/s390_flic.txt
index 4ceef53..d1ad9d5 100644
--- a/Documentation/virtual/kvm/devices/s390_flic.txt
+++ b/Documentation/virtual/kvm/devices/s390_flic.txt
@@ -27,6 +27,9 @@ Groups:
Copies all floating interrupts into a buffer provided by userspace.
When the buffer is too small it returns -ENOMEM, which is the indication
for userspace to try again with a bigger buffer.
+-ENOBUFS is returned when the allocation of a kernelspace buffer has
+failed.
+-EFAULT is returned when copying data to userspace failed.
All interrupts remain pending, i.e. are not deleted from the list of
currently pending interrupts.
attr->addr contains the userspace address of the buffer into which all
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 2361b8e..65b4eee 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1477,61 +1478,68 @@ void kvm_s390_clear_float_irqs(struct kvm *kvm)
spin_unlock(&fi->lock);
}
-static inline int copy_irq_to_user(struct kvm_s390_interrupt_info *inti,
- u8 *addr)
+static void inti_to_irq(struct kvm_s390_interrupt_info *inti,
+ struct kvm_s390_irq *irq)
{
- struct kvm_s390_irq __user *uptr = (struct kvm_s390_irq __user *) addr;
- struct kvm_s390_irq irq = {0};
-
- irq.type = inti->type;
+ irq->type = inti->type;
switch (inti->type) {
case KVM_S390_INT_PFAULT_INIT:
case KVM_S390_INT_PFAULT_DONE:
case KVM_S390_INT_VIRTIO:
case KVM_S390_INT_SERVICE:
- irq.u.ext = inti->ext;
+ irq->u.ext = inti->ext;
break;
case KVM_S390_INT_IO_MIN...KVM_S390_INT_IO_MAX:
- irq.u.io = inti->io;
+ irq->u.io = inti->io;
break;
case KVM_S390_MCHK:
- irq.u.mchk = inti->mchk;
+ irq->u.mchk = inti->mchk;
break;
- default:
- return -EINVAL;
}
-
- if (copy_to_user(uptr, &irq, sizeof(irq)))
- return -EFAULT;
-
- return 0;
}
-static int get_all_floating_irqs(struct kvm *kvm, __u8 *buf, __u64 len)
+static int get_all_floating_irqs(struct kvm *kvm, __user u8 *usrbuf, u64 len)
{
struct kvm_s390_interrupt_info *inti;
struct kvm_s390_float_interrupt *fi;
+ struct kvm_s390_irq *buf;
+ int max_irqs;
int ret = 0;
int n = 0;
+ if (len > KVM_S390_FLIC_MAX_BUFFER || len == 0)
+ return -EINVAL;
+
+ /*
+* We are already using -ENOMEM to signal
+* userspace it may retry with a bigger buffer,
+* so we need to use something else for this case
+*/
+ buf = vzalloc(len);
+ if (!buf)
+ return -ENOBUFS;
+
+ max_irqs = len / sizeof(struct kvm_s390_irq);
+
fi = &kvm->arch.float_int;
spin_lock(&fi->lock);
-
list_for_each_entry(inti, &fi->list, list) {
- if (len < sizeof(struct kvm_s390_irq)) {
+ if (n == max_irqs) {
/* signal userspace to try again */
ret = -ENOMEM;
break;
}
- ret = copy_irq_to_user(inti, buf);
- if (ret)
- break;
- buf += sizeof(struct kvm_s390_irq);
- len -= sizeof(struct kvm_s390_irq);
+ inti_to_irq(inti, &buf[n]);
n++;
}
-
spin_unlock(&fi->lock);
+ if (!ret && n > 0) {
+ if (copy_to_user((void __user *) usrbuf,
+(void *) buf,
+sizeof(struct kvm_s390_irq) * n))
+ ret = -EFAULT;
+ }
+ vfree(buf);
return ret < 0 ? ret : n;
}
@@ -1542,7 +1550,7 @@ static int flic_get_attr(struct kvm_device *dev, struct
kvm_device_attr *attr)
switch (attr->group) {
case KVM_DEV_FLIC_GET_ALL_IRQS:
- r = get_all_floating_irqs(dev->kvm, (u8 *) attr->addr
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Mon, Mar 30, 2015 at 02:20:43PM -0600, Eric Blake wrote:
> On 03/30/2015 02:17 PM, Eduardo Habkost wrote:
> > On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> >> This patch implements a new QMP request named 'query-cpu-model'.
> >> It returns the cpu model of cpu 0 and its backing accelerator.
> >>
> >> request:
> >> {"execute" : "query-cpu-model" }
> >>
> >> answer:
> >> {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> >
> > If you are returning information about an existing CPU, why not just
> > extend the output of "query-cpus"?
> >
> > (Existing qmp_query_cpus() calls cpu_synchronize_state(), which may be
> > undesired. But in this case we could add an optional parameter to
> > disable the return of data that requires stopping the VCPU).
>
> And how would libvirt learn about the existence of that optional
> parameter? Without introspection, a new command is easier to query than
> learning about whether an optional parameter exists (then again, we're
> hoping to get introspection into 2.4, so it may be a moot question).
Even if we don't get introspection, a query-cpus-v2 command (with the
extra parameter) could be extended in the future to return additional
information about CPUs, instead of being specific for CPU model
information.
We also have the option of simply providing predictable QOM paths for
CPU objects, then clients could use qom-get to get what they need
through QOM properties. There was a discussion about it some time ago,
but I don't remember the conclusion.
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
2015-03-30 22:32+0300, Andrey Korolyov: > On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote: > > 2015-03-27 13:16+0300, Andrey Korolyov: > >> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote: > >> > Radim Krčmář writes: > >> >> I second Bandan -- checking that it reproduces on other machine would be > >> >> great for sanity :) (Although a bug in our APICv is far more likely.) > >> > > >> > If it's APICv related, a run without apicv enabled could give more hints. > >> > > >> > Your "devices not getting reset" hypothesis makes the most sense to me, > >> > maybe the timer vector in the error message is just one part of > >> > the whole story. Another misbehaving interrupt from the dark comes in at > >> > the > >> > same time and leads to a double fault. > >> > >> Default trace (APICv enabled, first reboot introduced the issue): > >> http://xdel.ru/downloads/kvm-e5v2-issue/hanged-reboot-apic-on.dat.gz > > > > The relevant part is here, > > prefixed with "qemu-system-x86-4180 [002] 697.111550:" > > > > kvm_exit: reason CR_ACCESS rip 0xd272 info 0 0 > > kvm_cr: cr_write 0 = 0x10 > > kvm_mmu_get_page: existing sp gfn 0 0/4 q0 direct --- !pge !nxe root > > 0 sync > > kvm_entry:vcpu 0 > > kvm_emulate_insn: f:d275: ea 7a d2 00 f0 > > kvm_emulate_insn: f:d27a: 2e 0f 01 1e f0 6c > > kvm_emulate_insn: f:d280: 31 c0 > > kvm_emulate_insn: f:d282: 8e e0 > > kvm_emulate_insn: f:d284: 8e e8 > > kvm_emulate_insn: f:d286: 8e c0 > > kvm_emulate_insn: f:d288: 8e d8 > > kvm_emulate_insn: f:d28a: 8e d0 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xd28f info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason EPT_VIOLATION rip 0x8dd0 info 184 0 > > kvm_page_fault: address f8dd0 error_code 184 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8dd0 info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason EPT_VIOLATION rip 0x76d6 info 184 0 > > kvm_page_fault: address f76d6 error_code 184 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x76d6 info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason PENDING_INTERRUPT rip 0xd331 info 0 0 > > kvm_inj_virq: irq 8 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfea5 info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason EPT_VIOLATION rip 0xfea5 info 184 0 > > kvm_page_fault: address ffea5 error_code 184 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfea5 info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason EPT_VIOLATION rip 0xe990 info 184 0 > > kvm_page_fault: address fe990 error_code 184 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xe990 info 0 80f6 > > kvm_entry:vcpu 0 > > kvm_exit: reason EXCEPTION_NMI rip 0xd334 info 0 8b0d > > kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) > > > >> Trace without APICv (three reboots, just to make sure to hit the > >> problematic condition of supposed DF, as it still have not one hundred > >> percent reproducibility): > >> http://xdel.ru/downloads/kvm-e5v2-issue/apic-off.dat.gz > > > > The trace here contains a well matching excerpt, just instead of the > > EXCEPTION_NMI, it does > > > > 169.905098: kvm_exit: reason EPT_VIOLATION rip 0xd334 info 181 > > 0 > > 169.905102: kvm_page_fault: address feffd066 error_code 181 > > > > and works. Page fault says we tried to read 0xfeffd066 -- probably IOPB > > of TSS. (I guess it is pre-fetch for following IO instruction.) > > > > Nothing strikes me when looking at it, but some APICv boots don't fail, > > so it would be interesting to compare them ... hosts's 0xf6 interrupt > > (IRQ_WORK_VECTOR) is a possible source of races. (We could look more > > closely. It is fired too often for my liking as well.) > > Thanks Radim, > http://xdel.ru/downloads/kvm-e5v2-issue/no-fail-with-apicv.dat.gz > > The related bits looks the same as with enable_apicv=0 for me. Yeah, qemu-system-x86-4201 [007] 159.297337: kvm_exit: reason CR_ACCESS rip 0xd272 info 0 0 kvm_cr: cr_write 0 = 0x10 kvm_mmu_get_page: existing sp gfn 0 0/4 q0 direct --- !pge !nxe root 0 sync kvm_entry:vcpu 0 kvm_emulate_insn: f:d275: ea 7a d2 00 f0 kvm_emulate_insn: f:d27a: 2e 0f 01 1e f0 6c kvm_emulate_insn: f:d280: 31 c0 kvm_emulate_insn: f:d282: 8e e0 kvm_emulate_insn: f:d284: 8e e8 kvm_emulate_insn: f:d286: 8e c0 kvm_emulate_insn: f:d288: 8e d8 k
Re: [GIT PULL 3/8] KVM: s390: fix get_all_floating_irqs
On Tue, Mar 31, 2015 at 03:01:58PM +0200, Christian Borntraeger wrote:
> From: Jens Freimann
>
> This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390:
> add floating irq controller").
>
> get_all_floating_irqs() does copy_to_user() while holding
> a spin lock. Let's fix this by filling a temporary buffer
> first and copy it to userspace after giving up the lock.
>
> Cc: # 3.18+: 69a8d4562638 KVM: s390: no need to
> hold...
>
> Reviewed-by: David Hildenbrand
> Signed-off-by: Jens Freimann
> Signed-off-by: Christian Borntraeger
> Acked-by: Cornelia Huck
...
> -static int get_all_floating_irqs(struct kvm *kvm, __u8 *buf, __u64 len)
> +static int get_all_floating_irqs(struct kvm *kvm, __user u8 *usrbuf, u64 len)
fwiw, this is probably the only place within the kernel where we see
"__user u8 *" instead of "u8 __user *". This is odd within this whole
patch.
> + if (copy_to_user((void __user *) usrbuf,
The cast shouldn't be necessary at all...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 3/8] KVM: s390: fix get_all_floating_irqs
Am 31.03.2015 um 16:12 schrieb Heiko Carstens:
> On Tue, Mar 31, 2015 at 03:01:58PM +0200, Christian Borntraeger wrote:
>> From: Jens Freimann
>>
>> This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390:
>> add floating irq controller").
>>
>> get_all_floating_irqs() does copy_to_user() while holding
>> a spin lock. Let's fix this by filling a temporary buffer
>> first and copy it to userspace after giving up the lock.
>>
>> Cc: # 3.18+: 69a8d4562638 KVM: s390: no need to
>> hold...
>>
>> Reviewed-by: David Hildenbrand
>> Signed-off-by: Jens Freimann
>> Signed-off-by: Christian Borntraeger
>> Acked-by: Cornelia Huck
>
> ...
>
>> -static int get_all_floating_irqs(struct kvm *kvm, __u8 *buf, __u64 len)
>> +static int get_all_floating_irqs(struct kvm *kvm, __user u8 *usrbuf, u64
>> len)
>
> fwiw, this is probably the only place within the kernel where we see
> "__user u8 *" instead of "u8 __user *". This is odd within this whole
> patch.
>
>> +if (copy_to_user((void __user *) usrbuf,
>
> The cast shouldn't be necessary at all...
>
Yes, will fixup.
Paolo, Marcelo,
I will resend the pull request. But do not hesitate to review the other
patches :-)
Christian
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Tue, Mar 31, 2015 at 4:45 PM, Radim Krčmář wrote: > 2015-03-30 22:32+0300, Andrey Korolyov: >> On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote: >> > 2015-03-27 13:16+0300, Andrey Korolyov: >> >> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote: >> >> > Radim Krčmář writes: >> >> >> I second Bandan -- checking that it reproduces on other machine would >> >> >> be >> >> >> great for sanity :) (Although a bug in our APICv is far more likely.) >> >> > >> >> > If it's APICv related, a run without apicv enabled could give more >> >> > hints. >> >> > >> >> > Your "devices not getting reset" hypothesis makes the most sense to me, >> >> > maybe the timer vector in the error message is just one part of >> >> > the whole story. Another misbehaving interrupt from the dark comes in >> >> > at the >> >> > same time and leads to a double fault. >> >> >> >> Default trace (APICv enabled, first reboot introduced the issue): >> >> http://xdel.ru/downloads/kvm-e5v2-issue/hanged-reboot-apic-on.dat.gz >> > >> > The relevant part is here, >> > prefixed with "qemu-system-x86-4180 [002] 697.111550:" >> > >> > kvm_exit: reason CR_ACCESS rip 0xd272 info 0 0 >> > kvm_cr: cr_write 0 = 0x10 >> > kvm_mmu_get_page: existing sp gfn 0 0/4 q0 direct --- !pge !nxe root >> > 0 sync >> > kvm_entry:vcpu 0 >> > kvm_emulate_insn: f:d275: ea 7a d2 00 f0 >> > kvm_emulate_insn: f:d27a: 2e 0f 01 1e f0 6c >> > kvm_emulate_insn: f:d280: 31 c0 >> > kvm_emulate_insn: f:d282: 8e e0 >> > kvm_emulate_insn: f:d284: 8e e8 >> > kvm_emulate_insn: f:d286: 8e c0 >> > kvm_emulate_insn: f:d288: 8e d8 >> > kvm_emulate_insn: f:d28a: 8e d0 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xd28f info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EPT_VIOLATION rip 0x8dd0 info 184 0 >> > kvm_page_fault: address f8dd0 error_code 184 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8dd0 info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EPT_VIOLATION rip 0x76d6 info 184 0 >> > kvm_page_fault: address f76d6 error_code 184 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x76d6 info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason PENDING_INTERRUPT rip 0xd331 info 0 0 >> > kvm_inj_virq: irq 8 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfea5 info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EPT_VIOLATION rip 0xfea5 info 184 0 >> > kvm_page_fault: address ffea5 error_code 184 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfea5 info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EPT_VIOLATION rip 0xe990 info 184 0 >> > kvm_page_fault: address fe990 error_code 184 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXTERNAL_INTERRUPT rip 0xe990 info 0 >> > 80f6 >> > kvm_entry:vcpu 0 >> > kvm_exit: reason EXCEPTION_NMI rip 0xd334 info 0 8b0d >> > kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17) >> > >> >> Trace without APICv (three reboots, just to make sure to hit the >> >> problematic condition of supposed DF, as it still have not one hundred >> >> percent reproducibility): >> >> http://xdel.ru/downloads/kvm-e5v2-issue/apic-off.dat.gz >> > >> > The trace here contains a well matching excerpt, just instead of the >> > EXCEPTION_NMI, it does >> > >> > 169.905098: kvm_exit: reason EPT_VIOLATION rip 0xd334 info >> > 181 0 >> > 169.905102: kvm_page_fault: address feffd066 error_code 181 >> > >> > and works. Page fault says we tried to read 0xfeffd066 -- probably IOPB >> > of TSS. (I guess it is pre-fetch for following IO instruction.) >> > >> > Nothing strikes me when looking at it, but some APICv boots don't fail, >> > so it would be interesting to compare them ... hosts's 0xf6 interrupt >> > (IRQ_WORK_VECTOR) is a possible source of races. (We could look more >> > closely. It is fired too often for my liking as well.) >> >> Thanks Radim, >> http://xdel.ru/downloads/kvm-e5v2-issue/no-fail-with-apicv.dat.gz >> >> The related bits looks the same as with enable_apicv=0 for me. > > Yeah, > > qemu-system-x86-4201 [007] 159.297337: > kvm_exit: reason CR_ACCESS rip 0xd272 info 0 0 > kvm_cr: cr_write 0 = 0x10 > kvm_mmu_get_page: existing sp gfn 0 0/4 q0 direct --- !pge !nxe root 0 > sync > kvm_entry:vcpu 0 > kvm_emulate_insn: f:d275: ea 7a d2 00 f0 > kvm_emulate_insn: f:d27a: 2e 0f 01 1e
[PATCH v2 04/10] KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl
This commit adds a stub function to support the KVM_SET_GUEST_DEBUG
ioctl. Currently any operation flag will return EINVAL. Actual
functionality will be added with further patches.
Signed-off-by: Alex Bennée .
---
v2
- simplified form of the ioctl (stuff will go into setup_debug)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index b112efc..06c5064 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2604,7 +2604,7 @@ handled.
4.87 KVM_SET_GUEST_DEBUG
Capability: KVM_CAP_SET_GUEST_DEBUG
-Architectures: x86, s390, ppc
+Architectures: x86, s390, ppc, arm64
Type: vcpu ioctl
Parameters: struct kvm_guest_debug (in)
Returns: 0 on success; -1 on error
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 5560f74..445933d 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -183,6 +183,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PSCI:
case KVM_CAP_ARM_PSCI_0_2:
case KVM_CAP_READONLY_MEM:
+ case KVM_CAP_SET_GUEST_DEBUG:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -303,10 +304,21 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
+#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE)
+
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
{
- return -EINVAL;
+ if (dbg->control & KVM_GUESTDBG_ENABLE) {
+ if (dbg->control & ~KVM_GUESTDBG_VALID)
+ return -EINVAL;
+
+ vcpu->guest_debug = dbg->control;
+ } else {
+ /* If not enabled clear all flags */
+ vcpu->guest_debug = 0;
+ }
+ return 0;
}
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/10] KVM: arm64: trap nested debug register access
When we are using the hardware registers for guest debug we need to deal
with the guests access to them. There is already a mechanism for dealing
with these accesses so we build on top of that.
- mdscr_el1_bits is renamed as we save the whole register
- any access to mdscr_el1 is now stored in the mirror location
- if we are using HW assisted debug we do the same with DBG[WB][CV]R
There is one register (MDCCINT_EL1) which guest debug doesn't care about
so this behaves as before.
Signed-off-by: Alex Bennée
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 2c359c9..3d32d45 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -122,10 +122,13 @@ struct kvm_vcpu_arch {
* here.
*/
- /* Registers pre any guest debug manipulations */
+ /* Registers before any guest debug manipulations. These
+* shadow registers are updated by the kvm_handle_sys_reg
+* trap handler if the guest accesses or updates them
+*/
struct {
u32 pstate_ss_bit;
- u32 mdscr_el1_bits;
+ u32 mdscr_el1;
struct kvm_guest_debug_arch debug_regs;
} debug_saved_regs;
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 3b368f3..638c111 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -55,8 +55,6 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMCR);
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TDRA | MDCR_EL2_TDOSA);
- trace_kvm_arch_setup_debug_reg32("MDCR_EL2", vcpu->arch.mdcr_el2);
-
/*
* If we are not treating debug registers are dirty we need
* to trap if the guest starts accessing them.
@@ -71,8 +69,10 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
/* Save pstate/mdscr */
vcpu_debug_saved_reg(vcpu, pstate_ss_bit) =
*vcpu_cpsr(vcpu) & DBG_SPSR_SS;
- vcpu_debug_saved_reg(vcpu, mdscr_el1_bits) =
- vcpu_sys_reg(vcpu, MDSCR_EL1) & MDSCR_EL1_DEBUG_BITS;
+
+ vcpu_debug_saved_reg(vcpu, mdscr_el1) =
+ vcpu_sys_reg(vcpu, MDSCR_EL1);
+
/*
* Single Step (ARM ARM D2.12.3 The software step state
* machine)
@@ -161,9 +161,8 @@ void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
*vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
*vcpu_cpsr(vcpu) |= vcpu_debug_saved_reg(vcpu, pstate_ss_bit);
- vcpu_sys_reg(vcpu, MDSCR_EL1) &= ~MDSCR_EL1_DEBUG_BITS;
- vcpu_sys_reg(vcpu, MDSCR_EL1) |=
- vcpu_debug_saved_reg(vcpu, mdscr_el1_bits);
+ vcpu_sys_reg(vcpu, MDSCR_EL1) =
+ vcpu_debug_saved_reg(vcpu, mdscr_el1);
/*
* If we were using HW debug we need to restore the
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index be9b188..d43d7d1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -208,39 +208,61 @@ static bool trap_debug_regs(struct kvm_vcpu *vcpu,
const struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
- if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
- struct kvm_guest_debug_arch *saved;
- __u64 *val;
-
- saved = &vcpu_debug_saved_reg(vcpu, debug_regs);
-
- if (r->reg >= DBGBCR0_EL1 && r->reg <= DBGBCR15_EL1)
- val = &saved->dbg_bcr[r->reg - DBGBCR0_EL1];
- else if (r->reg >= DBGBVR0_EL1 && r->reg <= DBGBVR15_EL1)
- val = &saved->dbg_bvr[r->reg - DBGBVR0_EL1];
- else if (r->reg >= DBGWCR0_EL1 && r->reg <= DBGWCR15_EL1)
- val = &saved->dbg_wcr[r->reg - DBGWCR0_EL1];
- else if (r->reg >= DBGWVR0_EL1 && r->reg <= DBGWVR15_EL1)
- val = &saved->dbg_wvr[r->reg - DBGWVR0_EL1];
- else {
- kvm_err("Bad register index %d\n", r->reg);
- return false;
+ if (vcpu->guest_debug) {
+
+ /* MDSCR_EL1 */
+ if (r->reg == MDSCR_EL1) {
+ if (p->is_write)
+ vcpu_debug_saved_reg(vcpu, mdscr_el1) =
+ *vcpu_reg(vcpu, p->Rt);
+ else
+ *vcpu_reg(vcpu, p->Rt) =
+ vcpu_debug_saved_reg(vcpu, mdscr_el1);
+
+ return true;
}
- if (p->is_write)
- *val = *vcpu_reg(vcpu, p->Rt);
- else
- *vcpu_reg(vcpu, p->Rt) = *val;
+ /* MDCCINT_EL1 */
+
[PATCH v2 05/10] KVM: arm: introduce kvm_arch_setup/clear_debug()
This is a precursor for later patches which will need to do more to
setup debug state before entering the hyp.S switch code. The existing
functionality for setting mdcr_el2 has been moved out of hyp.S and now
uses the value kept in vcpu->arch.mdcr_el2.
This also moves the conditional setting of the TDA bit from the hyp code
into the C code.
Signed-off-by: Alex Bennée
create mode 100644 arch/arm64/kvm/debug.c
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 41008cd..8c01c97 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -242,5 +242,7 @@ static inline void kvm_arch_hardware_unsetup(void) {}
static inline void kvm_arch_sync_events(struct kvm *kvm) {}
static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
+static inline void kvm_arch_setup_debug(struct kvm_vcpu *vcpu) {}
+static inline void kvm_arch_clear_debug(struct kvm_vcpu *vcpu) {}
#endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 445933d..7ea8b0e 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -523,6 +523,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
kvm_vgic_flush_hwstate(vcpu);
kvm_timer_flush_hwstate(vcpu);
+ kvm_arch_setup_debug(vcpu);
local_irq_disable();
@@ -569,6 +570,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
* Back from guest
*/
+ kvm_arch_clear_debug(vcpu);
kvm_timer_sync_hwstate(vcpu);
kvm_vgic_sync_hwstate(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 8ac3c70..0631840 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -101,6 +101,7 @@ struct kvm_vcpu_arch {
/* HYP configuration */
u64 hcr_el2;
+ u32 mdcr_el2;
/* Exception Information */
struct kvm_vcpu_fault_info fault;
@@ -257,4 +258,7 @@ static inline void kvm_arch_sync_events(struct kvm *kvm) {}
static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
+void kvm_arch_setup_debug(struct kvm_vcpu *vcpu);
+void kvm_arch_clear_debug(struct kvm_vcpu *vcpu);
+
#endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index f7fa65d..cd06209 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -122,6 +122,7 @@ int main(void)
DEFINE(VCPU_HPFAR_EL2, offsetof(struct kvm_vcpu,
arch.fault.hpfar_el2));
DEFINE(VCPU_DEBUG_FLAGS, offsetof(struct kvm_vcpu, arch.debug_flags));
DEFINE(VCPU_HCR_EL2, offsetof(struct kvm_vcpu, arch.hcr_el2));
+ DEFINE(VCPU_MDCR_EL2,offsetof(struct kvm_vcpu, arch.mdcr_el2));
DEFINE(VCPU_IRQ_LINES, offsetof(struct kvm_vcpu, arch.irq_lines));
DEFINE(VCPU_HOST_CONTEXT,offsetof(struct kvm_vcpu,
arch.host_cpu_context));
DEFINE(VCPU_TIMER_CNTV_CTL, offsetof(struct kvm_vcpu,
arch.timer_cpu.cntv_ctl));
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 4e6e09e..6796d4a 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -17,7 +17,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(ARM)/psci.o $(ARM)/perf.o
kvm-$(CONFIG_KVM_ARM_HOST) += emulate.o inject_fault.o regmap.o
kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
-kvm-$(CONFIG_KVM_ARM_HOST) += guest.o reset.o sys_regs.o sys_regs_generic_v8.o
+kvm-$(CONFIG_KVM_ARM_HOST) += guest.o debug.o reset.o sys_regs.o
sys_regs_generic_v8.o
kvm-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic.o
kvm-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic-v2.o
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
new file mode 100644
index 000..8a29d0b
--- /dev/null
+++ b/arch/arm64/kvm/debug.c
@@ -0,0 +1,58 @@
+/*
+ * Debug and Guest Debug support
+ *
+ * Copyright (C) 2015 - Linaro Ltd
+ * Author: Alex Bennée
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH v2 08/10] KVM: arm64: guest debug, HW assisted debug support
This adds support for userspace to control the HW debug registers for
guest debug. We'll only copy the $ARCH defined number across as that is
all that hyp.S will use anyway. I've moved some helper functions into
the hw_breakpoint.h header for re-use.
As with single step we need to tweak the guest registers to enable the
exceptions so we need to save and restore those bits.
Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
userspace to query the number of hardware break and watch points
available on the host hardware.
As QEMU tests for watchpoints based on the address and not the PC we
also need to export the value of far_el2 to userspace.
Signed-off-by: Alex Bennée
---
v2
- switched to C setup
- replace host debug registers directly into context
- minor tweak to api docs
- setup right register for debug
- add FAR_EL2 to debug exit structure
- add support fro trapping debug register access
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 17d4f9c..ac34093 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2627,7 +2627,7 @@ The top 16 bits of the control field are architecture
specific control
flags which can include the following:
- KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
- - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
+ - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390, arm64]
- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
- KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
@@ -2642,6 +2642,10 @@ updated to the correct (supplied) values.
The second part of the structure is architecture specific and
typically contains a set of debug registers.
+For arm64 the number of debug registers is implementation defined and
+can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
+KVM_CAP_GUEST_DEBUG_HW_WPS capabilities.
+
When debug events exit the main run loop with the reason
KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
structure containing architecture specific debug information.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index c1ed8cb..a286026 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -306,6 +306,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE |\
KVM_GUESTDBG_USE_SW_BP | \
+ KVM_GUESTDBG_USE_HW_BP | \
KVM_GUESTDBG_SINGLESTEP)
/**
@@ -328,6 +329,26 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
*vcpu,
return -EINVAL;
vcpu->guest_debug = dbg->control;
+
+ /* Hardware assisted Break and Watch points */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
+ int nb = get_num_brps();
+ int nw = get_num_wrps();
+
+ /* Copy across up to IMPDEF debug registers to our
+* shadow copy in the vcpu structure. The debug code
+* will then set them up before we re-enter the guest.
+*/
+ memcpy(vcpu->arch.guest_debug_regs.dbg_bcr,
+ dbg->arch.dbg_bcr, sizeof(__u64)*nb);
+ memcpy(vcpu->arch.guest_debug_regs.dbg_bvr,
+ dbg->arch.dbg_bvr, sizeof(__u64)*nb);
+ memcpy(vcpu->arch.guest_debug_regs.dbg_wcr,
+ dbg->arch.dbg_wcr, sizeof(__u64)*nw);
+ memcpy(vcpu->arch.guest_debug_regs.dbg_wvr,
+ dbg->arch.dbg_wvr, sizeof(__u64)*nw);
+ }
+
} else {
/* If not enabled clear all flags */
vcpu->guest_debug = 0;
diff --git a/arch/arm64/include/asm/hw_breakpoint.h
b/arch/arm64/include/asm/hw_breakpoint.h
index 52b484b..c450552 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -130,6 +130,18 @@ static inline void ptrace_hw_copy_thread(struct
task_struct *task)
}
#endif
+/* Determine number of BRP registers available. */
+static inline int get_num_brps(void)
+{
+ return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
+}
+
+/* Determine number of WRP registers available. */
+static inline int get_num_wrps(void)
+{
+ return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
+}
+
extern struct pmu perf_ops_bp;
#endif /* __KERNEL__ */
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 6a33647..2c359c9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -106,8 +106,9 @@ struct kvm_vcpu_arch {
/* Exception Information */
[PATCH v2 02/10] KVM: define common __KVM_GUESTDBG_USE_SW/HW_BP values
Currently x86, powerpc and soon arm64 use the same two architecture
specific bits for guest debug support for software and hardware
breakpoints. This makes the shared values explicit while leaving the
gate open for another architecture to use some other value if they
really really want to.
Signed-off-by: Alex Bennée
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index ab4d473..1731569 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -310,8 +310,8 @@ struct kvm_guest_debug_arch {
* and upper 16 bits are architecture specific. Architecture specific defines
* that ioctl is for setting hardware breakpoint or software breakpoint.
*/
-#define KVM_GUESTDBG_USE_SW_BP 0x0001
-#define KVM_GUESTDBG_USE_HW_BP 0x0002
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
/* definition of registers in kvm_run */
struct kvm_sync_regs {
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index d7dcef5..1438202 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -250,8 +250,8 @@ struct kvm_debug_exit_arch {
__u64 dr7;
};
-#define KVM_GUESTDBG_USE_SW_BP 0x0001
-#define KVM_GUESTDBG_USE_HW_BP 0x0002
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
#define KVM_GUESTDBG_INJECT_DB 0x0004
#define KVM_GUESTDBG_INJECT_BP 0x0008
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 5eedf84..ce2db14 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -525,8 +525,16 @@ struct kvm_s390_irq {
/* for KVM_SET_GUEST_DEBUG */
-#define KVM_GUESTDBG_ENABLE0x0001
-#define KVM_GUESTDBG_SINGLESTEP0x0002
+#define KVM_GUESTDBG_ENABLE(1 << 0)
+#define KVM_GUESTDBG_SINGLESTEP(1 << 1)
+
+/*
+ * Architecture specific stuff uses the top 16 bits of the field,
+ * however there is some shared commonality for the common cases
+ */
+#define __KVM_GUESTDBG_USE_SW_BP (1 << 16)
+#define __KVM_GUESTDBG_USE_HW_BP (1 << 17)
+
struct kvm_guest_debug {
__u32 control;
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
This adds support for SW breakpoints inserted by userspace.
We do this by trapping all BKPT exceptions in the
hypervisor (MDCR_EL2_TDE). The kvm_debug_exit_arch carries the address
of the exception. If user-space doesn't know of the breakpoint then we
have a guest inserted breakpoint and the hypervisor needs to start again
and deliver the exception to guest.
Signed-off-by: Alex Bennée
---
v2
- update to use new exit struct
- tweak for C setup
- do our setup in debug_setup/clear code
- fixed up comments
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 06c5064..17d4f9c 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2626,7 +2626,7 @@ when running. Common control bits are:
The top 16 bits of the control field are architecture specific control
flags which can include the following:
- - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86]
+ - KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
- KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 7ea8b0e..d3bc8dc 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -304,7 +304,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
-#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE)
+#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE|KVM_GUESTDBG_USE_SW_BP)
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 8a29d0b..cff0475 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -45,11 +45,18 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMCR);
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TDRA | MDCR_EL2_TDOSA);
+ /* Trap debug register access? */
if (!vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY)
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
else
vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDA;
+ /* Trap breakpoints? */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
+ vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
+ else
+ vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;
+
}
void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 524fa25..ed1bbb4 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -82,6 +82,37 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct
kvm_run *run)
return 1;
}
+/**
+ * kvm_handle_debug_exception - handle a debug exception instruction
+ *
+ * @vcpu: the vcpu pointer
+ * @run: access to the kvm_run structure for results
+ *
+ * We route all debug exceptions through the same handler as we
+ * just need to report the PC and the HSR values to userspace.
+ * Userspace may decide to re-inject the exception and deliver it to
+ * the guest if it wasn't for the host to deal with.
+ */
+static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ u32 hsr = kvm_vcpu_get_hsr(vcpu);
+
+ run->exit_reason = KVM_EXIT_DEBUG;
+ run->debug.arch.hsr = hsr;
+
+ switch (hsr >> ESR_ELx_EC_SHIFT) {
+ case ESR_ELx_EC_BKPT32:
+ case ESR_ELx_EC_BRK64:
+ run->debug.arch.pc = *vcpu_pc(vcpu);
+ break;
+ default:
+ kvm_err("%s: un-handled case hsr: %#08x\n",
+ __func__, (unsigned int) hsr);
+ break;
+ }
+ return 0;
+}
+
static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_WFx]= kvm_handle_wfx,
[ESR_ELx_EC_CP15_32]= kvm_handle_cp15_32,
@@ -96,6 +127,8 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_SYS64] = kvm_handle_sys_reg,
[ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
+ [ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
+ [ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
};
static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/10] KVM Guest Debug support for arm64
Hi, Here is V2 of the KVM Guest Debug support for arm64. Although there has been an increase in the total number of patches the implementation is both simpler and more complete. Gone are most of the changes that touch hyp.S replaced with C based hooks kvm_arch_setup/clear_debug() that manipulate the VCPU context before entering hyp.S. As a result I dropped the re-factoring patch for simplicity. The API has been simplified to pass the syndrome information directly back to user-space and leaving it to figure out what each exception is. The ioctl and handle_exit code have been re-factored and simplified. The handle_exit code in particular is all done with one handler which aside from watchpoints is supplying pretty much the same information for every exception. The HW debugging support has been improved by handling guest access to the debug register while debugging is happening. As a result a bunch of the review comments are no longer relevant as they applied to code that no longer exists. All the rest have been addressed as of this patch series. There are a few checkpatch violations for white space. Some in existing code (asm-offsets) and a couple in the handle_exit code where adding a whole extra tab seemed excessive. GIT Repos: The patches for this series are based off v4.0-rc6 and can be found at: https://git.linaro.org/people/alex.bennee/linux.git branch: guest-debug/4.0-rc6-v2 You can find the QEMU code that goes with this patch series at: https://github.com/stsquad/qemu branch: kvm/guest-debug-v2 Patch breakdown: The first 2 patches are simple clean-ups to rationalise some of the commentary and #defines. The next 2 introduce the API and implement the stub ioctl handler which is built up in later patches. The kvm_arch_setup/clear_debug() patch is a functional replacement for the previous manipulations of mdcr_el2 in hyp.S but making the value part of the VCPU context. The next 3 patches implement the various guest debug features. The penultimate patch could be merged with the one before but I kept it split apart for ease of review. The final patch may get dropped before up-streaming but it does provide useful trace points for anyone who want to track what is happening during guest debug. Alex Bennée (10): KVM: add commentary for kvm_debug_exit_arch struct KVM: define common __KVM_GUESTDBG_USE_SW/HW_BP values KVM: arm: guest debug, define API headers KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl KVM: arm: introduce kvm_arch_setup/clear_debug() KVM: arm64: guest debug, add SW break point support KVM: arm64: guest debug, add support for single-step KVM: arm64: guest debug, HW assisted debug support KVM: arm64: trap nested debug register access KVM: arm64: add trace points for guest_debug debug Documentation/virtual/kvm/api.txt | 10 +- arch/arm/include/asm/kvm_host.h| 2 + arch/arm/kvm/arm.c | 51 ++- arch/arm64/include/asm/hw_breakpoint.h | 12 ++ arch/arm64/include/asm/kvm_host.h | 19 ++- arch/arm64/include/uapi/asm/kvm.h | 22 +++ arch/arm64/kernel/asm-offsets.c| 1 + arch/arm64/kernel/hw_breakpoint.c | 12 -- arch/arm64/kvm/Makefile| 2 +- arch/arm64/kvm/debug.c | 249 + arch/arm64/kvm/handle_exit.c | 43 ++ arch/arm64/kvm/hyp.S | 13 +- arch/arm64/kvm/reset.c | 6 + arch/arm64/kvm/sys_regs.c | 55 arch/arm64/kvm/trace.h | 66 + arch/powerpc/include/uapi/asm/kvm.h| 4 +- arch/x86/include/uapi/asm/kvm.h| 4 +- include/uapi/linux/kvm.h | 17 ++- 18 files changed, 553 insertions(+), 35 deletions(-) create mode 100644 arch/arm64/kvm/debug.c -- 2.3.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] KVM: arm: guest debug, define API headers
This commit defines the API headers for guest debugging. There are two
architecture specific debug structures:
- kvm_guest_debug_arch, allows us to pass in HW debug registers
- kvm_debug_exit_arch, signals the exact debug exit and pc
The type of debugging being used is control by the architecture specific
control bits of the kvm_guest_debug->control flags in the ioctl
structure.
Signed-off-by: Alex Bennée
---
v2
- expose hsr and pc directly to user-space
diff --git a/arch/arm64/include/uapi/asm/kvm.h
b/arch/arm64/include/uapi/asm/kvm.h
index 3ef77a4..6ee70a0 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -100,10 +100,24 @@ struct kvm_sregs {
struct kvm_fpu {
};
+/*
+ * See ARM ARM D7.3: Debug Registers
+ *
+ * The control registers are architecturally defined as 32 bits but are
+ * stored as 64 bit values along side the value registers and aligned
+ * with the rest 64 bit registers in the normal CPU context.
+ */
+#define KVM_ARM_NDBG_REGS 16
struct kvm_guest_debug_arch {
+ __u64 dbg_bcr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_bvr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_wcr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_wvr[KVM_ARM_NDBG_REGS];
};
struct kvm_debug_exit_arch {
+ __u64 pc;
+ __u32 hsr;
};
struct kvm_sync_regs {
@@ -207,4 +221,11 @@ struct kvm_arch_memory_slot {
#endif
+/*
+ * Architecture related debug defines - upper 16 bits of
+ * kvm_guest_debug->control
+ */
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
+
#endif /* __ARM_KVM_H__ */
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/10] KVM: add commentary for kvm_debug_exit_arch struct
Bring into line with the commentary for the other structures and their
KVM_EXIT_* cases.
Signed-off-by: Alex Bennée
---
v2
- add comments for other exit types
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8055706..5eedf84 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -226,6 +226,7 @@ struct kvm_run {
__u32 count;
__u64 data_offset; /* relative to kvm_run start */
} io;
+ /* KVM_EXIT_DEBUG */
struct {
struct kvm_debug_exit_arch arch;
} debug;
@@ -274,6 +275,7 @@ struct kvm_run {
__u32 data;
__u8 is_write;
} dcr;
+ /* KVM_EXIT_INTERNAL_ERROR */
struct {
__u32 suberror;
/* Available with KVM_CAP_INTERNAL_ERROR_DATA: */
@@ -284,6 +286,7 @@ struct kvm_run {
struct {
__u64 gprs[32];
} osi;
+ /* KVM_EXIT_PAPR_HCALL */
struct {
__u64 nr;
__u64 ret;
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/10] KVM: arm64: guest debug, add support for single-step
This adds support for single-stepping the guest. As userspace can and
will manipulate guest registers before restarting any tweaking of the
registers has to occur just before control is passed back to the guest.
Furthermore while guest debugging is in effect we need to squash the
ability of the guest to single-step itself as we have no easy way of
re-entering the guest after the exception has been delivered to the
hypervisor.
Signed-off-by: Alex Bennée
---
v2
- Move pstate/mdscr manipulation into C
- don't export guest_debug to assembly
- add accessor for saved_debug regs
- tweak save/restore of mdscr_el1
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index d3bc8dc..c1ed8cb 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -304,7 +304,21 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
kvm_arm_set_running_vcpu(NULL);
}
-#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE|KVM_GUESTDBG_USE_SW_BP)
+#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE |\
+ KVM_GUESTDBG_USE_SW_BP | \
+ KVM_GUESTDBG_SINGLESTEP)
+
+/**
+ * kvm_arch_vcpu_ioctl_set_guest_debug - Setup guest debugging
+ * @kvm: pointer to the KVM struct
+ * @kvm_guest_debug: the ioctl data buffer
+ *
+ * This sets up the VM for guest debugging. Care has to be taken when
+ * manipulating guest registers as these will be set/cleared by the
+ * hyper-visor controller, typically before each kvm_run event. As a
+ * result modification of the guest registers needs to take place
+ * after they have been restored in the hyp.S trampoline code.
+ */
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 0631840..6a33647 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -121,6 +121,13 @@ struct kvm_vcpu_arch {
* here.
*/
+ /* Registers pre any guest debug manipulations */
+ struct {
+ u32 pstate_ss_bit;
+ u32 mdscr_el1_bits;
+
+ } debug_saved_regs;
+
/* Don't run the guest */
bool pause;
@@ -143,6 +150,7 @@ struct kvm_vcpu_arch {
#define vcpu_gp_regs(v)(&(v)->arch.ctxt.gp_regs)
#define vcpu_sys_reg(v,r) ((v)->arch.ctxt.sys_regs[(r)])
+#define vcpu_debug_saved_reg(v, r) ((v)->arch.debug_saved_regs.r)
/*
* CP14 and CP15 live in the same array, as they are backed by the
* same system registers.
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index cff0475..b32362c 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -19,8 +19,16 @@
#include
+#include
+#include
#include
#include
+#include
+
+/* These are the bits of MDSCR_EL1 we may mess with */
+#define MDSCR_EL1_DEBUG_BITS (DBG_MDSCR_SS | \
+ DBG_MDSCR_KDE | \
+ DBG_MDSCR_MDE)
/**
* kvm_arch_setup_debug - set-up debug related stuff
@@ -51,15 +59,46 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
else
vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDA;
- /* Trap breakpoints? */
- if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
+ /* Is Guest debugging in effect? */
+ if (vcpu->guest_debug) {
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
- else
- vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;
+ /* Save pstate/mdscr */
+ vcpu_debug_saved_reg(vcpu, pstate_ss_bit) =
+ *vcpu_cpsr(vcpu) & DBG_SPSR_SS;
+ vcpu_debug_saved_reg(vcpu, mdscr_el1_bits) =
+ vcpu_sys_reg(vcpu, MDSCR_EL1) & MDSCR_EL1_DEBUG_BITS;
+ /*
+* Single Step (ARM ARM D2.12.3 The software step state
+* machine)
+*
+* If we are doing Single Step we need to manipulate
+* MDSCR_EL1.SS and PSTATE.SS. If not we need to
+* suppress the guest from messing with it.
+*/
+ if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
+ *vcpu_cpsr(vcpu) |= DBG_SPSR_SS;
+ vcpu_sys_reg(vcpu, MDSCR_EL1) |= DBG_MDSCR_SS;
+ } else {
+ *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
+ vcpu_sys_reg(vcpu, MDSCR_EL1) &= ~DBG_MDSCR_SS;
+ }
+
+ } else {
+ /* Debug operations can go straight to the guest */
+ vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;
+ }
}
void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
{
- /* Nothing to do yet */
+ if (vcpu->guest_debug) {
+ /* Restore pstate/mdscr bits we may have messed with */
+ *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
+ *vcpu_cpsr(vcpu) |= vcpu_debug_saved_reg(v
[PATCH v2 10/10] KVM: arm64: add trace points for guest_debug debug
This includes trace points for:
kvm_arch_setup_guest_debug
kvm_arch_clear_guest_debug
kvm_handle_guest_debug
I've also added some generic register setting trace events so I can
watch the register values being built up over time. The local
dump_dbg_regs() function dumps all the HW BKPT and WPT registers.
I've also added a #define trace_dreg to shorten some lines.
Signed-off-by: Alex Bennée
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 638c111..7c96288 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -25,12 +25,37 @@
#include
#include
+#include "trace.h"
+
+#define trace_dreg(name, value) trace_kvm_arch_setup_debug_reg32(name, value)
+
/* These are the bits of MDSCR_EL1 we may mess with */
#define MDSCR_EL1_DEBUG_BITS (DBG_MDSCR_SS | \
DBG_MDSCR_KDE | \
DBG_MDSCR_MDE)
/**
+ * dump_dbg_regs - simple debug helper
+ *
+ * This provides a simple helper to dump the HW debug registers
+ */
+static void dump_dbg_regs(struct kvm_vcpu *vcpu, int nb, int nw)
+{
+ int i;
+
+ for (i = 0; i < nb; i++) {
+ trace_printk("bkpt%d: 0x%08x:0x%llx\n", i,
+ (u32) vcpu_sys_reg(vcpu, DBGBCR0_EL1 + i),
+ vcpu_sys_reg(vcpu, DBGBVR0_EL1 + i));
+ }
+ for (i = 0; i < nb; i++) {
+ trace_printk("wtpt%d: 0x%08x:0x%llx\n", i,
+ (u32) vcpu_sys_reg(vcpu, DBGWCR0_EL1 + i),
+ vcpu_sys_reg(vcpu, DBGWVR0_EL1 + i));
+ }
+}
+
+/**
* kvm_arch_setup_debug - set-up debug related stuff
*
* @vcpu: the vcpu pointer
@@ -52,9 +77,13 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
{
bool trap_debug = false;
+ trace_kvm_arch_setup_debug(vcpu->guest_debug);
+
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMCR);
vcpu->arch.mdcr_el2 |= (MDCR_EL2_TDRA | MDCR_EL2_TDOSA);
+ trace_kvm_arch_setup_debug_reg32("MDCR_EL2", vcpu->arch.mdcr_el2);
+
/*
* If we are not treating debug registers are dirty we need
* to trap if the guest starts accessing them.
@@ -66,6 +95,8 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
if (vcpu->guest_debug) {
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
+ trace_dreg("MDCR_EL2", vcpu->arch.mdcr_el2);
+
/* Save pstate/mdscr */
vcpu_debug_saved_reg(vcpu, pstate_ss_bit) =
*vcpu_cpsr(vcpu) & DBG_SPSR_SS;
@@ -73,6 +104,11 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
vcpu_debug_saved_reg(vcpu, mdscr_el1) =
vcpu_sys_reg(vcpu, MDSCR_EL1);
+ trace_dreg("Save: PSTATE.SS",
+ vcpu_debug_saved_reg(vcpu, pstate_ss_bit));
+ trace_dreg("Save: MDSCR",
+ vcpu_debug_saved_reg(vcpu, mdscr_el1));
+
/*
* Single Step (ARM ARM D2.12.3 The software step state
* machine)
@@ -88,6 +124,8 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
*vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
vcpu_sys_reg(vcpu, MDSCR_EL1) &= ~DBG_MDSCR_SS;
}
+ trace_dreg("SPSR_EL2", *vcpu_cpsr(vcpu));
+ trace_dreg("MDSCR_EL1", vcpu_sys_reg(vcpu, MDSCR_EL1));
/*
* HW Break/Watch points
@@ -136,6 +174,9 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
&host->dbg_wvr,
sizeof(__u64)*nw);
+ if (trace_kvm_arch_setup_debug_reg32_enabled())
+ dump_dbg_regs(vcpu, nb, nw);
+
/* Make sure hyp.S copies them in/out */
vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
/* Also track guest changes */
@@ -147,15 +188,24 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;
}
+ trace_kvm_arch_setup_debug_reg32("MDCR_EL2", vcpu->arch.mdcr_el2);
+ trace_kvm_arch_setup_debug_reg32("MDSCR_EL1",
+ vcpu_sys_reg(vcpu, MDSCR_EL1));
+
+
/* Trap debug register access? */
if (trap_debug)
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
else
vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDA;
+
+ trace_kvm_arch_setup_debug_reg32("MDCR_EL2", vcpu->arch.mdcr_el2);
}
void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
{
+ trace_kvm_arch_clear_debug(vcpu->guest_debug);
+
if (vcpu->guest_debug) {
/* Restore pstate/mdscr bits we may have messed with */
*vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
@@ -164,6 +214,8 @@ void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
vcpu_sys_reg(vcpu, MDSCR_EL1) =
v
[PATCH v2 3/4] target-arm: kvm - support for single step
This adds support for single-step. There isn't much to do on the QEMU
side as after we set-up the request for single step via the debug ioctl
it is all handled within the kernel.
Signed-off-by: Alex Bennée
---
v2
- convert to using HSR_EC
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 290c1fe..ae0f8b2 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -475,6 +475,7 @@ void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
*/
#define HSR_EC_SHIFT26
+#define HSR_EC_SOFT_STEP0x32
#define HSR_EC_SW_BKPT 0x3c
static int kvm_handle_debug(CPUState *cs, struct kvm_run *run)
@@ -483,6 +484,13 @@ static int kvm_handle_debug(CPUState *cs, struct kvm_run
*run)
int hsr_ec = arch_info->hsr >> HSR_EC_SHIFT;
switch (hsr_ec) {
+case HSR_EC_SOFT_STEP:
+if (cs->singlestep_enabled) {
+return true;
+} else {
+error_report("Came out of SINGLE STEP when not enabled");
+}
+break;
case HSR_EC_SW_BKPT:
if (kvm_find_sw_breakpoint(cs, arch_info->pc)) {
return true;
@@ -542,6 +550,9 @@ int kvm_arch_on_sigbus(int code, void *addr)
void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
{
+if (cs->singlestep_enabled) {
+dbg->control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_SINGLESTEP;
+}
if (kvm_sw_breakpoints_active(cs)) {
dbg->control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
}
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] QEMU support for KVM Guest Debug on arm64
Hi, I thought I'd sent V1 to the list but apparently not. Anyway this patch series provides the QEMU side of guest debug support for arm64. I'm assuming the first patch will be dropped when a proper merge of the linux-headers is done once the kernel side is upstreamed. There is nothing particularly special about the implementation details although some of the bit-fiddling is a little fiddly. GIT Repos: The patch series is based off a recent master and can be found at: https://github.com/stsquad/qemu branch: kvm/guest-debug-v2 The kernel patches for this series are based off a v4.0-rc6 and can be found at: https://git.linaro.org/people/alex.bennee/linux.git branch: guest-debug/4.0-rc6-v2 Alex Bennée (4): linux-headers: partial sync from my kernel tree (DEV) target-arm: kvm - implement software breakpoints target-arm: kvm - support for single step target-arm: kvm - add support for HW assisted debug linux-headers/asm-arm64/kvm.h | 22 +++ linux-headers/asm-powerpc/kvm.h | 4 +- linux-headers/asm-x86/kvm.h | 4 +- linux-headers/linux/kvm.h | 17 ++- target-arm/kvm.c| 124 target-arm/kvm64.c | 315 target-arm/kvm_arm.h| 21 +++ 7 files changed, 474 insertions(+), 33 deletions(-) -- 2.3.4 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] target-arm: kvm - add support for HW assisted debug
From: Alex Bennée
This adds basic support for HW assisted debug. The ioctl interface to
KVM allows us to pass an implementation defined number of break and
watch point registers. When KVM_GUESTDBG_USE_HW_BP is specified these
debug registers will be installed in place on the world switch into the
guest.
The hardware is actually capable of more advanced matching but it is
unclear if this expressiveness is available via the gdbstub protocol.
Signed-off-by: Alex Bennée
---
v2
- correct setting of PMC/BAS/MASK
- improved commentary
- added helper function to check watchpoint in range
- fix find/deletion of watchpoints
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index ae0f8b2..d1adf5f 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -17,6 +17,7 @@
#include "qemu-common.h"
#include "qemu/timer.h"
+#include "qemu/error-report.h"
#include "sysemu/sysemu.h"
#include "sysemu/kvm.h"
#include "kvm_arm.h"
@@ -476,6 +477,8 @@ void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
#define HSR_EC_SHIFT26
#define HSR_EC_SOFT_STEP0x32
+#define HSR_EC_HW_BKPT 0x30
+#define HSR_EC_HW_WATCH 0x34
#define HSR_EC_SW_BKPT 0x3c
static int kvm_handle_debug(CPUState *cs, struct kvm_run *run)
@@ -496,6 +499,16 @@ static int kvm_handle_debug(CPUState *cs, struct kvm_run
*run)
return true;
}
break;
+case HSR_EC_HW_BKPT:
+if (kvm_arm_find_hw_breakpoint(cs, arch_info->pc)) {
+return true;
+}
+break;
+case HSR_EC_HW_WATCH:
+if (kvm_arm_find_hw_watchpoint(cs, arch_info->far)) {
+return true;
+}
+break;
default:
error_report("%s: unhandled debug exit (%x, %llx)\n",
__func__, arch_info->hsr, arch_info->pc);
@@ -556,6 +569,10 @@ void kvm_arch_update_guest_debug(CPUState *cs, struct
kvm_guest_debug *dbg)
if (kvm_sw_breakpoints_active(cs)) {
dbg->control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
}
+if (kvm_hw_breakpoints_active(cs)) {
+dbg->control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_HW_BP;
+kvm_copy_hw_breakpoint_data(&dbg->arch);
+}
}
/* C6.6.29 BRK instruction */
@@ -582,26 +599,6 @@ int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct
kvm_sw_breakpoint *bp)
return 0;
}
-int kvm_arch_insert_hw_breakpoint(target_ulong addr,
- target_ulong len, int type)
-{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
-return -EINVAL;
-}
-
-int kvm_arch_remove_hw_breakpoint(target_ulong addr,
- target_ulong len, int type)
-{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
-return -EINVAL;
-}
-
-
-void kvm_arch_remove_all_hw_breakpoints(void)
-{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
-}
-
void kvm_arch_init_irq_routing(KVMState *s)
{
}
diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
index 8cf3a62..dbe81a7 100644
--- a/target-arm/kvm64.c
+++ b/target-arm/kvm64.c
@@ -2,6 +2,7 @@
* ARM implementation of KVM hooks, 64 bit specific code
*
* Copyright Mian-M. Hamayun 2013, Virtual Open Systems
+ * Copyright Alex Bennée 2014, Linaro
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
@@ -12,11 +13,17 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include "qemu-common.h"
#include "qemu/timer.h"
+#include "qemu/host-utils.h"
+#include "qemu/error-report.h"
+#include "exec/gdbstub.h"
#include "sysemu/sysemu.h"
#include "sysemu/kvm.h"
#include "kvm_arm.h"
@@ -24,6 +31,312 @@
#include "internals.h"
#include "hw/arm/arm.h"
+/* Max and current break/watch point counts */
+int max_hw_bp, max_hw_wp;
+int cur_hw_bp, cur_hw_wp;
+struct kvm_guest_debug_arch guest_debug_registers;
+
+/**
+ * kvm_arm_init_debug()
+ * @cs: CPUState
+ *
+ * kvm_check_extension returns 0 if we have no debug registers or the
+ * number we have.
+ *
+ */
+static void kvm_arm_init_debug(CPUState *cs)
+{
+max_hw_wp = kvm_check_extension(cs->kvm_state, KVM_CAP_GUEST_DEBUG_HW_WPS);
+max_hw_bp = kvm_check_extension(cs->kvm_state, KVM_CAP_GUEST_DEBUG_HW_BPS);
+return;
+}
+
+/**
+ * insert_hw_breakpoint()
+ * @addr: address of breakpoint
+ *
+ * See ARM ARM D2.9.1 for details but here we are only going to create
+ * simple un-linked breakpoints (i.e. we don't chain breakpoints
+ * together to match address and context or vmid). The hardware is
+ * capable of fancier matching but that will require exposing that
+ * fanciness to GDB's interface
+ *
+ * D7.3.2 DBGBCR_EL1, Debug Breakpoint Control Registers
+ *
+ * 31 24 23 20 19 16 15 14 13 12 9 8 5 43 2 1 0
+ * +--+--+---+-++--+-+--+-+---+
+ * | RES0 | BT | LBN | SSC | HMC| RES0 | BAS | RES0 | PMC | E |
+ * +--
[PATCH v2 2/4] target-arm: kvm - implement software breakpoints
These don't involve messing around with debug registers, just setting
the breakpoint instruction in memory. GDB will not use this mechanism if
it can't access the memory to write the breakpoint.
All the kernel has to do is ensure the hypervisor traps the breakpoint
exceptions and returns to userspace.
Signed-off-by: Alex Bennée
--
v2
- handle debug exit with new hsr exception info
- add verbosity to UNIMP message
diff --git a/target-arm/kvm.c b/target-arm/kvm.c
index 72c1fa1..290c1fe 100644
--- a/target-arm/kvm.c
+++ b/target-arm/kvm.c
@@ -25,6 +25,7 @@
#include "hw/arm/arm.h"
const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
+KVM_CAP_INFO(SET_GUEST_DEBUG),
KVM_CAP_LAST_INFO
};
@@ -466,9 +467,57 @@ void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
{
}
+/* See ARM ARM D7.2.27 ESR_ELx, Exception Syndrome Register
+**
+** To minimise translating between kernel and user-space the kernel
+** ABI just provides user-space with the full exception syndrome
+** register value to be decoded in QEMU.
+*/
+
+#define HSR_EC_SHIFT26
+#define HSR_EC_SW_BKPT 0x3c
+
+static int kvm_handle_debug(CPUState *cs, struct kvm_run *run)
+{
+struct kvm_debug_exit_arch *arch_info = &run->debug.arch;
+int hsr_ec = arch_info->hsr >> HSR_EC_SHIFT;
+
+switch (hsr_ec) {
+case HSR_EC_SW_BKPT:
+if (kvm_find_sw_breakpoint(cs, arch_info->pc)) {
+return true;
+}
+break;
+default:
+error_report("%s: unhandled debug exit (%x, %llx)\n",
+ __func__, arch_info->hsr, arch_info->pc);
+}
+
+/* If we don't handle this it could be it really is for the
+ guest to handle */
+qemu_log_mask(LOG_UNIMP,
+ "%s: re-injecting exception not yet implemented (0x%x,
%llx)\n",
+ __func__, hsr_ec, arch_info->pc);
+
+return false;
+}
+
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
-return 0;
+int ret = 0;
+
+switch (run->exit_reason) {
+case KVM_EXIT_DEBUG:
+if (kvm_handle_debug(cs, run)) {
+ret = EXCP_DEBUG;
+} /* otherwise return to guest */
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
+ __func__, run->exit_reason);
+break;
+}
+return ret;
}
bool kvm_arch_stop_on_emulation_error(CPUState *cs)
@@ -493,14 +542,33 @@ int kvm_arch_on_sigbus(int code, void *addr)
void kvm_arch_update_guest_debug(CPUState *cs, struct kvm_guest_debug *dbg)
{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
+if (kvm_sw_breakpoints_active(cs)) {
+dbg->control |= KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP;
+}
}
-int kvm_arch_insert_sw_breakpoint(CPUState *cs,
- struct kvm_sw_breakpoint *bp)
+/* C6.6.29 BRK instruction */
+int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
-return -EINVAL;
+static const uint32_t brk = 0xd420;
+
+if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&bp->saved_insn, 4, 0) ||
+cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&brk, 4, 1)) {
+return -EINVAL;
+}
+return 0;
+}
+
+int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp)
+{
+static uint32_t brk;
+
+if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&brk, 4, 0) ||
+brk != 0xd420 ||
+cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&bp->saved_insn, 4, 1)) {
+return -EINVAL;
+}
+return 0;
}
int kvm_arch_insert_hw_breakpoint(target_ulong addr,
@@ -517,12 +585,6 @@ int kvm_arch_remove_hw_breakpoint(target_ulong addr,
return -EINVAL;
}
-int kvm_arch_remove_sw_breakpoint(CPUState *cs,
- struct kvm_sw_breakpoint *bp)
-{
-qemu_log_mask(LOG_UNIMP, "%s: not implemented\n", __func__);
-return -EINVAL;
-}
void kvm_arch_remove_all_hw_breakpoints(void)
{
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] linux-headers: partial sync from my kernel tree (DEV)
I assume I'll properly merge the KVM Headers direct from Linux when
done. These headers came from:
https://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/guest-debug/4.0-rc6-v2
Signed-off-by: Alex Bennée
---
v2
- update ABI to include ->far
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index 3ef77a4..73f21e4 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -100,10 +100,25 @@ struct kvm_sregs {
struct kvm_fpu {
};
+/*
+ * See ARM ARM D7.3: Debug Registers
+ *
+ * The control registers are architecturally defined as 32 bits but are
+ * stored as 64 bit values along side the value registers and aligned
+ * with the rest 64 bit registers in the normal CPU context.
+ */
+#define KVM_ARM_NDBG_REGS 16
struct kvm_guest_debug_arch {
+ __u64 dbg_bcr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_bvr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_wcr[KVM_ARM_NDBG_REGS];
+ __u64 dbg_wvr[KVM_ARM_NDBG_REGS];
};
struct kvm_debug_exit_arch {
+ __u64 pc;
+ __u32 hsr;
+ __u64 far; /* used for watchpoints */
};
struct kvm_sync_regs {
@@ -207,4 +222,11 @@ struct kvm_arch_memory_slot {
#endif
+/*
+ * Architecture related debug defines - upper 16 bits of
+ * kvm_guest_debug->control
+ */
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
+
#endif /* __ARM_KVM_H__ */
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index ab4d473..1731569 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -310,8 +310,8 @@ struct kvm_guest_debug_arch {
* and upper 16 bits are architecture specific. Architecture specific defines
* that ioctl is for setting hardware breakpoint or software breakpoint.
*/
-#define KVM_GUESTDBG_USE_SW_BP 0x0001
-#define KVM_GUESTDBG_USE_HW_BP 0x0002
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
/* definition of registers in kvm_run */
struct kvm_sync_regs {
diff --git a/linux-headers/asm-x86/kvm.h b/linux-headers/asm-x86/kvm.h
index d7dcef5..1438202 100644
--- a/linux-headers/asm-x86/kvm.h
+++ b/linux-headers/asm-x86/kvm.h
@@ -250,8 +250,8 @@ struct kvm_debug_exit_arch {
__u64 dr7;
};
-#define KVM_GUESTDBG_USE_SW_BP 0x0001
-#define KVM_GUESTDBG_USE_HW_BP 0x0002
+#define KVM_GUESTDBG_USE_SW_BP __KVM_GUESTDBG_USE_SW_BP
+#define KVM_GUESTDBG_USE_HW_BP __KVM_GUESTDBG_USE_HW_BP
#define KVM_GUESTDBG_INJECT_DB 0x0004
#define KVM_GUESTDBG_INJECT_BP 0x0008
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 60a54c8..fa6c2ac 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -226,6 +226,7 @@ struct kvm_run {
__u32 count;
__u64 data_offset; /* relative to kvm_run start */
} io;
+ /* KVM_EXIT_DEBUG */
struct {
struct kvm_debug_exit_arch arch;
} debug;
@@ -274,6 +275,7 @@ struct kvm_run {
__u32 data;
__u8 is_write;
} dcr;
+ /* KVM_EXIT_INTERNAL_ERROR */
struct {
__u32 suberror;
/* Available with KVM_CAP_INTERNAL_ERROR_DATA: */
@@ -284,6 +286,7 @@ struct kvm_run {
struct {
__u64 gprs[32];
} osi;
+ /* KVM_EXIT_PAPR_HCALL */
struct {
__u64 nr;
__u64 ret;
@@ -522,8 +525,16 @@ struct kvm_s390_irq {
/* for KVM_SET_GUEST_DEBUG */
-#define KVM_GUESTDBG_ENABLE0x0001
-#define KVM_GUESTDBG_SINGLESTEP0x0002
+#define KVM_GUESTDBG_ENABLE(1 << 0)
+#define KVM_GUESTDBG_SINGLESTEP(1 << 1)
+
+/*
+ * Architecture specific stuff uses the top 16 bits of the field,
+ * however there is some shared commonality for the common cases
+ */
+#define __KVM_GUESTDBG_USE_SW_BP (1 << 16)
+#define __KVM_GUESTDBG_USE_HW_BP (1 << 17)
+
struct kvm_guest_debug {
__u32 control;
@@ -760,6 +771,8 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_PPC_ENABLE_HCALL 104
#define KVM_CAP_CHECK_EXTENSION_VM 105
#define KVM_CAP_S390_USER_SIGP 106
+#define KVM_CAP_GUEST_DEBUG_HW_BPS 107
+#define KVM_CAP_GUEST_DEBUG_HW_WPS 108
#ifdef KVM_CAP_IRQ_ROUTING
--
2.3.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] arm: Use bool function return values of true/false not 1/0
On 31/03/2015 01:45, Joe Perches wrote:
> Use the normal return values for bool functions
>
> Signed-off-by: Joe Perches
> ---
> arch/arm/include/asm/dma-mapping.h | 8
> arch/arm/include/asm/kvm_emulate.h | 2 +-
> arch/arm/mach-omap2/powerdomain.c | 14 +++---
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index b52101d..166e1e1 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -151,18 +151,18 @@ static inline bool dma_capable(struct device *dev,
> dma_addr_t addr, size_t size)
> u64 limit, mask;
>
> if (!dev->dma_mask)
> - return 0;
> + return false;
>
> mask = *dev->dma_mask;
>
> limit = (mask + 1) & ~mask;
> if (limit && size > limit)
> - return 0;
> + return false;
>
> if ((addr | (addr + size - 1)) & ~mask)
> - return 0;
> + return false;
>
> - return 1;
> + return true;
> }
>
> static inline void dma_mark_clean(void *addr, size_t size) { }
> diff --git a/arch/arm/include/asm/kvm_emulate.h
> b/arch/arm/include/asm/kvm_emulate.h
> index a9c80a2..ad200a0 100644
> --- a/arch/arm/include/asm/kvm_emulate.h
> +++ b/arch/arm/include/asm/kvm_emulate.h
> @@ -51,7 +51,7 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu,
> unsigned long hcr)
>
> static inline bool vcpu_mode_is_32bit(struct kvm_vcpu *vcpu)
> {
> - return 1;
> + return true;
> }
>
> static inline unsigned long *vcpu_pc(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 78af6d8..897f9fb 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -950,7 +950,7 @@ int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm)
> */
> bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
> {
> - return (pwrdm && pwrdm->flags & PWRDM_HAS_HDWR_SAR) ? 1 : 0;
> + return pwrdm && (pwrdm->flags & PWRDM_HAS_HDWR_SAR);
> }
>
> int pwrdm_state_switch_nolock(struct powerdomain *pwrdm)
> @@ -1185,24 +1185,24 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
> *pwrdm)
> if (!pwrdm) {
> pr_debug("powerdomain: %s: invalid powerdomain pointer\n",
>__func__);
> - return 1;
> + return true;
> }
>
> if (pwrdm->pwrsts & PWRSTS_OFF)
> - return 1;
> + return true;
>
> if (pwrdm->pwrsts & PWRSTS_RET) {
> if (pwrdm->pwrsts_logic_ret & PWRSTS_OFF)
> - return 1;
> + return true;
>
> for (i = 0; i < pwrdm->banks; i++)
> if (pwrdm->pwrsts_mem_ret[i] & PWRSTS_OFF)
> - return 1;
> + return true;
> }
>
> for (i = 0; i < pwrdm->banks; i++)
> if (pwrdm->pwrsts_mem_on[i] & PWRSTS_OFF)
> - return 1;
> + return true;
>
> - return 0;
> + return false;
> }
>
Marc/Christoffer, please pick this up yourself.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] arm: Use bool function return values of true/false not 1/0
* Joe Perches [150330 16:47]:
> Use the normal return values for bool functions
>
> Signed-off-by: Joe Perches
Acked-by: Tony Lindgren
> ---
> arch/arm/include/asm/dma-mapping.h | 8
> arch/arm/include/asm/kvm_emulate.h | 2 +-
> arch/arm/mach-omap2/powerdomain.c | 14 +++---
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index b52101d..166e1e1 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -151,18 +151,18 @@ static inline bool dma_capable(struct device *dev,
> dma_addr_t addr, size_t size)
> u64 limit, mask;
>
> if (!dev->dma_mask)
> - return 0;
> + return false;
>
> mask = *dev->dma_mask;
>
> limit = (mask + 1) & ~mask;
> if (limit && size > limit)
> - return 0;
> + return false;
>
> if ((addr | (addr + size - 1)) & ~mask)
> - return 0;
> + return false;
>
> - return 1;
> + return true;
> }
>
> static inline void dma_mark_clean(void *addr, size_t size) { }
> diff --git a/arch/arm/include/asm/kvm_emulate.h
> b/arch/arm/include/asm/kvm_emulate.h
> index a9c80a2..ad200a0 100644
> --- a/arch/arm/include/asm/kvm_emulate.h
> +++ b/arch/arm/include/asm/kvm_emulate.h
> @@ -51,7 +51,7 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu,
> unsigned long hcr)
>
> static inline bool vcpu_mode_is_32bit(struct kvm_vcpu *vcpu)
> {
> - return 1;
> + return true;
> }
>
> static inline unsigned long *vcpu_pc(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 78af6d8..897f9fb 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -950,7 +950,7 @@ int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm)
> */
> bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
> {
> - return (pwrdm && pwrdm->flags & PWRDM_HAS_HDWR_SAR) ? 1 : 0;
> + return pwrdm && (pwrdm->flags & PWRDM_HAS_HDWR_SAR);
> }
>
> int pwrdm_state_switch_nolock(struct powerdomain *pwrdm)
> @@ -1185,24 +1185,24 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
> *pwrdm)
> if (!pwrdm) {
> pr_debug("powerdomain: %s: invalid powerdomain pointer\n",
>__func__);
> - return 1;
> + return true;
> }
>
> if (pwrdm->pwrsts & PWRSTS_OFF)
> - return 1;
> + return true;
>
> if (pwrdm->pwrsts & PWRSTS_RET) {
> if (pwrdm->pwrsts_logic_ret & PWRSTS_OFF)
> - return 1;
> + return true;
>
> for (i = 0; i < pwrdm->banks; i++)
> if (pwrdm->pwrsts_mem_ret[i] & PWRSTS_OFF)
> - return 1;
> + return true;
> }
>
> for (i = 0; i < pwrdm->banks; i++)
> if (pwrdm->pwrsts_mem_on[i] & PWRSTS_OFF)
> - return 1;
> + return true;
>
> - return 0;
> + return false;
> }
> --
> 2.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/25] x86: Use bool function return values of true/false not 1/0
On 31/03/2015 01:46, Joe Perches wrote: > Use the normal return values for bool functions > > Signed-off-by: Joe Perches > --- > arch/x86/include/asm/archrandom.h | 2 +- > arch/x86/include/asm/dma-mapping.h | 2 +- > arch/x86/include/asm/kvm_para.h| 2 +- > arch/x86/kvm/cpuid.h | 2 +- > arch/x86/kvm/vmx.c | 72 > +++--- > 5 files changed, 40 insertions(+), 40 deletions(-) Applied arch/x86/include/asm/kvm_para.h and arch/x86/kvm/* parts, thanks. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 0/8] KVM: s390: Features and fixes for 4.1 (kvm/next)
On 31/03/2015 15:01, Christian Borntraeger wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git > tags/kvm-s390-next-20150331 Looks good, pulled. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] arm: Use bool function return values of true/false not 1/0
On Tue, 31 Mar 2015 16:58:28 +0100
Paolo Bonzini wrote:
> On 31/03/2015 01:45, Joe Perches wrote:
> > Use the normal return values for bool functions
> >
> > Signed-off-by: Joe Perches
> > ---
> > arch/arm/include/asm/dma-mapping.h | 8
> > arch/arm/include/asm/kvm_emulate.h | 2 +-
> > arch/arm/mach-omap2/powerdomain.c | 14 +++---
> > 3 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/dma-mapping.h
> > b/arch/arm/include/asm/dma-mapping.h
> > index b52101d..166e1e1 100644
> > --- a/arch/arm/include/asm/dma-mapping.h
> > +++ b/arch/arm/include/asm/dma-mapping.h
> > @@ -151,18 +151,18 @@ static inline bool dma_capable(struct device *dev,
> > dma_addr_t addr, size_t size)
> > u64 limit, mask;
> >
> > if (!dev->dma_mask)
> > - return 0;
> > + return false;
> >
> > mask = *dev->dma_mask;
> >
> > limit = (mask + 1) & ~mask;
> > if (limit && size > limit)
> > - return 0;
> > + return false;
> >
> > if ((addr | (addr + size - 1)) & ~mask)
> > - return 0;
> > + return false;
> >
> > - return 1;
> > + return true;
> > }
> >
> > static inline void dma_mark_clean(void *addr, size_t size) { }
> > diff --git a/arch/arm/include/asm/kvm_emulate.h
> > b/arch/arm/include/asm/kvm_emulate.h
> > index a9c80a2..ad200a0 100644
> > --- a/arch/arm/include/asm/kvm_emulate.h
> > +++ b/arch/arm/include/asm/kvm_emulate.h
> > @@ -51,7 +51,7 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu,
> > unsigned long hcr)
> >
> > static inline bool vcpu_mode_is_32bit(struct kvm_vcpu *vcpu)
> > {
> > - return 1;
> > + return true;
> > }
> >
> > static inline unsigned long *vcpu_pc(struct kvm_vcpu *vcpu)
> > diff --git a/arch/arm/mach-omap2/powerdomain.c
> > b/arch/arm/mach-omap2/powerdomain.c
> > index 78af6d8..897f9fb 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -950,7 +950,7 @@ int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm)
> > */
> > bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
> > {
> > - return (pwrdm && pwrdm->flags & PWRDM_HAS_HDWR_SAR) ? 1 : 0;
> > + return pwrdm && (pwrdm->flags & PWRDM_HAS_HDWR_SAR);
> > }
> >
> > int pwrdm_state_switch_nolock(struct powerdomain *pwrdm)
> > @@ -1185,24 +1185,24 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
> > *pwrdm)
> > if (!pwrdm) {
> > pr_debug("powerdomain: %s: invalid powerdomain pointer\n",
> > __func__);
> > - return 1;
> > + return true;
> > }
> >
> > if (pwrdm->pwrsts & PWRSTS_OFF)
> > - return 1;
> > + return true;
> >
> > if (pwrdm->pwrsts & PWRSTS_RET) {
> > if (pwrdm->pwrsts_logic_ret & PWRSTS_OFF)
> > - return 1;
> > + return true;
> >
> > for (i = 0; i < pwrdm->banks; i++)
> > if (pwrdm->pwrsts_mem_ret[i] & PWRSTS_OFF)
> > - return 1;
> > + return true;
> > }
> >
> > for (i = 0; i < pwrdm->banks; i++)
> > if (pwrdm->pwrsts_mem_on[i] & PWRSTS_OFF)
> > - return 1;
> > + return true;
> >
> > - return 0;
> > + return false;
> > }
> >
>
> Marc/Christoffer, please pick this up yourself.
Given that it touches a range of completely unrelated files, for the
KVM part:
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 0/8] KVM: s390: Features and fixes for 4.1 (kvm/next)
On 31/03/2015 18:11, Paolo Bonzini wrote: > > > On 31/03/2015 15:01, Christian Borntraeger wrote: >> git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git >> tags/kvm-s390-next-20150331 > > Looks good, pulled. Oops, spoke too soon! It conflicts with the MIPS pull request due to overlapping capability numbers. Please use 113 and 114; since the MIPS pull request is in kvm/queue only, do not rebase: just fix the two numbers and I'll resolve the conflict myself. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
2015-03-31 17:56+0300, Andrey Korolyov:
> > Chasing the culprit this way could take a long time, so a new tracepoint
> > that shows if 0xef is set on entry would let us guess the bug faster ...
> >
> > Please provide a failing trace with the following patch:
>
> Thanks, please see below:
>
> http://xdel.ru/downloads/kvm-e5v2-issue/new-tracepoint-fail-with-apicv.dat.gz
qemu-system-x86-4022 [006] 255.915978:
kvm_entry:vcpu 0
kvm_emulate_insn: f:d275: ea 7a d2 00 f0
kvm_emulate_insn: f:d27a: 2e 0f 01 1e f0 6c
kvm_emulate_insn: f:d280: 31 c0
kvm_emulate_insn: f:d282: 8e e0
kvm_emulate_insn: f:d284: 8e e8
kvm_emulate_insn: f:d286: 8e c0
kvm_emulate_insn: f:d288: 8e d8
kvm_emulate_insn: f:d28a: 8e d0
kvm_entry:vcpu 0
kvm_0xef: irr clear, isr clear, vmcs 0x0
kvm_exit: reason EPT_VIOLATION rip 0x8dd0 info 184 0
kvm_page_fault: address f8dd0 error_code 184
kvm_entry:vcpu 0
kvm_0xef: irr clear, isr clear, vmcs 0x0
kvm_exit: reason EPT_VIOLATION rip 0x76d6 info 184 0
kvm_page_fault: address f76d6 error_code 184
kvm_entry:vcpu 0
kvm_0xef: irr clear, isr clear, vmcs 0x0
kvm_exit: reason EXCEPTION_NMI rip 0xd331 info 0 8b0d
kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17)
Ok, nothing obvious here either ... I've desperately added all
information I know about. Please run it again, thanks.
(The patch has to be applied instead of the previous one.)
---
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 7c7bc8bef21f..f986636ad9d0 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -742,6 +742,41 @@ TRACE_EVENT(kvm_emulate_insn,
#define trace_kvm_emulate_insn_start(vcpu) trace_kvm_emulate_insn(vcpu, 0)
#define trace_kvm_emulate_insn_failed(vcpu) trace_kvm_emulate_insn(vcpu, 1)
+TRACE_EVENT(kvm_0xef,
+ TP_PROTO(bool irr, bool isr, u32 info, bool on, bool pir, u16 status),
+ TP_ARGS(irr, isr, info, on, pir, status),
+
+ TP_STRUCT__entry(
+ __field(bool, irr )
+ __field(bool, isr )
+ __field(u32, info)
+ __field(bool, on )
+ __field(bool, pir )
+ __field(u8,rvi )
+ __field(u8,svi )
+ ),
+
+ TP_fast_assign(
+ __entry->irr = irr;
+ __entry->isr = isr;
+ __entry->info = info;
+ __entry->on = on;
+ __entry->pir = pir;
+ __entry->rvi = status & 0xff;
+ __entry->svi = status >> 8;
+ ),
+
+ TP_printk("irr %s, isr %s, info 0x%x, on %s, pir %s, rvi 0x%x, svi
0x%x",
+ __entry->irr ? "set " : "clear",
+ __entry->isr ? "set " : "clear",
+ __entry->info,
+ __entry->on ? "set " : "clear",
+ __entry->pir ? "set " : "clear",
+ __entry->rvi,
+ __entry->svi
+)
+ );
+
TRACE_EVENT(
vcpu_match_mmio,
TP_PROTO(gva_t gva, gpa_t gpa, bool write, bool gpa_match),
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index eee63dc33d89..b461edc93d53 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5047,6 +5047,25 @@ static int handle_machine_check(struct kvm_vcpu *vcpu)
return 1;
}
+#define VEC_POS(v) ((v) & (32 - 1))
+#define REG_POS(v) (((v) >> 5) << 4)
+static inline int apic_test_vector(int vec, void *bitmap)
+{
+ return test_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
+}
+
+static inline void random_trace(struct kvm_vcpu *vcpu)
+{
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+ trace_kvm_0xef(apic_test_vector(0xef, vcpu->arch.apic->regs + APIC_IRR),
+ apic_test_vector(0xef, vcpu->arch.apic->regs + APIC_ISR),
+ vmcs_read32(VM_ENTRY_INTR_INFO_FIELD),
+ test_bit(POSTED_INTR_ON, (unsigned long
*)&vmx->pi_desc.control),
+ test_bit(0xef, (unsigned long *)vmx->pi_desc.pir),
+ vmcs_read16(GUEST_INTR_STATUS));
+}
+
static int handle_exception(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -5077,6 +5096,8 @@ static int handle_exception(struct kvm_vcpu *vcpu)
return 1;
}
+ random_trace(vcpu);
+
error_code = 0;
if (intr_info & INTR_INFO_DELIVER_CODE_MASK)
error_code = vmcs_read32(VM_EXIT_INTR_ERROR_CODE);
@@ -8143,6 +8164,8 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
if (vmx->emulation_required)
return;
+ random_trace(vcpu);
+
if (vmx->ple_window_dirty) {
vmx->ple_window_dirty = false;
vmcs_write32(PLE_WINDOW, vmx->ple_window);
@@ -8312,6
Re: [GSoC] project proposal
On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini wrote: > On 18/03/2015 18:05, Catalin Vasile wrote: >> cryptodev is not merged into upstream from what I know. > > Yes, but QEMU runs on non-Linux platforms too. Of course doing > vhost+driver or gnutls+driver would be already more than enough for the > summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). That approach is more beneficial in the long run. It will allow other applications to use the Crypto API too. vhost is good for exploiting kernel-only functionality (usually due to security/reliability boundaries). In this case the only reason for vhost is that the userspace API isn't ready yet. Use the opportunity to contribute to that effort instead of working around it. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v5 06/13] VFIO: platform: add vfio_external_{mask|is_active|set_automasked}
On Thu, 2015-03-19 at 15:55 +0100, Eric Auger wrote:
> Introduces 3 new external functions aimed at doining some actions
> on VFIO platform devices:
> - mask a VFIO IRQ
> - get the active status of a VFIO IRQ (active at interrupt
> controller level or masked by the level-sensitive automasking).
> - change the automasked property and the VFIO handler
>
> Note there is no way to discriminate between user-space
> masking and automasked handler masking. As a consequence, is_active
> will return true in case the IRQ was masked by the user-space.
>
> Signed-off-by: Eric Auger
>
> ---
>
> V4: creation
> ---
> drivers/vfio/platform/vfio_platform_irq.c | 43
> +++
> include/linux/vfio.h | 14 ++
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/vfio/platform/vfio_platform_irq.c
> b/drivers/vfio/platform/vfio_platform_irq.c
> index 8eb65c1..49994cb 100644
> --- a/drivers/vfio/platform/vfio_platform_irq.c
> +++ b/drivers/vfio/platform/vfio_platform_irq.c
> @@ -231,6 +231,49 @@ static int vfio_set_trigger(struct vfio_platform_device
> *vdev, int index,
> return 0;
> }
>
> +void vfio_external_mask(struct vfio_platform_device *vdev, int index)
> +{
> + vfio_platform_mask(&vdev->irqs[index]);
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_mask);
> +
> +bool vfio_external_is_active(struct vfio_platform_device *vdev, int index)
> +{
> + unsigned long flags;
> + struct vfio_platform_irq *irq = &vdev->irqs[index];
> + bool active, masked, outstanding;
> + int ret;
> +
> + spin_lock_irqsave(&irq->lock, flags);
> +
> + ret = irq_get_irqchip_state(irq->hwirq, IRQCHIP_STATE_ACTIVE, &active);
> + BUG_ON(ret);
> + masked = irq->masked;
> + outstanding = active || masked;
> +
> + spin_unlock_irqrestore(&irq->lock, flags);
> + return outstanding;
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_is_active);
> +
> +void vfio_external_set_automasked(struct vfio_platform_device *vdev,
> + int index, bool automasked)
> +{
> + unsigned long flags;
> + struct vfio_platform_irq *irq = &vdev->irqs[index];
> +
> + spin_lock_irqsave(&irq->lock, flags);
> + if (automasked) {
> + irq->flags |= VFIO_IRQ_INFO_AUTOMASKED;
> + irq->handler = vfio_automasked_irq_handler;
> + } else {
> + irq->flags &= ~VFIO_IRQ_INFO_AUTOMASKED;
> + irq->handler = vfio_irq_handler;
> + }
> + spin_unlock_irqrestore(&irq->lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(vfio_external_set_automasked);
> +
This is where the abstraction breaks down. These are
vfio_external_foo() interfaces, yet they assume a specific type of
device, a vfio platform device. Either the name should reflect that or
they should be hosted in vfio-core with a callout to the device specific
implementations. Can we make kvm-vfio deal only in struct vfio_device
and struct device?
> static int vfio_platform_set_irq_trigger(struct vfio_platform_device *vdev,
>unsigned index, unsigned start,
>unsigned count, uint32_t flags,
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index b18c38f..7aa6330 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -105,6 +105,20 @@ extern struct vfio_device
> *vfio_device_get_external_user(struct file *filep);
> extern void vfio_device_put_external_user(struct vfio_device *vdev);
> extern struct device *vfio_external_base_device(struct vfio_device *vdev);
>
> +struct vfio_platform_device;
> +extern void vfio_external_mask(struct vfio_platform_device *vdev, int index);
> +/*
> + * returns whether the VFIO IRQ is active:
> + * true if not yet deactivated at interrupt controller level or if
> + * automasked (level sensitive IRQ). Unfortunately there is no way to
> + * discriminate between handler auto-masking and user-space masking
> + */
> +extern bool vfio_external_is_active(struct vfio_platform_device *vdev,
> + int index);
> +
> +extern void vfio_external_set_automasked(struct vfio_platform_device *vdev,
> + int index, bool automasked);
> +
> struct pci_dev;
> #ifdef CONFIG_EEH
> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v5 08/13] KVM: kvm-vfio: wrappers for vfio_external_{mask|is_active|set_automasked}
On Thu, 2015-03-19 at 15:55 +0100, Eric Auger wrote:
> Those 3 new wrapper functions call the respective VFIO external
> functions.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v4: creation
> ---
> include/linux/vfio.h | 8 +++-
> virt/kvm/vfio.c | 44
> 2 files changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 7aa6330..78c1202 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -108,14 +108,12 @@ extern struct device *vfio_external_base_device(struct
> vfio_device *vdev);
> struct vfio_platform_device;
> extern void vfio_external_mask(struct vfio_platform_device *vdev, int index);
> /*
> - * returns whether the VFIO IRQ is active:
> - * true if not yet deactivated at interrupt controller level or if
> - * automasked (level sensitive IRQ). Unfortunately there is no way to
> - * discriminate between handler auto-masking and user-space masking
> + * returns whether the VFIO IRQ is active at interrupt controller level
> + * or VFIO-masked. Note that if the use-space masked the IRQ index it
> + * cannot be discriminated from automasked handler situation.
> */
> extern bool vfio_external_is_active(struct vfio_platform_device *vdev,
> int index);
> -
> extern void vfio_external_set_automasked(struct vfio_platform_device *vdev,
>int index, bool automasked);
>
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 80a45e4..c995e51 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -134,6 +134,50 @@ static void kvm_vfio_put_vfio_device(struct vfio_device
> *vdev)
> kvm_vfio_device_put_external_user(vdev);
> }
>
> +bool kvm_vfio_external_is_active(struct vfio_platform_device *vpdev,
> + int index)
> +{
> + bool (*fn)(struct vfio_platform_device *, int index);
> + bool active;
> +
> + fn = symbol_get(vfio_external_is_active);
> + if (!fn)
> + return -1;
> +
> + active = fn(vpdev, index);
> +
> + symbol_put(vfio_external_is_active);
> + return active;
> +}
> +
> +void kvm_vfio_external_mask(struct vfio_platform_device *vpdev,
> + int index)
> +{
> + void (*fn)(struct vfio_platform_device *, int index);
> +
> + fn = symbol_get(vfio_external_mask);
> + if (!fn)
> + return;
> +
> + fn(vpdev, index);
> +
> + symbol_put(vfio_external_mask);
> +}
> +
> +void kvm_vfio_external_set_automasked(struct vfio_platform_device *vpdev,
> + int index, bool automasked)
> +{
> + void (*fn)(struct vfio_platform_device *, int index, bool automasked);
> +
> + fn = symbol_get(vfio_external_set_automasked);
> + if (!fn)
> + return;
> +
> + fn(vpdev, index, automasked);
> +
> + symbol_put(vfio_external_set_automasked);
> +}
> +
I think we'd really prefer not to be dealing with vfio_platform_devices
here.
> static bool kvm_vfio_group_is_coherent(struct vfio_group *vfio_group)
> {
> long (*fn)(struct vfio_group *, unsigned long);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v5 12/13] KVM: kvm-vfio: generic forwarding control
On Thu, 2015-03-19 at 15:55 +0100, Eric Auger wrote:
> This patch introduces a new KVM_DEV_VFIO_DEVICE group.
>
> This is a new control channel which enables KVM to cooperate with
> viable VFIO devices.
>
> The patch introduces 2 attributes for this group:
> KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ.
> Their purpose is to turn a VFIO device IRQ into a forwarded IRQ and
> respectively unset the feature.
>
> The generic part introduced here interact with VFIO, genirq, KVM while
> the architecture specific part mostly takes care of the virtual interrupt
> controller programming.
>
> Architecture specific implementation is enabled when
> __KVM_HAVE_ARCH_KVM_VFIO_FORWARD is set. When not set those
> functions are void.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v3 -> v4:
> - use new kvm_vfio_dev_irq struct
> - improve error handling according to Alex comments
> - full rework or generic/arch specific split to accomodate for
> unforward that never fails
> - kvm_vfio_get_vfio_device and kvm_vfio_put_vfio_device removed from
> that patch file and introduced before (since also used by Feng)
> - guard kvm_vfio_control_irq_forward call with
> __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
>
> v2 -> v3:
> - add API comments in kvm_host.h
> - improve the commit message
> - create a private kvm_vfio_fwd_irq struct
> - fwd_irq_action replaced by a bool and removal of VFIO_IRQ_CLEANUP. This
> latter action will be handled in vgic.
> - add a vfio_device handle argument to kvm_arch_set_fwd_state. The goal is
> to move platform specific stuff in architecture specific code.
> - kvm_arch_set_fwd_state renamed into kvm_arch_vfio_set_forward
> - increment the ref counter each time we do an IRQ forwarding and decrement
> this latter each time one IRQ forward is unset. Simplifies the whole
> ref counting.
> - simplification of list handling: create, search, removal
>
> v1 -> v2:
> - __KVM_HAVE_ARCH_KVM_VFIO renamed into __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> - original patch file separated into 2 parts: generic part moved in vfio.c
> and ARM specific part(kvm_arch_set_fwd_state)
> ---
> include/linux/kvm_host.h | 47 +++
> virt/kvm/vfio.c | 311
> ++-
> 2 files changed, 355 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index f4e1829..8f17f87 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1042,6 +1042,15 @@ struct kvm_device_ops {
> unsigned long arg);
> };
>
> +/* internal self-contained structure describing a forwarded IRQ */
> +struct kvm_fwd_irq {
> + struct kvm *kvm; /* VM to inject the GSI into */
> + struct vfio_device *vdev; /* vfio device the IRQ belongs to */
> + __u32 index; /* VFIO device IRQ index */
> + __u32 subindex; /* VFIO device IRQ subindex */
> + __u32 gsi; /* gsi, ie. virtual IRQ number */
> +};
> +
> void kvm_device_get(struct kvm_device *dev);
> void kvm_device_put(struct kvm_device *dev);
> struct kvm_device *kvm_device_from_filp(struct file *filp);
> @@ -1065,6 +1074,44 @@ inline void kvm_arch_resume_guest(struct kvm *kvm) {}
>
> #endif
>
> +#ifdef __KVM_HAVE_ARCH_KVM_VFIO_FORWARD
> +/**
> + * kvm_arch_set_forward - Sets forwarding for a given IRQ
> + *
> + * @kvm: handle to the VM
> + * @host_irq: physical IRQ number
> + * @guest_irq: virtual IRQ number
> + * returns 0 on success, < 0 on failure
> + */
> +int kvm_arch_set_forward(struct kvm *kvm,
> + unsigned int host_irq, unsigned int guest_irq);
> +
> +/**
> + * kvm_arch_unset_forward - Unsets forwarding for a given IRQ
> + *
> + * @kvm: handle to the VM
> + * @host_irq: physical IRQ number
> + * @guest_irq: virtual IRQ number
> + * @active: returns whether the IRQ is active
> + */
> +void kvm_arch_unset_forward(struct kvm *kvm,
> + unsigned int host_irq,
> + unsigned int guest_irq,
> + bool *active);
> +
> +#else
> +static inline int kvm_arch_set_forward(struct kvm *kvm,
> +unsigned int host_irq,
> +unsigned int guest_irq)
> +{
> + return -ENOENT;
> +}
> +static inline void kvm_arch_unset_forward(struct kvm *kvm,
> + unsigned int host_irq,
> + unsigned int guest_irq,
> + bool *active) {}
> +#endif
> +
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
>
> static inline void kvm_vcpu_set_in_spin_loop(struct kvm_vcpu *vcpu, bool val)
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index c995e51..4847597 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -19,14 +19,30 @@
> #include
> #include
> #include "vfio.h"
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEBUG_FORWARD
> +#define DEBUG_UNFORWARD
The
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Tue, Mar 31, 2015 at 7:45 PM, Radim Krčmář wrote:
> 2015-03-31 17:56+0300, Andrey Korolyov:
>> > Chasing the culprit this way could take a long time, so a new tracepoint
>> > that shows if 0xef is set on entry would let us guess the bug faster ...
>> >
>> > Please provide a failing trace with the following patch:
>>
>> Thanks, please see below:
>>
>> http://xdel.ru/downloads/kvm-e5v2-issue/new-tracepoint-fail-with-apicv.dat.gz
>
> qemu-system-x86-4022 [006] 255.915978:
> kvm_entry:vcpu 0
> kvm_emulate_insn: f:d275: ea 7a d2 00 f0
> kvm_emulate_insn: f:d27a: 2e 0f 01 1e f0 6c
> kvm_emulate_insn: f:d280: 31 c0
> kvm_emulate_insn: f:d282: 8e e0
> kvm_emulate_insn: f:d284: 8e e8
> kvm_emulate_insn: f:d286: 8e c0
> kvm_emulate_insn: f:d288: 8e d8
> kvm_emulate_insn: f:d28a: 8e d0
> kvm_entry:vcpu 0
> kvm_0xef: irr clear, isr clear, vmcs 0x0
> kvm_exit: reason EPT_VIOLATION rip 0x8dd0 info 184 0
> kvm_page_fault: address f8dd0 error_code 184
> kvm_entry:vcpu 0
> kvm_0xef: irr clear, isr clear, vmcs 0x0
> kvm_exit: reason EPT_VIOLATION rip 0x76d6 info 184 0
> kvm_page_fault: address f76d6 error_code 184
> kvm_entry:vcpu 0
> kvm_0xef: irr clear, isr clear, vmcs 0x0
> kvm_exit: reason EXCEPTION_NMI rip 0xd331 info 0 8b0d
> kvm_userspace_exit: reason KVM_EXIT_INTERNAL_ERROR (17)
>
> Ok, nothing obvious here either ... I've desperately added all
> information I know about. Please run it again, thanks.
>
> (The patch has to be applied instead of the previous one.)
> ---
> diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
> index 7c7bc8bef21f..f986636ad9d0 100644
> --- a/arch/x86/kvm/trace.h
> +++ b/arch/x86/kvm/trace.h
> @@ -742,6 +742,41 @@ TRACE_EVENT(kvm_emulate_insn,
> #define trace_kvm_emulate_insn_start(vcpu) trace_kvm_emulate_insn(vcpu, 0)
> #define trace_kvm_emulate_insn_failed(vcpu) trace_kvm_emulate_insn(vcpu, 1)
>
> +TRACE_EVENT(kvm_0xef,
> + TP_PROTO(bool irr, bool isr, u32 info, bool on, bool pir, u16 status),
> + TP_ARGS(irr, isr, info, on, pir, status),
> +
> + TP_STRUCT__entry(
> + __field(bool, irr )
> + __field(bool, isr )
> + __field(u32, info)
> + __field(bool, on )
> + __field(bool, pir )
> + __field(u8,rvi )
> + __field(u8,svi )
> + ),
> +
> + TP_fast_assign(
> + __entry->irr = irr;
> + __entry->isr = isr;
> + __entry->info = info;
> + __entry->on = on;
> + __entry->pir = pir;
> + __entry->rvi = status & 0xff;
> + __entry->svi = status >> 8;
> + ),
> +
> + TP_printk("irr %s, isr %s, info 0x%x, on %s, pir %s, rvi 0x%x, svi
> 0x%x",
> + __entry->irr ? "set " : "clear",
> + __entry->isr ? "set " : "clear",
> + __entry->info,
> + __entry->on ? "set " : "clear",
> + __entry->pir ? "set " : "clear",
> + __entry->rvi,
> + __entry->svi
> +)
> + );
> +
> TRACE_EVENT(
> vcpu_match_mmio,
> TP_PROTO(gva_t gva, gpa_t gpa, bool write, bool gpa_match),
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index eee63dc33d89..b461edc93d53 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -5047,6 +5047,25 @@ static int handle_machine_check(struct kvm_vcpu *vcpu)
> return 1;
> }
>
> +#define VEC_POS(v) ((v) & (32 - 1))
> +#define REG_POS(v) (((v) >> 5) << 4)
> +static inline int apic_test_vector(int vec, void *bitmap)
> +{
> + return test_bit(VEC_POS(vec), (bitmap) + REG_POS(vec));
> +}
> +
> +static inline void random_trace(struct kvm_vcpu *vcpu)
> +{
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> +
> + trace_kvm_0xef(apic_test_vector(0xef, vcpu->arch.apic->regs +
> APIC_IRR),
> + apic_test_vector(0xef, vcpu->arch.apic->regs +
> APIC_ISR),
> + vmcs_read32(VM_ENTRY_INTR_INFO_FIELD),
> + test_bit(POSTED_INTR_ON, (unsigned long
> *)&vmx->pi_desc.control),
> + test_bit(0xef, (unsigned long *)vmx->pi_desc.pir),
> + vmcs_read16(GUEST_INTR_STATUS));
> +}
> +
> static int handle_exception(struct kvm_vcpu *vcpu)
> {
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> @@ -5077,6 +5096,8 @@ static int handle_exception(struct kvm_vcpu *vcpu)
> return 1;
> }
>
> + random_trace(vcpu);
> +
> error_code = 0;
> if (intr_info & INTR_INFO_DELIVER_CODE_MASK)
> error_code = vmcs_read32(VM_EXIT_INTR_ERROR_CODE);
> @@ -8143,6 +8164,8 @@ static void
Re: [Qemu-devel] E5-2620v2 - emulation stop error
Andrey Korolyov writes: ... > http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz > > Something a bit more interesting, but the mess is happening just > *after* NMI firing. What happens if NMI is turned off on the host ? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
Bandan Das writes: > Andrey Korolyov writes: > ... >> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz >> >> Something a bit more interesting, but the mess is happening just >> *after* NMI firing. > > What happens if NMI is turned off on the host ? Sorry, I meant the watchdog.. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] E5-2620v2 - emulation stop error
On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote: > Bandan Das writes: > >> Andrey Korolyov writes: >> ... >>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz >>> >>> Something a bit more interesting, but the mess is happening just >>> *after* NMI firing. >> >> What happens if NMI is turned off on the host ? > > Sorry, I meant the watchdog.. Thanks, everything goes well (as it probably should go there): http://xdel.ru/downloads/kvm-e5v2-issue/apicv-enabled-nmi-disabled.dat.gz -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Tue, Mar 31, 2015 at 01:21:05PM +0200, Michael Mueller wrote:
> On Mon, 30 Mar 2015 17:17:21 -0300
> Eduardo Habkost wrote:
>
> > On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> > > This patch implements a new QMP request named 'query-cpu-model'.
> > > It returns the cpu model of cpu 0 and its backing accelerator.
> > >
> > > request:
> > > {"execute" : "query-cpu-model" }
> > >
> > > answer:
> > > {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> >
> > If you are returning information about an existing CPU, why not just
> > extend the output of "query-cpus"?
> >
> > (Existing qmp_query_cpus() calls cpu_synchronize_state(), which may be
> > undesired. But in this case we could add an optional parameter to
> > disable the return of data that requires stopping the VCPU).
>
> Will the cpu_cpu_syncronize_state() really hurt in real life?
> query-cpus will be called only once a while...
>
I was just thinking about possible reasons you wouldn't want to reuse
query-cpus, and thought cpu_synchronize_state() call could be one of
them.
> I will prepare the extension of query-cpus as an option but initially
> without the optional parameter.
I agree we can simply add the new info to query-cpus without any extra
parameter, and (if really necessary) we can worry about optimizing it by
avoiding the cpu_synchronize_state() call later.
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> This patch implements a new QMP request named 'query-cpu-model'.
> It returns the cpu model of cpu 0 and its backing accelerator.
>
> request:
> {"execute" : "query-cpu-model" }
>
> answer:
> {"return" : {"name": "2827-ga2", "accel": "kvm" }}
>
> Alias names are resolved to their respective machine type and GA names
> already during cpu instantiation. Thus, also a cpu model like 'host'
> which is implemented as alias will return its normalized cpu model name.
>
> Furthermore the patch implements the following function:
>
> - s390_cpu_models_used(), returns true if S390 cpu models are in use
>
> Signed-off-by: Michael Mueller
> ---
[...]
> +static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
> +{
> +return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
> +}
How exactly is this information going to be used by clients? If getting
the correct type and ga values is important for them, maybe you could
add them as integer fields, instead of requiring clients to parse the
CPU model name?
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.13.y-ckt stable] Patch "MIPS: KVM: Deliver guest interrupts after local_irq_disable()" has been added to staging queue
This is a note to let you know that I have just added a patch titled MIPS: KVM: Deliver guest interrupts after local_irq_disable() to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree which can be found at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue This patch is scheduled to be released in version 3.13.11-ckt18. If you, or anyone else, feels it should not be added to this tree, please reply to this email. For more information about the 3.13.y-ckt tree, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable Thanks. -Kamal -- >From ade4441c2cab159ef290dc1af3d1165f1e3f78d3 Mon Sep 17 00:00:00 2001 From: James Hogan Date: Thu, 29 May 2014 10:16:32 +0100 Subject: MIPS: KVM: Deliver guest interrupts after local_irq_disable() commit 044f0f03eca0110e1835b2ea038a484b93950328 upstream. When about to run the guest, deliver guest interrupts after disabling host interrupts. This should prevent an hrtimer interrupt from being handled after delivering guest interrupts, and therefore not delivering the guest timer interrupt until after the next guest exit. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Gleb Natapov Cc: kvm@vger.kernel.org Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Cc: Sanjay Lal Signed-off-by: Paolo Bonzini Signed-off-by: Kamal Mostafa --- arch/mips/kvm/kvm_mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c index 7a8b440..4d058a7 100644 --- a/arch/mips/kvm/kvm_mips.c +++ b/arch/mips/kvm/kvm_mips.c @@ -424,11 +424,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run) vcpu->mmio_needed = 0; } + local_irq_disable(); /* Check if we have any exceptions/interrupts pending */ kvm_mips_deliver_interrupts(vcpu, kvm_read_c0_guest_cause(vcpu->arch.cop0)); - local_irq_disable(); kvm_guest_enter(); r = __kvm_mips_vcpu_run(run, vcpu); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.13.y-ckt stable] Patch "KVM: MIPS: Don't leak FPU/DSP to guest" has been added to staging queue
This is a note to let you know that I have just added a patch titled
KVM: MIPS: Don't leak FPU/DSP to guest
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
This patch is scheduled to be released in version 3.13.11-ckt18.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.13.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
--
>From adb94d141d17042e7eee5118f4f6358bfa61ffd9 Mon Sep 17 00:00:00 2001
From: James Hogan
Date: Wed, 4 Feb 2015 17:06:37 +
Subject: KVM: MIPS: Don't leak FPU/DSP to guest
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a guest exit, presumably in case there is
active state that needs saving if pre-emption occurs. However neither of
these bits are cleared again when returning to the guest.
This effectively gives the guest access to the FPU/DSP hardware after
the first guest exit even though it is not aware of its presence,
allowing FP instructions in guest user code to intermittently actually
execute instead of trapping into the guest OS for emulation. It will
then read & manipulate the hardware FP registers which technically
belong to the user process (e.g. QEMU), or are stale from another user
process. It can also crash the guest OS by causing an FP exception, for
which a guest exception handler won't have been registered.
First lets save and disable the FPU (and MSA) state with lose_fpu(1)
before entering the guest. This simplifies the problem, especially for
when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
state being live when the FR bit gets cleared for the guest, which
according to the architecture causes the contents of the FPU and vector
registers to become UNPREDICTABLE.
We can then safely remove the enabling of the FPU in
kvm_mips_set_c0_status(), since there should never be any active FPU or
MSA state to save at pre-emption, which should plug the FPU leak.
DSP state is always live rather than being lazily restored, so for that
it is simpler to just clear the MX bit again when re-entering the guest.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Sanjay Lal
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-m...@linux-mips.org
Signed-off-by: Paolo Bonzini
[ luis: backported to 3.16: files rename:
- locore.S -> kvm_locore.S
- mips.c -> kvm_mips.c ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
arch/mips/kvm/kvm_locore.S | 2 +-
arch/mips/kvm/kvm_mips.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index bbace09..03a2db5 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -428,7 +428,7 @@ __kvm_mips_return_to_guest:
/* Setup status register for running guest in UM */
.setat
or v1, v1, (ST0_EXL | KSU_USER | ST0_IE)
- and v1, v1, ~ST0_CU0
+ and v1, v1, ~(ST0_CU0 | ST0_MX)
.setnoat
mtc0v1, CP0_STATUS
ehb
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index 4d058a7..bdc5eeb 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -424,6 +425,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
vcpu->mmio_needed = 0;
}
+ lose_fpu(1);
+
local_irq_disable();
/* Check if we have any exceptions/interrupts pending */
kvm_mips_deliver_interrupts(vcpu,
@@ -1028,9 +1031,6 @@ void kvm_mips_set_c0_status(void)
{
uint32_t status = read_c0_status();
- if (cpu_has_fpu)
- status |= (ST0_CU1);
-
if (cpu_has_dsp)
status |= (ST0_MX);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.13.y-ckt stable] Patch "MIPS: Export FP functions used by lose_fpu(1) for KVM" has been added to staging queue
This is a note to let you know that I have just added a patch titled
MIPS: Export FP functions used by lose_fpu(1) for KVM
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
This patch is scheduled to be released in version 3.13.11-ckt18.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.13.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
--
>From 7adee277d64254de602234e7e53691d729f5e50c Mon Sep 17 00:00:00 2001
From: James Hogan
Date: Tue, 10 Feb 2015 10:02:59 +
Subject: MIPS: Export FP functions used by lose_fpu(1) for KVM
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is built as a module.
This fixes the following build error when CONFIG_KVM=m due to commit
f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
Signed-off-by: James Hogan
Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9260/
Signed-off-by: Ralf Baechle
Signed-off-by: Kamal Mostafa
---
arch/mips/kernel/mips_ksyms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
index 6e58e97..60adf79 100644
--- a/arch/mips/kernel/mips_ksyms.c
+++ b/arch/mips/kernel/mips_ksyms.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
extern void *__bzero(void *__s, size_t __count);
extern long __strncpy_from_user_nocheck_asm(char *__to,
@@ -26,6 +27,11 @@ extern long __strnlen_user_nocheck_asm(const char *s);
extern long __strnlen_user_asm(const char *s);
/*
+ * Core architecture code
+ */
+EXPORT_SYMBOL_GPL(_save_fp);
+
+/*
* String functions
*/
EXPORT_SYMBOL(memset);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.13.y-ckt stable] Patch "MIPS: Export FP functions used by lose_fpu(1) for KVM" has been added to staging queue
Hi Kamal,
On Tue, Mar 31, 2015 at 11:46:43AM -0700, Kamal Mostafa wrote:
> This is a note to let you know that I have just added a patch titled
>
> MIPS: Export FP functions used by lose_fpu(1) for KVM
>
> to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
> which can be found at:
>
>
> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
>
> This patch is scheduled to be released in version 3.13.11-ckt18.
>
> If you, or anyone else, feels it should not be added to this tree, please
> reply to this email.
>
> For more information about the 3.13.y-ckt tree, see
> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
>
> Thanks.
> -Kamal
>
> --
>
> From 7adee277d64254de602234e7e53691d729f5e50c Mon Sep 17 00:00:00 2001
> From: James Hogan
> Date: Tue, 10 Feb 2015 10:02:59 +
> Subject: MIPS: Export FP functions used by lose_fpu(1) for KVM
>
> commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
>
> Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
> modules so that KVM can make use of it when it is built as a module.
>
> This fixes the following build error when CONFIG_KVM=m due to commit
> f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
>
> ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
>
> Signed-off-by: James Hogan
> Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
> Cc: Paolo Bonzini
> Cc: Ralf Baechle
> Cc: Paul Burton
> Cc: Gleb Natapov
> Cc: kvm@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/9260/
> Signed-off-by: Ralf Baechle
> Signed-off-by: Kamal Mostafa
> ---
> arch/mips/kernel/mips_ksyms.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
> index 6e58e97..60adf79 100644
> --- a/arch/mips/kernel/mips_ksyms.c
> +++ b/arch/mips/kernel/mips_ksyms.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> extern void *__bzero(void *__s, size_t __count);
> extern long __strncpy_from_user_nocheck_asm(char *__to,
> @@ -26,6 +27,11 @@ extern long __strnlen_user_nocheck_asm(const char *s);
> extern long __strnlen_user_asm(const char *s);
>
> /*
> + * Core architecture code
> + */
> +EXPORT_SYMBOL_GPL(_save_fp);
Before v3.16 this will cause a build error with cavium_octeon_defconfig.
I submitted an updated stable patch for v3.10, v3.12, and v3.14, which
should be suitable for v3.13 too. See:
https://marc.info/?l=linux-mips&m=142557178417268&w=2
Cheers
James
> +
> +/*
> * String functions
> */
> EXPORT_SYMBOL(memset);
> --
> 1.9.1
>
signature.asc
Description: Digital signature
Re: [PATCH v5 3/3] drivers/vfio: Support EEH error injection
On Thu, 2015-03-26 at 16:42 +1100, Gavin Shan wrote:
> The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
> to inject the specified EEH error, which is represented by
> (struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
>
> Signed-off-by: Gavin Shan
> Reviewed-by: David Gibson
> ---
> Documentation/vfio.txt| 12
> drivers/vfio/vfio_spapr_eeh.c | 10 ++
> include/uapi/linux/vfio.h | 14 +-
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index 96978ec..4c746a7 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -385,6 +385,18 @@ The code flow from the example above should be slightly
> changed:
>
>
>
> + /* Inject EEH error, which is expected to be caused by 32-bits
> + * config load.
> + */
> + pe_op.op = VFIO_EEH_PE_INJECT_ERR;
> + pe_op.err.type = EEH_ERR_TYPE_32;
> + pe_op.err.func = EEH_ERR_FUNC_LD_CFG_ADDR;
> + pe_op.err.addr = 0ul;
> + pe_op.err.mask = 0ul;
> + ioctl(container, VFIO_EEH_PE_OP, &pe_op);
> +
> +
> +
> /* When 0xFF's returned from reading PCI config space or IO BARs
>* of the PCI device. Check the PE's state to see if that has been
>* frozen.
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index 5fa42db..38edeb4 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -85,6 +85,16 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> case VFIO_EEH_PE_CONFIGURE:
> ret = eeh_pe_configure(pe);
> break;
> + case VFIO_EEH_PE_INJECT_ERR:
> + minsz = offsetofend(struct vfio_eeh_pe_op, err.mask);
> + if (op.argsz < minsz)
> + return -EINVAL;
> + if (copy_from_user(&op, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + ret = eeh_pe_inject_err(pe, op.err.type, op.err.func,
> + op.err.addr, op.err.mask);
> + break;
> default:
> ret = -EINVAL;
> }
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 82889c3..d81c17f 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -468,12 +468,23 @@ struct vfio_iommu_spapr_tce_info {
> * - unfreeze IO/DMA for frozen PE;
> * - read PE state;
> * - reset PE;
> - * - configure PE.
> + * - configure PE;
> + * - inject EEH error.
> */
> +struct vfio_eeh_pe_err {
> + __u32 type;
> + __u32 func;
> + __u64 addr;
> + __u64 mask;
> +};
> +
> struct vfio_eeh_pe_op {
> __u32 argsz;
> __u32 flags;
> __u32 op;
> + union {
> + struct vfio_eeh_pe_err err;
> + };
> };
>
> #define VFIO_EEH_PE_DISABLE 0 /* Disable EEH functionality */
> @@ -490,6 +501,7 @@ struct vfio_eeh_pe_op {
> #define VFIO_EEH_PE_RESET_HOT6 /* Assert hot reset
> */
> #define VFIO_EEH_PE_RESET_FUNDAMENTAL7 /* Assert fundamental
> reset */
> #define VFIO_EEH_PE_CONFIGURE8 /* PE configuration
> */
> +#define VFIO_EEH_PE_INJECT_ERR 9 /* Inject EEH error
> */
>
> #define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21)
>
I assume you want this to go in through the PPC tree, so
Acked-by: Alex Williamson
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULLv2] KVM: s390: Features and fixes for 4.1 (kvm/next)
Paolo, Marcelo, here is the updated pull request for s390 (tag was updated) The changes reflect the comments from Heiko Carstens and Paolo Bonzini, (diff as followup mail) The following changes since commit 18280d8b4bcd4a2b174ee3cd748166c6190acacb: KVM: s390: represent SIMD cap in kvm facility (2015-03-17 16:33:14 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git tags/kvm-s390-next-20150331 for you to fetch changes up to 816c7667ea97c61884e014cfeedaede5b67b0e58: KVM: s390: migrate vcpu interrupt state (2015-03-31 21:07:31 +0200) Features and fixes for 4.1 (kvm/next) 1. Assorted changes 1.1 allow more feature bits for the guest 1.2 Store breaking event address on program interrupts 2. Interrupt handling rework 2.1 Fix copy_to_user while holding a spinlock (cc stable) 2.2 Rework floating interrupts to follow the priorities 2.3 Allow to inject all local interrupts via new ioctl 2.4 allow to get/set the full local irq state, e.g. for migration and introspection Christian Borntraeger (1): KVM: s390: enable more features that need no hypervisor changes David Hildenbrand (2): KVM: s390: store the breaking-event address on pgm interrupts KVM: s390: cpu timer irq priority Jens Freimann (5): KVM: s390: fix get_all_floating_irqs KVM: s390: deliver floating interrupts in order of priority KVM: s390: add ioctl to inject local interrupts KVM: s390: refactor vcpu injection function KVM: s390: migrate vcpu interrupt state Documentation/virtual/kvm/api.txt | 117 +++ Documentation/virtual/kvm/devices/s390_flic.txt |3 + arch/s390/include/asm/kvm_host.h| 30 +- arch/s390/kvm/interrupt.c | 1073 ++- arch/s390/kvm/kvm-s390.c| 54 +- arch/s390/kvm/kvm-s390.h|6 +- arch/s390/kvm/priv.c|9 +- include/uapi/linux/kvm.h| 14 + virt/kvm/kvm_main.c |2 +- 9 files changed, 906 insertions(+), 402 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL diff] diff to previous pull request
From: Jens Freimann
- change "__user u8" to u8 "__user"
- avoid unnecessary casts
- use capability numbers 113 and 114
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index ee2dfdc..9de4726 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -1613,7 +1613,7 @@ void kvm_s390_clear_float_irqs(struct kvm *kvm)
spin_unlock(&fi->lock);
};
-static int get_all_floating_irqs(struct kvm *kvm, __user __u8 *usrbuf, __u64
len)
+static int get_all_floating_irqs(struct kvm *kvm, u8 __user *usrbuf, u64 len)
{
struct kvm_s390_interrupt_info *inti;
struct kvm_s390_float_interrupt *fi;
@@ -1677,9 +1677,7 @@ static int get_all_floating_irqs(struct kvm *kvm, __user
__u8 *usrbuf, __u64 len
out:
spin_unlock(&fi->lock);
if (!ret && n > 0) {
- if (copy_to_user((void __user *) usrbuf,
-(void *) buf,
-sizeof(struct kvm_s390_irq) * n))
+ if (copy_to_user(usrbuf, buf, sizeof(struct kvm_s390_irq) * n))
ret = -EFAULT;
}
vfree(buf);
@@ -1693,7 +1691,7 @@ static int flic_get_attr(struct kvm_device *dev, struct
kvm_device_attr *attr)
switch (attr->group) {
case KVM_DEV_FLIC_GET_ALL_IRQS:
- r = get_all_floating_irqs(dev->kvm, (__user u8 *) attr->addr,
+ r = get_all_floating_irqs(dev->kvm, (u8 __user *) attr->addr,
attr->attr);
break;
default:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7437ce9..c045c72 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -809,8 +809,8 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_S390_MEM_OP 108
#define KVM_CAP_S390_USER_STSI 109
#define KVM_CAP_S390_SKEYS 110
-#define KVM_CAP_S390_INJECT_IRQ 111
-#define KVM_CAP_S390_IRQ_STATE 112
+#define KVM_CAP_S390_INJECT_IRQ 113
+#define KVM_CAP_S390_IRQ_STATE 114
#ifdef KVM_CAP_IRQ_ROUTING
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3.13.y-ckt stable] Patch "MIPS: Export FP functions used by lose_fpu(1) for KVM" has been added to staging queue
On Tue, 2015-03-31 at 20:08 +0100, James Hogan wrote:
> Hi Kamal,
>
> On Tue, Mar 31, 2015 at 11:46:43AM -0700, Kamal Mostafa wrote:
> > This is a note to let you know that I have just added a patch titled
> >
> > MIPS: Export FP functions used by lose_fpu(1) for KVM
> >
> > to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
> > which can be found at:
> >
> >
> > http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
> >
> > This patch is scheduled to be released in version 3.13.11-ckt18.
> >
> > If you, or anyone else, feels it should not be added to this tree, please
> > reply to this email.
> >
> > For more information about the 3.13.y-ckt tree, see
> > https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> >
> > Thanks.
> > -Kamal
> >
> > --
> >
> > From 7adee277d64254de602234e7e53691d729f5e50c Mon Sep 17 00:00:00 2001
> > From: James Hogan
> > Date: Tue, 10 Feb 2015 10:02:59 +
> > Subject: MIPS: Export FP functions used by lose_fpu(1) for KVM
> >
> > commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
> >
> > Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
> > modules so that KVM can make use of it when it is built as a module.
> >
> > This fixes the following build error when CONFIG_KVM=m due to commit
> > f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
> >
> > ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
> >
> > Signed-off-by: James Hogan
> > Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
> > Cc: Paolo Bonzini
> > Cc: Ralf Baechle
> > Cc: Paul Burton
> > Cc: Gleb Natapov
> > Cc: kvm@vger.kernel.org
> > Cc: linux-m...@linux-mips.org
> > Patchwork: https://patchwork.linux-mips.org/patch/9260/
> > Signed-off-by: Ralf Baechle
> > Signed-off-by: Kamal Mostafa
> > ---
> > arch/mips/kernel/mips_ksyms.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
> > index 6e58e97..60adf79 100644
> > --- a/arch/mips/kernel/mips_ksyms.c
> > +++ b/arch/mips/kernel/mips_ksyms.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > extern void *__bzero(void *__s, size_t __count);
> > extern long __strncpy_from_user_nocheck_asm(char *__to,
> > @@ -26,6 +27,11 @@ extern long __strnlen_user_nocheck_asm(const char *s);
> > extern long __strnlen_user_asm(const char *s);
> >
> > /*
> > + * Core architecture code
> > + */
> > +EXPORT_SYMBOL_GPL(_save_fp);
>
> Before v3.16 this will cause a build error with cavium_octeon_defconfig.
> I submitted an updated stable patch for v3.10, v3.12, and v3.14, which
> should be suitable for v3.13 too. See:
> https://marc.info/?l=linux-mips&m=142557178417268&w=2
Okay, replaced this in 3.13-stable with your backport. Thanks very
much, James!
-Kamal
> Cheers
> James
>
> > +
> > +/*
> > * String functions
> > */
> > EXPORT_SYMBOL(memset);
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
On Mon, Mar 30, 2015 at 04:28:25PM +0200, Michael Mueller wrote:
[...]
> ##
> # @query-cpu-definitions:
> #
> # Return a list of supported virtual CPU definitions
> #
> +# @machine: #optional machine type (since 2.4)
> +#
> +# @accel: #optional accelerator id (since 2.4)
> +#
> # Returns: a list of CpuDefInfo
> #
> # Since: 1.2.0
> ##
> -{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
> +{ 'command': 'query-cpu-definitions',
> + 'data': { '*machine': 'str', '*accel': 'AccelId' },
> + 'returns': ['CpuDefinitionInfo'] }
What happens if the new parameters are provided to an old QEMU version
that doesn't accept them? It looks like we need an introspection
mechanism or a new command name.
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
On 03/31/2015 01:46 PM, Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:25PM +0200, Michael Mueller wrote:
> [...]
>> ##
>> # @query-cpu-definitions:
>> #
>> # Return a list of supported virtual CPU definitions
>> #
>> +# @machine: #optional machine type (since 2.4)
>> +#
>> +# @accel: #optional accelerator id (since 2.4)
>> +#
>> # Returns: a list of CpuDefInfo
>> #
>> # Since: 1.2.0
>> ##
>> -{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
>> +{ 'command': 'query-cpu-definitions',
>> + 'data': { '*machine': 'str', '*accel': 'AccelId' },
>> + 'returns': ['CpuDefinitionInfo'] }
>
> What happens if the new parameters are provided to an old QEMU version
> that doesn't accept them? It looks like we need an introspection
> mechanism or a new command name.
Providing an optional parameter that a new qemu understands to an older
qemu gracefully errors out about an unknown parameter. But it's
annoying to have to probe for whether the parameter is understood by
exploiting that particular error message from older qemu.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[PATCH 3.13.y-ckt 119/143] MIPS: Export FP functions used by lose_fpu(1) for KVM
3.13.11-ckt18 -stable review patch. If anyone has any objections, please let
me know.
--
From: James Hogan
[ Upstream commit 3ce465e04bfd8de9956d515d6e9587faac3375dc ]
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is built as a module.
This fixes the following build error when CONFIG_KVM=m due to commit
f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):
ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
Signed-off-by: James Hogan
Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9260/
Signed-off-by: Ralf Baechle
[james.ho...@imgtec.com: Only export when CPU_R4K_FPU=y prior to v3.16,
so as not to break the Octeon build which excludes FPU support. KVM
depends on MIPS32r2 anyway.]
Signed-off-by: James Hogan
Signed-off-by: Kamal Mostafa
---
arch/mips/kernel/mips_ksyms.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
index 6e58e97..cedeb56 100644
--- a/arch/mips/kernel/mips_ksyms.c
+++ b/arch/mips/kernel/mips_ksyms.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
extern void *__bzero(void *__s, size_t __count);
extern long __strncpy_from_user_nocheck_asm(char *__to,
@@ -26,6 +27,13 @@ extern long __strnlen_user_nocheck_asm(const char *s);
extern long __strnlen_user_asm(const char *s);
/*
+ * Core architecture code
+ */
+#ifdef CONFIG_CPU_R4K_FPU
+EXPORT_SYMBOL_GPL(_save_fp);
+#endif
+
+/*
* String functions
*/
EXPORT_SYMBOL(memset);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model
On Tue, 31 Mar 2015 15:35:26 -0300
Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:24PM +0200, Michael Mueller wrote:
> > This patch implements a new QMP request named 'query-cpu-model'.
> > It returns the cpu model of cpu 0 and its backing accelerator.
> >
> > request:
> > {"execute" : "query-cpu-model" }
> >
> > answer:
> > {"return" : {"name": "2827-ga2", "accel": "kvm" }}
> >
> > Alias names are resolved to their respective machine type and GA names
> > already during cpu instantiation. Thus, also a cpu model like 'host'
> > which is implemented as alias will return its normalized cpu model name.
> >
> > Furthermore the patch implements the following function:
> >
> > - s390_cpu_models_used(), returns true if S390 cpu models are in use
> >
> > Signed-off-by: Michael Mueller
> > ---
> [...]
> > +static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
> > +{
> > +return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
> > +}
>
> How exactly is this information going to be used by clients? If getting
> the correct type and ga values is important for them, maybe you could
> add them as integer fields, instead of requiring clients to parse the
> CPU model name?
The consumer don't need to parse the name, it is just important for them to have
distinctive names that correlate with the names returned by
query-cpu-definitions.
Once the name of an active guest is known, e.g. ("2827-ga2", "kvm") a potential
migration target can be verified, i.e. its query-cpu-definitions answer for
"kvm"
has to contain "2827-ga2" with the attribute runnable set to true. With that
mechanism
also the largest common denominator can be calculated. That model will be used
then.
I also changed the above mentioned routine to map the cpu model none case:
static inline char *strdup_s390_cpu_name(S390CPUClass *cc)
{
if (cpuid(cc->proc)) {
return g_strdup_printf("%04x-ga%u", cc->proc.type, cc->mach.ga);
} else {
return g_strdup("none");
}
}
This implicitly will fail a comparison for cpu model ("none", "kvm") as that
will
never be part of the query-cpu-definitions answer.
I actually applied a couple of your suggestions like:
- test for NULL skipped after strdup_s390_cpu_name()
- strdup_s390_cpu_name() now also handles none cpu model case
- omit runnable and is-default field from query-cpu-definitions
answer when they are false
- global variable cpu_models_used dropped
- function s390_cpu_models_used() dropped
- routine query-cpu-definitions has a single code path now
Only the integration of the ACCEL_ID with the cpu state in cpu_generic_init()
and
the change for the query-cpus implementation is under construction. I hope to
resend
the patches by tomorrow evening.
Thanks,
Michael
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.13.y-ckt 069/143] KVM: MIPS: Don't leak FPU/DSP to guest
3.13.11-ckt18 -stable review patch. If anyone has any objections, please let
me know.
--
From: James Hogan
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a guest exit, presumably in case there is
active state that needs saving if pre-emption occurs. However neither of
these bits are cleared again when returning to the guest.
This effectively gives the guest access to the FPU/DSP hardware after
the first guest exit even though it is not aware of its presence,
allowing FP instructions in guest user code to intermittently actually
execute instead of trapping into the guest OS for emulation. It will
then read & manipulate the hardware FP registers which technically
belong to the user process (e.g. QEMU), or are stale from another user
process. It can also crash the guest OS by causing an FP exception, for
which a guest exception handler won't have been registered.
First lets save and disable the FPU (and MSA) state with lose_fpu(1)
before entering the guest. This simplifies the problem, especially for
when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
state being live when the FR bit gets cleared for the guest, which
according to the architecture causes the contents of the FPU and vector
registers to become UNPREDICTABLE.
We can then safely remove the enabling of the FPU in
kvm_mips_set_c0_status(), since there should never be any active FPU or
MSA state to save at pre-emption, which should plug the FPU leak.
DSP state is always live rather than being lazily restored, so for that
it is simpler to just clear the MX bit again when re-entering the guest.
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Sanjay Lal
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-m...@linux-mips.org
Signed-off-by: Paolo Bonzini
[ luis: backported to 3.16: files rename:
- locore.S -> kvm_locore.S
- mips.c -> kvm_mips.c ]
Signed-off-by: Luis Henriques
Signed-off-by: Kamal Mostafa
---
arch/mips/kvm/kvm_locore.S | 2 +-
arch/mips/kvm/kvm_mips.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index bbace09..03a2db5 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -428,7 +428,7 @@ __kvm_mips_return_to_guest:
/* Setup status register for running guest in UM */
.setat
or v1, v1, (ST0_EXL | KSU_USER | ST0_IE)
- and v1, v1, ~ST0_CU0
+ and v1, v1, ~(ST0_CU0 | ST0_MX)
.setnoat
mtc0v1, CP0_STATUS
ehb
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index 4d058a7..bdc5eeb 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -424,6 +425,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
vcpu->mmio_needed = 0;
}
+ lose_fpu(1);
+
local_irq_disable();
/* Check if we have any exceptions/interrupts pending */
kvm_mips_deliver_interrupts(vcpu,
@@ -1028,9 +1031,6 @@ void kvm_mips_set_c0_status(void)
{
uint32_t status = read_c0_status();
- if (cpu_has_fpu)
- status |= (ST0_CU1);
-
if (cpu_has_dsp)
status |= (ST0_MX);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.13.y-ckt 068/143] MIPS: KVM: Deliver guest interrupts after local_irq_disable()
3.13.11-ckt18 -stable review patch. If anyone has any objections, please let me know. -- From: James Hogan commit 044f0f03eca0110e1835b2ea038a484b93950328 upstream. When about to run the guest, deliver guest interrupts after disabling host interrupts. This should prevent an hrtimer interrupt from being handled after delivering guest interrupts, and therefore not delivering the guest timer interrupt until after the next guest exit. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: Gleb Natapov Cc: kvm@vger.kernel.org Cc: Ralf Baechle Cc: linux-m...@linux-mips.org Cc: Sanjay Lal Signed-off-by: Paolo Bonzini Signed-off-by: Kamal Mostafa --- arch/mips/kvm/kvm_mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c index 7a8b440..4d058a7 100644 --- a/arch/mips/kvm/kvm_mips.c +++ b/arch/mips/kvm/kvm_mips.c @@ -424,11 +424,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run) vcpu->mmio_needed = 0; } + local_irq_disable(); /* Check if we have any exceptions/interrupts pending */ kvm_mips_deliver_interrupts(vcpu, kvm_read_c0_guest_cause(vcpu->arch.cop0)); - local_irq_disable(); kvm_guest_enter(); r = __kvm_mips_vcpu_run(run, vcpu); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v4 12/15] Add optional parameters to QMP command query-cpu-definitions
On Tue, 31 Mar 2015 16:46:56 -0300
Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:25PM +0200, Michael Mueller wrote:
> [...]
> > ##
> > # @query-cpu-definitions:
> > #
> > # Return a list of supported virtual CPU definitions
> > #
> > +# @machine: #optional machine type (since 2.4)
> > +#
> > +# @accel: #optional accelerator id (since 2.4)
> > +#
> > # Returns: a list of CpuDefInfo
> > #
> > # Since: 1.2.0
> > ##
> > -{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
> > +{ 'command': 'query-cpu-definitions',
> > + 'data': { '*machine': 'str', '*accel': 'AccelId' },
> > + 'returns': ['CpuDefinitionInfo'] }
>
> What happens if the new parameters are provided to an old QEMU version
> that doesn't accept them? It looks like we need an introspection
> mechanism or a new command name.
Yep, as Eric mentions:
[mimu@p57lp59 (master) qemu]$ sudo virsh qemu-monitor-command zhyp027 '{
"execute":
"query-cpu-definitions", "arguments": { "accel": "kvm", "machine":
"s390-ccw-virtio" } }'
{"id":"libvirt-13","error":{"class":"GenericError","desc":"Invalid parameter
'accel'"}}
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] drivers/vfio: Support EEH error injection
On Tue, Mar 31, 2015 at 01:13:26PM -0600, Alex Williamson wrote:
>On Thu, 2015-03-26 at 16:42 +1100, Gavin Shan wrote:
>> The patch adds one more EEH sub-command (VFIO_EEH_PE_INJECT_ERR)
>> to inject the specified EEH error, which is represented by
>> (struct vfio_eeh_pe_err), to the indicated PE for testing purpose.
>>
>> Signed-off-by: Gavin Shan
>> Reviewed-by: David Gibson
>> ---
>> Documentation/vfio.txt| 12
>> drivers/vfio/vfio_spapr_eeh.c | 10 ++
>> include/uapi/linux/vfio.h | 14 +-
>> 3 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
>> index 96978ec..4c746a7 100644
>> --- a/Documentation/vfio.txt
>> +++ b/Documentation/vfio.txt
>> @@ -385,6 +385,18 @@ The code flow from the example above should be slightly
>> changed:
>>
>>
>>
>> +/* Inject EEH error, which is expected to be caused by 32-bits
>> + * config load.
>> + */
>> +pe_op.op = VFIO_EEH_PE_INJECT_ERR;
>> +pe_op.err.type = EEH_ERR_TYPE_32;
>> +pe_op.err.func = EEH_ERR_FUNC_LD_CFG_ADDR;
>> +pe_op.err.addr = 0ul;
>> +pe_op.err.mask = 0ul;
>> +ioctl(container, VFIO_EEH_PE_OP, &pe_op);
>> +
>> +
>> +
>> /* When 0xFF's returned from reading PCI config space or IO BARs
>> * of the PCI device. Check the PE's state to see if that has been
>> * frozen.
>> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
>> index 5fa42db..38edeb4 100644
>> --- a/drivers/vfio/vfio_spapr_eeh.c
>> +++ b/drivers/vfio/vfio_spapr_eeh.c
>> @@ -85,6 +85,16 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>> case VFIO_EEH_PE_CONFIGURE:
>> ret = eeh_pe_configure(pe);
>> break;
>> +case VFIO_EEH_PE_INJECT_ERR:
>> +minsz = offsetofend(struct vfio_eeh_pe_op, err.mask);
>> +if (op.argsz < minsz)
>> +return -EINVAL;
>> +if (copy_from_user(&op, (void __user *)arg, minsz))
>> +return -EFAULT;
>> +
>> +ret = eeh_pe_inject_err(pe, op.err.type, op.err.func,
>> +op.err.addr, op.err.mask);
>> +break;
>> default:
>> ret = -EINVAL;
>> }
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 82889c3..d81c17f 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -468,12 +468,23 @@ struct vfio_iommu_spapr_tce_info {
>> * - unfreeze IO/DMA for frozen PE;
>> * - read PE state;
>> * - reset PE;
>> - * - configure PE.
>> + * - configure PE;
>> + * - inject EEH error.
>> */
>> +struct vfio_eeh_pe_err {
>> +__u32 type;
>> +__u32 func;
>> +__u64 addr;
>> +__u64 mask;
>> +};
>> +
>> struct vfio_eeh_pe_op {
>> __u32 argsz;
>> __u32 flags;
>> __u32 op;
>> +union {
>> +struct vfio_eeh_pe_err err;
>> +};
>> };
>>
>> #define VFIO_EEH_PE_DISABLE 0 /* Disable EEH functionality */
>> @@ -490,6 +501,7 @@ struct vfio_eeh_pe_op {
>> #define VFIO_EEH_PE_RESET_HOT 6 /* Assert hot reset
>> */
>> #define VFIO_EEH_PE_RESET_FUNDAMENTAL 7 /* Assert fundamental
>> reset */
>> #define VFIO_EEH_PE_CONFIGURE 8 /* PE configuration
>> */
>> +#define VFIO_EEH_PE_INJECT_ERR 9 /* Inject EEH error
>> */
>>
>> #define VFIO_EEH_PE_OP _IO(VFIO_TYPE, VFIO_BASE + 21)
>>
>
>I assume you want this to go in through the PPC tree, so
>
>Acked-by: Alex Williamson
>
Thanks, Alex.W. Yes, It can go via PPC tree.
Thanks,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
