* [PATCH 1/3] x86/Hyper-V: Fix definition of struct hv_vp_assist_page
From: lantianyu1986 @ 2019-08-09 9:49 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-kernel, linux-hyperv, vkuznets
In-Reply-To: <20190809094939.76093-1-Tianyu.Lan@microsoft.com>
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
The struct hv_vp_assist_page was defined incorrectly.
The "vtl_control" should be u64[3], "nested_enlightenments_control"
should be a u64 and there is 7 reserved bytes following "enlighten_vmentry".
This patch is to fix it.
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
---
arch/x86/include/asm/hyperv-tlfs.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
index af78cd72b8f3..a79703c56ebe 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -517,11 +517,11 @@ struct hv_timer_message_payload {
/* Define virtual processor assist page structure. */
struct hv_vp_assist_page {
__u32 apic_assist;
- __u32 reserved;
- __u64 vtl_control[2];
+ __u32 reserved1;
+ __u64 vtl_control[3];
__u64 nested_enlightenments_control[2];
- __u32 enlighten_vmentry;
- __u32 padding;
+ __u8 enlighten_vmentry;
+ __u8 reserved2[7];
__u64 current_nested_vmcs;
} __packed;
--
2.14.2
^ permalink raw reply related
* [PATCH 0/3] KVM/Hyper-V: Add Hyper-V direct tlb flush support
From: lantianyu1986 @ 2019-08-09 9:49 UTC (permalink / raw)
To: pbonzini, rkrcmar, corbet, kys, haiyangz, sthemmin, sashal, tglx,
mingo, bp, hpa, x86, michael.h.kelley
Cc: Tianyu Lan, kvm, linux-doc, linux-hyperv, linux-kernel, vkuznets
From: Tianyu Lan <Tianyu.Lan@microsoft.com>
This patchset is to add Hyper-V direct tlb support in KVM. Hyper-V
in L0 can delegate L1 hypervisor to handle tlb flush request from
L2 guest when direct tlb flush is enabled in L1.
Patch 2 introduces new cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH to enable
feature from user space. User space should enable this feature only
when Hyper-V hypervisor capability is exposed to guest and KVM profile
is hided. There is a parameter conflict between KVM and Hyper-V hypercall.
We hope L2 guest doesn't use KVM hypercall when the feature is
enabled. Detail please see comment of new API "KVM_CAP_HYPERV_DIRECT_TLBFLUSH"
Tianyu Lan (2):
x86/Hyper-V: Fix definition of struct hv_vp_assist_page
KVM/Hyper-V: Add new KVM cap KVM_CAP_HYPERV_DIRECT_TLBFLUSH
Vitaly Kuznetsov (1):
KVM/Hyper-V/VMX: Add direct tlb flush support
Documentation/virtual/kvm/api.txt | 10 ++++++++++
arch/x86/include/asm/hyperv-tlfs.h | 24 +++++++++++++++++++-----
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/vmx/evmcs.h | 2 ++
arch/x86/kvm/vmx/vmx.c | 38 ++++++++++++++++++++++++++++++++++++++
arch/x86/kvm/x86.c | 8 ++++++++
include/linux/kvm_host.h | 1 +
include/uapi/linux/kvm.h | 1 +
8 files changed, 81 insertions(+), 5 deletions(-)
--
2.14.2
^ permalink raw reply
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Dave Martin @ 2019-08-09 9:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Kees Cook, Mark Rutland, kvm, Christian Koenig, Szabolcs Nagy,
Will Deacon, dri-devel, Kostya Serebryany, Khalid Aziz, Lee Smith,
open list:KERNEL SELFTEST FRAMEWORK, Vincenzo Frascino,
Will Deacon, Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Evgeniy Stepanov, linux-media, Ruben Ayrapetyan, Andrey Konovalov,
Kevin Brodsky, Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Linux Memory Management List, Greg Kroah-Hartman, Felix Kuehling,
Dave Hansen, LKML, Jens Wiklander, Ramana Radhakrishnan,
Alexander Deucher, Andrew Morton, enh, Robin Murphy, Yishai Hadas,
Luc Van Oostenryck
In-Reply-To: <20190809090016.GA23083@arrakis.emea.arm.com>
On Fri, Aug 09, 2019 at 10:00:17AM +0100, Catalin Marinas wrote:
> On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> > On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook@chromium.org> wrote:
> > >
> > > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > > >
> > > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > > >
> > > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > > via Andrew? I hope he agrees. :)
> > >
> > > I'll grab everything that has not yet appeared in linux-next. If more
> > > of these patches appear in linux-next I'll drop those as well.
> > >
> > > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > > prctl() options to control the tagged user addresses ABI" has petered
> > > out inconclusively. prctl() vs arch_prctl().
> >
> > I've always disliked arch_prctl() existing at all. Given that tagging is
> > likely to be a multi-architectural feature, it seems like the controls
> > should live in prctl() to me.
>
> It took a bit of grep'ing to figure out what Dave H meant by
> arch_prctl(). It's an x86-specific syscall which we do not have on arm64
> (and possibly any other architecture). Actually, we don't have any arm64
> specific syscalls, only the generic unistd.h, hence the confusion. For
> other arm64-specific prctls like SVE we used the generic sys_prctl() and
> I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
>
> In general I disagree with adding any arm64-specific syscalls but in
> this instance it can't even be justified. I'd rather see some clean-up
> similar to arch_ptrace/ptrace_request than introducing new syscall
> numbers (but as I suggested in my reply to Dave, that's for another
> patch series).
I had a go at refactoring this a while ago, but it fell by the wayside.
I can try to resurrect it if it's still considered worthwhile.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH v4 00/20] KVM RISC-V Support
From: Anup Patel @ 2019-08-09 9:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Paul Walmsley, Anup Patel, Palmer Dabbelt, Radim K,
Daniel Lezcano, Thomas Gleixner, Atish Patra, Alistair Francis,
Damien Le Moal, Christoph Hellwig, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <97987944-b42f-4f51-acfb-f318b41875bc@redhat.com>
On Fri, Aug 9, 2019 at 2:30 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/08/19 10:22, Anup Patel wrote:
> >> the L here should be kvm@vger.kernel.org. arch/riscv/kvm/ files would
> >> still match RISC-V ARCHITECTURE and therefore
> >> linux-riscv@lists.infradead.org would be CCed.
> > In addition to above mentioned lists, we insist of having a separate
> > KVM RISC-V list which can be CCed for non-kernel patches for projects
> > such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
> > be used for general queries related to KVM RISCV.
>
> You can use kvm@vger.kernel.org for that, with CCs to the other
> appropriate list (qemu-devel, libvir-list, LKML, linux-riscv, etc.).
> But if you want to have kvm-riscv, go ahead and ask for it.
>
> In any case, you can send v5 with all R-b and Acked-by and a fixed
> MAINTAINERS entry (listing kvm@vger for now), and Paul will apply it.
> For 5.5 you can start sending patches to me, either for direct
> application to the KVM tree or as pull requests.
Sure, I will send v5 early next week.
Regards,
Anup
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: change list for KVM/s390
From: Cornelia Huck @ 2019-08-09 9:04 UTC (permalink / raw)
To: Paolo Bonzini
Cc: linux-kernel, kvm, frankja, Christian Borntraeger, linux-s390
In-Reply-To: <1565335156-28660-1-git-send-email-pbonzini@redhat.com>
On Fri, 9 Aug 2019 09:19:16 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:
> KVM/s390 does not have a list of its own, and linux-s390 is in the
> loop anyway thanks to the generic arch/s390 match. So use the generic
> KVM list for s390 patches.
Let's add the s390 list manually just for this patch, for awareness :)
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1aec93695040..6498ebaca2f6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8788,7 +8788,7 @@ M: Christian Borntraeger <borntraeger@de.ibm.com>
> M: Janosch Frank <frankja@linux.ibm.com>
> R: David Hildenbrand <david@redhat.com>
> R: Cornelia Huck <cohuck@redhat.com>
> -L: linux-s390@vger.kernel.org
> +L: kvm@vger.kernel.org
> W: http://www.ibm.com/developerworks/linux/linux390/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
> S: Supported
Yes, get_maintainers.pl should add in the s390 list, so that sounds
fine.
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 00/20] KVM RISC-V Support
From: Paolo Bonzini @ 2019-08-09 9:00 UTC (permalink / raw)
To: Anup Patel
Cc: Paul Walmsley, Anup Patel, Palmer Dabbelt, Radim K,
Daniel Lezcano, Thomas Gleixner, Atish Patra, Alistair Francis,
Damien Le Moal, Christoph Hellwig, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAAhSdy1Hn69CxERttqa39wWr1-EYJtUPSG7TZnavZQqnMOHUqA@mail.gmail.com>
On 09/08/19 10:22, Anup Patel wrote:
>> the L here should be kvm@vger.kernel.org. arch/riscv/kvm/ files would
>> still match RISC-V ARCHITECTURE and therefore
>> linux-riscv@lists.infradead.org would be CCed.
> In addition to above mentioned lists, we insist of having a separate
> KVM RISC-V list which can be CCed for non-kernel patches for projects
> such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
> be used for general queries related to KVM RISCV.
You can use kvm@vger.kernel.org for that, with CCs to the other
appropriate list (qemu-devel, libvir-list, LKML, linux-riscv, etc.).
But if you want to have kvm-riscv, go ahead and ask for it.
In any case, you can send v5 with all R-b and Acked-by and a fixed
MAINTAINERS entry (listing kvm@vger for now), and Paul will apply it.
For 5.5 you can start sending patches to me, either for direct
application to the KVM tree or as pull requests.
Paolo
^ permalink raw reply
* Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel
From: Catalin Marinas @ 2019-08-09 9:00 UTC (permalink / raw)
To: Kees Cook
Cc: Andrew Morton, Andrey Konovalov, Will Deacon, Will Deacon,
Vincenzo Frascino, Mark Rutland, kvm, Szabolcs Nagy, dri-devel,
Kostya Serebryany, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Jacob Bramley, Leon Romanovsky, linux-rdma, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, Linux ARM, Dave Martin,
Evgeniy Stepanov, linux-media, Kevin Brodsky, Ruben Ayrapetyan,
Ramana Radhakrishnan, Alex Williamson, Mauro Carvalho Chehab,
Dmitry Vyukov, Linux Memory Management List, Greg Kroah-Hartman,
Yishai Hadas, LKML, Jens Wiklander, Lee Smith, Alexander Deucher,
enh, Robin Murphy, Christian Koenig, Luc Van Oostenryck,
Dave Hansen
In-Reply-To: <201908081608.A4F6711@keescook>
On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook@chromium.org> wrote:
> >
> > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > >
> > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > >
> > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > via Andrew? I hope he agrees. :)
> >
> > I'll grab everything that has not yet appeared in linux-next. If more
> > of these patches appear in linux-next I'll drop those as well.
> >
> > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > prctl() options to control the tagged user addresses ABI" has petered
> > out inconclusively. prctl() vs arch_prctl().
>
> I've always disliked arch_prctl() existing at all. Given that tagging is
> likely to be a multi-architectural feature, it seems like the controls
> should live in prctl() to me.
It took a bit of grep'ing to figure out what Dave H meant by
arch_prctl(). It's an x86-specific syscall which we do not have on arm64
(and possibly any other architecture). Actually, we don't have any arm64
specific syscalls, only the generic unistd.h, hence the confusion. For
other arm64-specific prctls like SVE we used the generic sys_prctl() and
I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
In general I disagree with adding any arm64-specific syscalls but in
this instance it can't even be justified. I'd rather see some clean-up
similar to arch_ptrace/ptrace_request than introducing new syscall
numbers (but as I suggested in my reply to Dave, that's for another
patch series).
--
Catalin
^ permalink raw reply
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-09 8:34 UTC (permalink / raw)
To: Ira Weiny
Cc: Michal Hocko, Jan Kara, John Hubbard, Matthew Wilcox,
john.hubbard, Andrew Morton, Christoph Hellwig, Dan Williams,
Dave Chinner, Dave Hansen, Jason Gunthorpe,
Jérôme Glisse, LKML, amd-gfx, ceph-devel, devel, devel,
dri-devel, intel-gfx, kvm, linux-arm-kernel, linux-block,
linux-crypto, linux-fbdev, linux-fsdevel, linux-media, linux-mm,
linux-nfs, linux-rdma, linux-rpi-kernel, linux-xfs, netdev,
rds-devel, sparclinux, x86, xen-devel
In-Reply-To: <20190808023637.GA1508@iweiny-DESK2.sc.intel.com>
On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > So I think your debug option and my suggested renaming serve a bit
> > > different purposes (and thus both make sense). If you do the renaming, you
> > > can just grep to see unconverted sites. Also when someone merges new GUP
> > > user (unaware of the new rules) while you switch GUP to use pins instead of
> > > ordinary references, you'll get compilation error in case of renaming
> > > instead of hard to debug refcount leak without the renaming. And such
> > > conflict is almost bound to happen given the size of GUP patch set... Also
> > > the renaming serves against the "coding inertia" - i.e., GUP is around for
> > > ages so people just use it without checking any documentation or comments.
> > > After switching how GUP works, what used to be correct isn't anymore so
> > > renaming the function serves as a warning that something has really
> > > changed.
> >
> > Fully agreed!
>
> Ok Prior to this I've been basing all my work for the RDMA/FS DAX stuff in
> Johns put_user_pages()... (Including when I proposed failing truncate with a
> lease in June [1])
>
> However, based on the suggestions in that thread it became clear that a new
> interface was going to need to be added to pass in the "RDMA file" information
> to GUP to associate file pins with the correct processes...
>
> I have many drawings on my white board with "a whole lot of lines" on them to
> make sure that if a process opens a file, mmaps it, pins it with RDMA, _closes_
> it, and ummaps it; that the resulting file pin can still be traced back to the
> RDMA context and all the processes which may have access to it.... No matter
> where the original context may have come from. I believe I have accomplished
> that.
>
> Before I go on, I would like to say that the "imbalance" of get_user_pages()
> and put_page() bothers me from a purist standpoint... However, since this
> discussion cropped up I went ahead and ported my work to Linus' current master
> (5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
> John... :-(
>
> I don't have the commit messages all cleaned up and I know there may be some
> discussion on these new interfaces but I wanted to throw this series out there
> because I think it may be what Jan and Michal are driving at (or at least in
> that direction.
>
> Right now only RDMA and DAX FS's are supported. Other users of GUP will still
> fail on a DAX file and regular files will still be at risk.[2]
>
> I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
>
> https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
>
> I think the most relevant patch to this conversation is:
>
> https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
>
> I stole Jans suggestion for a name as the name I used while prototyping was
> pretty bad... So Thanks Jan... ;-)
For your function, I'd choose a name like vaddr_pin_leased_pages() so that
association with a lease is clear from the name :) Also I'd choose the
counterpart to be vaddr_unpin_leased_page[s](). Especially having put_page in
the name looks confusing to me...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v4 00/20] KVM RISC-V Support
From: Anup Patel @ 2019-08-09 8:22 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Paul Walmsley, Anup Patel, Palmer Dabbelt, Radim K,
Daniel Lezcano, Thomas Gleixner, Atish Patra, Alistair Francis,
Damien Le Moal, Christoph Hellwig, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <2ea0c656-bd7e-ae79-1f8e-6b60374ccc6e@redhat.com>
On Fri, Aug 9, 2019 at 1:07 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/08/19 03:35, Paul Walmsley wrote:
> > On Thu, 8 Aug 2019, Paolo Bonzini wrote:
> >
> >> However, for Linux releases after 5.4 I would rather get pull requests
> >> for arch/riscv/kvm from Anup and Atish without involving the RISC-V
> >> tree. Of course, they or I will ask for your ack, or for a topic
> >> branch, on the occasion that something touches files outside their
> >> maintainership area. This is how things are already being handled for
> >> ARM, POWER and s390 and it allows me to handle conflicts in common KVM
> >> files before they reach Linus; these are more common than conflicts in
> >> arch files. If you have further questions on git and maintenance
> >> workflows, just ask!
> >
> > In principle, that's fine with me, as long as the arch/riscv maintainers
> > and mailing lists are kept in the loop. We already do something similar
> > to this for the RISC-V BPF JIT. However, I'd like this to be explicitly
> > documented in the MAINTAINERS file, as it is for BPF. It looks like it
> > isn't for ARM, POWER, or S390, either looking at MAINTAINERS or
> > spot-checking scripts/get_maintainer.pl:
> >
> > $ scripts/get_maintainer.pl -f arch/s390/kvm/interrupt.c
> > Christian Borntraeger <borntraeger@de.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Janosch Frank <frankja@linux.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > David Hildenbrand <david@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Cornelia Huck <cohuck@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > Heiko Carstens <heiko.carstens@de.ibm.com> (supporter:S390)
> > Vasily Gorbik <gor@linux.ibm.com> (supporter:S390)
> > linux-s390@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> > linux-kernel@vger.kernel.org (open list)
> > $
> >
> > Would you be willing to send a MAINTAINERS patch to formalize this
> > practice?
>
> Ah, I see, in the MAINTAINERS entry
>
> KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
> M: Anup Patel <anup.patel@wdc.com>
> R: Atish Patra <atish.patra@wdc.com>
> L: linux-riscv@lists.infradead.org
> T: git git://github.com/avpatel/linux.git
> S: Maintained
> F: arch/riscv/include/uapi/asm/kvm*
> F: arch/riscv/include/asm/kvm*
> F: arch/riscv/kvm/
>
> the L here should be kvm@vger.kernel.org. arch/riscv/kvm/ files would
> still match RISC-V ARCHITECTURE and therefore
> linux-riscv@lists.infradead.org would be CCed.
In addition to above mentioned lists, we insist of having a separate
KVM RISC-V list which can be CCed for non-kernel patches for projects
such as QEMU, KVMTOOL, and Libvirt. This KVM RISC-V list can also
be used for general queries related to KVM RISCV.
>
> Unlike other subsystems, for KVM I ask the submaintainers to include the
> patches in their pull requests, which is why you saw no kvm@vger entry
> for KVM/s390. However, it's probably a good idea to add it and do the
> same for RISC-V.
For KVM RISC-V, we will always CC both kvm@vger.kernel.org and
linux-riscv@lists.infradead.org.
Regards,
Anup
^ permalink raw reply
* Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Cornelia Huck @ 2019-08-09 8:07 UTC (permalink / raw)
To: Alex Williamson; +Cc: Parav Pandit, kvm, kwankhede, linux-kernel, cjia
In-Reply-To: <20190808170247.1fc2c4c4@x1.home>
On Thu, 8 Aug 2019 17:02:47 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Thu, 8 Aug 2019 09:12:53 -0500
> Parav Pandit <parav@mellanox.com> wrote:
>
> > Currently mtty sample driver uses mdev state and UUID in convoluated way to
> > generate an interrupt.
> > It uses several translations from mdev_state to mdev_device to mdev uuid.
> > After which it does linear search of long uuid comparision to
> > find out mdev_state in mtty_trigger_interrupt().
> > mdev_state is already available while generating interrupt from which all
> > such translations are done to reach back to mdev_state.
> >
> > This translations are done during interrupt generation path.
> > This is unnecessary and reduandant.
>
> Is the interrupt handling efficiency of this particular sample driver
> really relevant, or is its purpose more to illustrate the API and
> provide a proof of concept? If we go to the trouble to optimize the
> sample driver and remove this interface from the API, what do we lose?
Not sure how useful the sample driver is as a template; blindly copying
their interrupt handling is probably not a good idea.
>
> This interface was added via commit:
>
> 99e3123e3d72 vfio-mdev: Make mdev_device private and abstract interfaces
>
> Where the goal was to create a more formal interface and abstract
> driver access to the struct mdev_device. In part this served to make
> out-of-tree mdev vendor drivers more supportable; the object is
> considered opaque and access is provided via an API rather than through
> direct structure fields.
>
> I believe that the NVIDIA GRID mdev driver does make use of this
> interface and it's likely included in the sample driver specifically so
> that there is an in-kernel user for it (ie. specifically to avoid it
> being removed so casually). An interesting feature of the NVIDIA mdev
> driver is that I believe it has portions that run in userspace. As we
> know, mdevs are named with a UUID, so I can imagine there are some
> efficiencies to be gained in having direct access to the UUID for a
> device when interacting with userspace, rather than repeatedly parsing
> it from a device name. Is that really something we want to make more
> difficult in order to optimize a sample driver? Knowing that an mdev
> device uses a UUID for it's name, as tools like libvirt and mdevctl
> expect, is it really worthwhile to remove such a trivial API?
Ripping out the uuid is a bad idea, I agree. The device name simply is
no good replacement for that.
If there's a good use case for using the uuid in a vendor driver, let's
keep the accessor. But then we probably should either leave the sample
driver alone, or add a more compelling use of the api there.
>
> > Hence,
> > Patch-1 simplifies mtty sample driver to directly use mdev_state.
> >
> > Patch-2, Since no production driver uses mdev_uuid(), simplifies and
> > removes redandant mdev_uuid() exported symbol.
>
> s/no production driver/no in-kernel production driver/
>
> I'd be interested to hear how the NVIDIA folks make use of this API
> interface. Thanks,
>
> Alex
>
> > ---
> > Changelog:
> > v1->v2:
> > - Corrected email of Kirti
> > - Updated cover letter commit log to address comment from Cornelia
> > - Added Reviewed-by tag
> > v0->v1:
> > - Updated commit log
> >
> > Parav Pandit (2):
> > vfio-mdev/mtty: Simplify interrupt generation
> > vfio/mdev: Removed unused and redundant API for mdev UUID
> >
> > drivers/vfio/mdev/mdev_core.c | 6 ------
> > include/linux/mdev.h | 1 -
> > samples/vfio-mdev/mtty.c | 39 +++++++----------------------------
> > 3 files changed, 8 insertions(+), 38 deletions(-)
> >
>
^ permalink raw reply
* Re: [PATCH v3 1/2] selftests: kvm: Adding config fragments
From: Naresh Kamboju @ 2019-08-09 7:53 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Shuah Khan, open list, Andrew Jones, sean.j.christopherson,
open list:KERNEL SELFTEST FRAMEWORK, kvm list, Dan Rue
In-Reply-To: <0a0e0563-aba7-e59c-1fbd-547126d404ed@redhat.com>
On Fri, 9 Aug 2019 at 13:09, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 09/08/19 09:24, Naresh Kamboju wrote:
> > selftests kvm all test cases need pre-required kernel config for the
> > tests to get pass.
> >
> > CONFIG_KVM=y
> >
> > The KVM tests are skipped without these configs:
> >
> > dev_fd = open(KVM_DEV_PATH, O_RDONLY);
> > if (dev_fd < 0)
> > exit(KSFT_SKIP);
> >
> > Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Acked-by: Shuah Khan <skhan@linuxfoundation.org>
> > ---
> > tools/testing/selftests/kvm/config | 1 +
> > 1 file changed, 1 insertion(+)
> > create mode 100644 tools/testing/selftests/kvm/config
> >
> > diff --git a/tools/testing/selftests/kvm/config b/tools/testing/selftests/kvm/config
> > new file mode 100644
> > index 000000000000..14f90d8d6801
> > --- /dev/null
> > +++ b/tools/testing/selftests/kvm/config
> > @@ -0,0 +1 @@
> > +CONFIG_KVM=y
> >
>
> I think this is more complicated without a real benefit, so I'll merge v2.
With the recent changes to 'kselftest-merge' nested configs also get merged.
Please refer this below commit for more details.
---
commit 6d3db46c8e331908775b0135dc7d2e5920bf6d90
Author: Dan Rue <dan.rue@linaro.org>
Date: Mon May 20 10:16:14 2019 -0500
kbuild: teach kselftest-merge to find nested config files
Current implementation of kselftest-merge only finds config files that
are one level deep using `$(srctree)/tools/testing/selftests/*/config`.
Often, config files are added in nested directories, and do not get
picked up by kselftest-merge.
Use `find` to catch all config files under
`$(srctree)/tools/testing/selftests` instead.
Signed-off-by: Dan Rue <dan.rue@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
- Naresh
^ permalink raw reply
* [PATCH 4/4] KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable
From: Marc Zyngier @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Alexandru Elisei, Zenghui Yu, James Morse, Suzuki K Poulose,
Julien Thierry, linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20190809074832.13283-1-maz@kernel.org>
From: Alexandru Elisei <alexandru.elisei@arm.com>
A HW mapped level sensitive interrupt asserted by a device will not be put
into the ap_list if it is disabled at the VGIC level. When it is enabled
again, it will be inserted into the ap_list and written to a list register
on guest entry regardless of the state of the device.
We could argue that this can also happen on real hardware, when the command
to enable the interrupt reached the GIC before the device had the chance to
de-assert the interrupt signal; however, we emulate the distributor and
redistributors in software and we can do better than that.
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
virt/kvm/arm/vgic/vgic-mmio.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index 3ba7278fb533..44efc2ff863f 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -113,6 +113,22 @@ void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,
struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
raw_spin_lock_irqsave(&irq->irq_lock, flags);
+ if (vgic_irq_is_mapped_level(irq)) {
+ bool was_high = irq->line_level;
+
+ /*
+ * We need to update the state of the interrupt because
+ * the guest might have changed the state of the device
+ * while the interrupt was disabled at the VGIC level.
+ */
+ irq->line_level = vgic_get_phys_line_level(irq);
+ /*
+ * Deactivate the physical interrupt so the GIC will let
+ * us know when it is asserted again.
+ */
+ if (!irq->active && was_high && !irq->line_level)
+ vgic_irq_set_phys_active(irq, false);
+ }
irq->enabled = true;
vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] KVM: arm: Don't write junk to CP15 registers on reset
From: Marc Zyngier @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Alexandru Elisei, Zenghui Yu, James Morse, Suzuki K Poulose,
Julien Thierry, linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20190809074832.13283-1-maz@kernel.org>
At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a CP15 register while junk is in there, bad thing may happen.
Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something.
In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the CP15 reg leave outside
of the cp15_regs[] array). It may well be axed in the near future.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm/kvm/coproc.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index d2806bcff8bb..07745ee022a1 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -651,13 +651,22 @@ int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
}
static void reset_coproc_regs(struct kvm_vcpu *vcpu,
- const struct coproc_reg *table, size_t num)
+ const struct coproc_reg *table, size_t num,
+ unsigned long *bmap)
{
unsigned long i;
for (i = 0; i < num; i++)
- if (table[i].reset)
+ if (table[i].reset) {
+ int reg = table[i].reg;
+
table[i].reset(vcpu, &table[i]);
+ if (reg > 0 && reg < NR_CP15_REGS) {
+ set_bit(reg, bmap);
+ if (table[i].is_64bit)
+ set_bit(reg + 1, bmap);
+ }
+ }
}
static struct coproc_params decode_32bit_hsr(struct kvm_vcpu *vcpu)
@@ -1432,17 +1441,15 @@ void kvm_reset_coprocs(struct kvm_vcpu *vcpu)
{
size_t num;
const struct coproc_reg *table;
-
- /* Catch someone adding a register without putting in reset entry. */
- memset(vcpu->arch.ctxt.cp15, 0x42, sizeof(vcpu->arch.ctxt.cp15));
+ DECLARE_BITMAP(bmap, NR_CP15_REGS) = { 0, };
/* Generic chip reset first (so target could override). */
- reset_coproc_regs(vcpu, cp15_regs, ARRAY_SIZE(cp15_regs));
+ reset_coproc_regs(vcpu, cp15_regs, ARRAY_SIZE(cp15_regs), bmap);
table = get_target_table(vcpu->arch.target, &num);
- reset_coproc_regs(vcpu, table, num);
+ reset_coproc_regs(vcpu, table, num, bmap);
for (num = 1; num < NR_CP15_REGS; num++)
- WARN(vcpu_cp15(vcpu, num) == 0x42424242,
+ WARN(!test_bit(num, bmap),
"Didn't reset vcpu_cp15(vcpu, %zi)", num);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: Don't write junk to sysregs on reset
From: Marc Zyngier @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Alexandru Elisei, Zenghui Yu, James Morse, Suzuki K Poulose,
Julien Thierry, linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20190809074832.13283-1-maz@kernel.org>
At the moment, the way we reset system registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while the guest is running
(PSCI, for example). If anything in KVM has to evaluate the state
of a system register while junk is in there, bad thing may happen.
Let's stop doing that. Instead, we track that we have called a
reset function for that register, and assume that the reset
function has done something. This requires fixing a couple of
sysreg refinition in the trap table.
In the end, the very need of this reset check is pretty dubious,
as it doesn't check everything (a lot of the sysregs leave outside of
the sys_regs[] array). It may well be axed in the near future.
Tested-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f26e181d881c..2071260a275b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -632,7 +632,7 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
*/
val = ((pmcr & ~ARMV8_PMU_PMCR_MASK)
| (ARMV8_PMU_PMCR_MASK & 0xdecafbad)) & (~ARMV8_PMU_PMCR_E);
- __vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+ __vcpu_sys_reg(vcpu, r->reg) = val;
}
static bool check_pmu_access_disabled(struct kvm_vcpu *vcpu, u64 flags)
@@ -981,13 +981,13 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
{ SYS_DESC(SYS_DBGBVRn_EL1(n)), \
- trap_bvr, reset_bvr, n, 0, get_bvr, set_bvr }, \
+ trap_bvr, reset_bvr, 0, 0, get_bvr, set_bvr }, \
{ SYS_DESC(SYS_DBGBCRn_EL1(n)), \
- trap_bcr, reset_bcr, n, 0, get_bcr, set_bcr }, \
+ trap_bcr, reset_bcr, 0, 0, get_bcr, set_bcr }, \
{ SYS_DESC(SYS_DBGWVRn_EL1(n)), \
- trap_wvr, reset_wvr, n, 0, get_wvr, set_wvr }, \
+ trap_wvr, reset_wvr, 0, 0, get_wvr, set_wvr }, \
{ SYS_DESC(SYS_DBGWCRn_EL1(n)), \
- trap_wcr, reset_wcr, n, 0, get_wcr, set_wcr }
+ trap_wcr, reset_wcr, 0, 0, get_wcr, set_wcr }
/* Macro to expand the PMEVCNTRn_EL0 register */
#define PMU_PMEVCNTR_EL0(n) \
@@ -1540,7 +1540,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
{ SYS_DESC(SYS_CTR_EL0), access_ctr },
- { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, },
+ { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, PMCR_EL0 },
{ SYS_DESC(SYS_PMCNTENSET_EL0), access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
{ SYS_DESC(SYS_PMCNTENCLR_EL0), access_pmcnten, NULL, PMCNTENSET_EL0 },
{ SYS_DESC(SYS_PMOVSCLR_EL0), access_pmovs, NULL, PMOVSSET_EL0 },
@@ -2254,13 +2254,19 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
}
static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
- const struct sys_reg_desc *table, size_t num)
+ const struct sys_reg_desc *table, size_t num,
+ unsigned long *bmap)
{
unsigned long i;
for (i = 0; i < num; i++)
- if (table[i].reset)
+ if (table[i].reset) {
+ int reg = table[i].reg;
+
table[i].reset(vcpu, &table[i]);
+ if (reg > 0 && reg < NR_SYS_REGS)
+ set_bit(reg, bmap);
+ }
}
/**
@@ -2774,18 +2780,16 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
{
size_t num;
const struct sys_reg_desc *table;
-
- /* Catch someone adding a register without putting in reset entry. */
- memset(&vcpu->arch.ctxt.sys_regs, 0x42, sizeof(vcpu->arch.ctxt.sys_regs));
+ DECLARE_BITMAP(bmap, NR_SYS_REGS) = { 0, };
/* Generic chip reset first (so target could override). */
- reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
+ reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs), bmap);
table = get_target_table(vcpu->arch.target, true, &num);
- reset_sys_reg_descs(vcpu, table, num);
+ reset_sys_reg_descs(vcpu, table, num, bmap);
for (num = 1; num < NR_SYS_REGS; num++) {
- if (WARN(__vcpu_sys_reg(vcpu, num) == 0x4242424242424242,
+ if (WARN(!test_bit(num, bmap),
"Didn't reset __vcpu_sys_reg(%zi)\n", num))
break;
}
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block
From: Marc Zyngier @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Alexandru Elisei, Zenghui Yu, James Morse, Suzuki K Poulose,
Julien Thierry, linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20190809074832.13283-1-maz@kernel.org>
Since commit commit 328e56647944 ("KVM: arm/arm64: vgic: Defer
touching GICH_VMCR to vcpu_load/put"), we leave ICH_VMCR_EL2 (or
its GICv2 equivalent) loaded as long as we can, only syncing it
back when we're scheduled out.
There is a small snag with that though: kvm_vgic_vcpu_pending_irq(),
which is indirectly called from kvm_vcpu_check_block(), needs to
evaluate the guest's view of ICC_PMR_EL1. At the point were we
call kvm_vcpu_check_block(), the vcpu is still loaded, and whatever
changes to PMR is not visible in memory until we do a vcpu_put().
Things go really south if the guest does the following:
mov x0, #0 // or any small value masking interrupts
msr ICC_PMR_EL1, x0
[vcpu preempted, then rescheduled, VMCR sampled]
mov x0, #ff // allow all interrupts
msr ICC_PMR_EL1, x0
wfi // traps to EL2, so samping of VMCR
[interrupt arrives just after WFI]
Here, the hypervisor's view of PMR is zero, while the guest has enabled
its interrupts. kvm_vgic_vcpu_pending_irq() will then say that no
interrupts are pending (despite an interrupt being received) and we'll
block for no reason. If the guest doesn't have a periodic interrupt
firing once it has blocked, it will stay there forever.
To avoid this unfortuante situation, let's resync VMCR from
kvm_arch_vcpu_blocking(), ensuring that a following kvm_vcpu_check_block()
will observe the latest value of PMR.
This has been found by booting an arm64 Linux guest with the pseudo NMI
feature, and thus using interrupt priorities to mask interrupts instead
of the usual PSTATE masking.
Cc: stable@vger.kernel.org # 4.12
Fixes: 328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/arm.c | 11 +++++++++++
virt/kvm/arm/vgic/vgic-v2.c | 9 ++++++++-
virt/kvm/arm/vgic/vgic-v3.c | 7 ++++++-
virt/kvm/arm/vgic/vgic.c | 11 +++++++++++
virt/kvm/arm/vgic/vgic.h | 2 ++
6 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 46bbc949c20a..7a30524a80ee 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -350,6 +350,7 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu);
void kvm_vgic_load(struct kvm_vcpu *vcpu);
void kvm_vgic_put(struct kvm_vcpu *vcpu);
+void kvm_vgic_vmcr_sync(struct kvm_vcpu *vcpu);
#define irqchip_in_kernel(k) (!!((k)->arch.vgic.in_kernel))
#define vgic_initialized(k) ((k)->arch.vgic.initialized)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index c704fa696184..482b20256fa8 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -323,6 +323,17 @@ int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
{
+ /*
+ * If we're about to block (most likely because we've just hit a
+ * WFI), we need to sync back the state of the GIC CPU interface
+ * so that we have the lastest PMR and group enables. This ensures
+ * that kvm_arch_vcpu_runnable has up-to-date data to decide
+ * whether we have pending interrupts.
+ */
+ preempt_disable();
+ kvm_vgic_vmcr_sync(vcpu);
+ preempt_enable();
+
kvm_vgic_v4_enable_doorbell(vcpu);
}
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 6dd5ad706c92..96aab77d0471 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -484,10 +484,17 @@ void vgic_v2_load(struct kvm_vcpu *vcpu)
kvm_vgic_global_state.vctrl_base + GICH_APR);
}
-void vgic_v2_put(struct kvm_vcpu *vcpu)
+void vgic_v2_vmcr_sync(struct kvm_vcpu *vcpu)
{
struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
cpu_if->vgic_vmcr = readl_relaxed(kvm_vgic_global_state.vctrl_base + GICH_VMCR);
+}
+
+void vgic_v2_put(struct kvm_vcpu *vcpu)
+{
+ struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+
+ vgic_v2_vmcr_sync(vcpu);
cpu_if->vgic_apr = readl_relaxed(kvm_vgic_global_state.vctrl_base + GICH_APR);
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index c2c9ce009f63..0c653a1e5215 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -662,12 +662,17 @@ void vgic_v3_load(struct kvm_vcpu *vcpu)
__vgic_v3_activate_traps(vcpu);
}
-void vgic_v3_put(struct kvm_vcpu *vcpu)
+void vgic_v3_vmcr_sync(struct kvm_vcpu *vcpu)
{
struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
if (likely(cpu_if->vgic_sre))
cpu_if->vgic_vmcr = kvm_call_hyp_ret(__vgic_v3_read_vmcr);
+}
+
+void vgic_v3_put(struct kvm_vcpu *vcpu)
+{
+ vgic_v3_vmcr_sync(vcpu);
kvm_call_hyp(__vgic_v3_save_aprs, vcpu);
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 04786c8ec77e..13d4b38a94ec 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -919,6 +919,17 @@ void kvm_vgic_put(struct kvm_vcpu *vcpu)
vgic_v3_put(vcpu);
}
+void kvm_vgic_vmcr_sync(struct kvm_vcpu *vcpu)
+{
+ if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
+ return;
+
+ if (kvm_vgic_global_state.type == VGIC_V2)
+ vgic_v2_vmcr_sync(vcpu);
+ else
+ vgic_v3_vmcr_sync(vcpu);
+}
+
int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
{
struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index 57205beaa981..11adbdac1d56 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -193,6 +193,7 @@ int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
void vgic_v2_init_lrs(void);
void vgic_v2_load(struct kvm_vcpu *vcpu);
void vgic_v2_put(struct kvm_vcpu *vcpu);
+void vgic_v2_vmcr_sync(struct kvm_vcpu *vcpu);
void vgic_v2_save_state(struct kvm_vcpu *vcpu);
void vgic_v2_restore_state(struct kvm_vcpu *vcpu);
@@ -223,6 +224,7 @@ bool vgic_v3_check_base(struct kvm *kvm);
void vgic_v3_load(struct kvm_vcpu *vcpu);
void vgic_v3_put(struct kvm_vcpu *vcpu);
+void vgic_v3_vmcr_sync(struct kvm_vcpu *vcpu);
bool vgic_has_its(struct kvm *kvm);
int kvm_vgic_register_its_device(void);
--
2.20.1
^ permalink raw reply related
* [GIT PULL] KVM/arm updates for 5.3-rc4
From: Marc Zyngier @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Alexandru Elisei, Zenghui Yu, James Morse, Suzuki K Poulose,
Julien Thierry, linux-arm-kernel, kvmarm, kvm
Paolo, Radim,
Here's a set of update for -rc4. Yet another reset fix, and two subtle
VGIC fixes for issues that can be observed in interesting corner cases.
Note that this is on top of kvmarm-fixes-for-5.3[1], which hasn't been
pulled yet. Hopefully you can pull both at the same time!
Thanks,
M.
[1] https://lore.kernel.org/kvmarm/20190731173650.12627-1-maz@kernel.org
The following changes since commit cdb2d3ee0436d74fa9092f2df46aaa6f9e03c969:
arm64: KVM: hyp: debug-sr: Mark expected switch fall-through (2019-07-29 11:01:37 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.3-2
for you to fetch changes up to 16e604a437c89751dc626c9e90cf88ba93c5be64:
KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable (2019-08-09 08:07:26 +0100)
----------------------------------------------------------------
KVM/arm fixes for 5.3, take #2
- Fix our system register reset so that we stop writing
non-sensical values to them, and track which registers
get reset instead.
- Sync VMCR back from the GIC on WFI so that KVM has an
exact vue of PMR.
- Reevaluate state of HW-mapped, level triggered interrupts
on enable.
----------------------------------------------------------------
Alexandru Elisei (1):
KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable
Marc Zyngier (3):
KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block
KVM: arm64: Don't write junk to sysregs on reset
KVM: arm: Don't write junk to CP15 registers on reset
arch/arm/kvm/coproc.c | 23 +++++++++++++++--------
arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++--------------
include/kvm/arm_vgic.h | 1 +
virt/kvm/arm/arm.c | 11 +++++++++++
virt/kvm/arm/vgic/vgic-mmio.c | 16 ++++++++++++++++
virt/kvm/arm/vgic/vgic-v2.c | 9 ++++++++-
virt/kvm/arm/vgic/vgic-v3.c | 7 ++++++-
virt/kvm/arm/vgic/vgic.c | 11 +++++++++++
virt/kvm/arm/vgic/vgic.h | 2 ++
9 files changed, 88 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add KVM x86 reviewers
From: Vitaly Kuznetsov @ 2019-08-09 7:48 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
Cc: Sean Christopherson, Wanpeng Li, Jim Mattson, Joerg Roedel
In-Reply-To: <1565336051-31793-1-git-send-email-pbonzini@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> This is probably overdone---KVM x86 has quite a few contributors that
> usually review each other's patches, which is really helpful to me.
> Formalize this by listing them as reviewers. I am including people
> with various expertise:
>
> - Joerg for SVM (with designated reviewers, it makes more sense to have
> him in the main KVM/x86 stanza)
>
> - Sean for MMU and VMX
>
Sean is known to be a great SVM reviewer too!
> - Jim for VMX
>
> - Vitaly for Hyper-V and possibly SVM
>
> - Wanpeng for LAPIC and paravirtualization.
>
> Please ack if you are okay with this arrangement, otherwise speak up.
>
> In other news, Radim is going to leave Red Hat soon. However, he has
> not been very much involved in upstream KVM development for some time,
> and in the immediate future he is still going to help maintain kvm/queue
> while I am on vacation. Since not much is going to change, I will let
> him decide whether he wants to keep the maintainer role after he leaves.
>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> MAINTAINERS | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6498ebaca2f6..c569bd194d2a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8738,14 +8738,6 @@ F: virt/kvm/*
> F: tools/kvm/
> F: tools/testing/selftests/kvm/
>
> -KERNEL VIRTUAL MACHINE FOR AMD-V (KVM/amd)
> -M: Joerg Roedel <joro@8bytes.org>
> -L: kvm@vger.kernel.org
> -W: http://www.linux-kvm.org/
> -S: Maintained
> -F: arch/x86/include/asm/svm.h
> -F: arch/x86/kvm/svm.c
> -
> KERNEL VIRTUAL MACHINE FOR ARM/ARM64 (KVM/arm, KVM/arm64)
> M: Marc Zyngier <marc.zyngier@arm.com>
> R: James Morse <james.morse@arm.com>
> @@ -8803,6 +8795,11 @@ F: tools/testing/selftests/kvm/*/s390x/
> KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
> M: Paolo Bonzini <pbonzini@redhat.com>
> M: Radim Krčmář <rkrcmar@redhat.com>
> +R: Sean Christopherson <sean.j.christopherson@intel.com>
> +R: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> +R: Wanpeng Li <wanpengli@tencent.com>
> +R: Jim Mattson <jmattson@google.com>
> +R: Joerg Roedel <joro@8bytes.org>
> L: kvm@vger.kernel.org
> W: http://www.linux-kvm.org
> T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> @@ -8810,8 +8807,12 @@ S: Supported
> F: arch/x86/kvm/
> F: arch/x86/kvm/*/
> F: arch/x86/include/uapi/asm/kvm*
> +F: arch/x86/include/uapi/asm/vmx.h
> +F: arch/x86/include/uapi/asm/svm.h
> F: arch/x86/include/asm/kvm*
> F: arch/x86/include/asm/pvclock-abi.h
> +F: arch/x86/include/asm/svm.h
> +F: arch/x86/include/asm/vmx.h
> F: arch/x86/kernel/kvm.c
> F: arch/x86/kernel/kvmclock.c
--
Vitaly
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add KVM x86 reviewers
From: Wanpeng Li @ 2019-08-09 7:43 UTC (permalink / raw)
To: Paolo Bonzini
Cc: LKML, kvm, Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li,
Jim Mattson, Joerg Roedel
In-Reply-To: <1565336051-31793-1-git-send-email-pbonzini@redhat.com>
On Fri, 9 Aug 2019 at 15:36, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> This is probably overdone---KVM x86 has quite a few contributors that
> usually review each other's patches, which is really helpful to me.
> Formalize this by listing them as reviewers. I am including people
> with various expertise:
>
> - Joerg for SVM (with designated reviewers, it makes more sense to have
> him in the main KVM/x86 stanza)
>
> - Sean for MMU and VMX
>
> - Jim for VMX
>
> - Vitaly for Hyper-V and possibly SVM
>
> - Wanpeng for LAPIC and paravirtualization.
>
> Please ack if you are okay with this arrangement, otherwise speak up.
>
> In other news, Radim is going to leave Red Hat soon. However, he has
> not been very much involved in upstream KVM development for some time,
> and in the immediate future he is still going to help maintain kvm/queue
> while I am on vacation. Since not much is going to change, I will let
> him decide whether he wants to keep the maintainer role after he leaves.
>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> MAINTAINERS | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
Acked-by: Wanpeng Li <wanpengli@tencent.com>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add KVM x86 reviewers
From: Joerg Roedel @ 2019-08-09 7:41 UTC (permalink / raw)
To: Paolo Bonzini
Cc: linux-kernel, kvm, Sean Christopherson, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson
In-Reply-To: <1565336051-31793-1-git-send-email-pbonzini@redhat.com>
On Fri, Aug 09, 2019 at 09:34:11AM +0200, Paolo Bonzini wrote:
> This is probably overdone---KVM x86 has quite a few contributors that
> usually review each other's patches, which is really helpful to me.
> Formalize this by listing them as reviewers. I am including people
> with various expertise:
>
> - Joerg for SVM (with designated reviewers, it makes more sense to have
> him in the main KVM/x86 stanza)
>
> - Sean for MMU and VMX
>
> - Jim for VMX
>
> - Vitaly for Hyper-V and possibly SVM
>
> - Wanpeng for LAPIC and paravirtualization.
>
> Please ack if you are okay with this arrangement, otherwise speak up.
>
> In other news, Radim is going to leave Red Hat soon. However, he has
> not been very much involved in upstream KVM development for some time,
> and in the immediate future he is still going to help maintain kvm/queue
> while I am on vacation. Since not much is going to change, I will let
> him decide whether he wants to keep the maintainer role after he leaves.
>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> MAINTAINERS | 17 +++++++++--------
> 1 file changed, 9 insertions(+), 8 deletions(-)
Acked-by: Joerg Roedel <joro@8bytes.org>
^ permalink raw reply
* Re: [PATCH v3 1/2] selftests: kvm: Adding config fragments
From: Paolo Bonzini @ 2019-08-09 7:39 UTC (permalink / raw)
To: Naresh Kamboju, shuah
Cc: linux-kernel, drjones, sean.j.christopherson, linux-kselftest,
kvm
In-Reply-To: <20190809072415.29305-1-naresh.kamboju@linaro.org>
On 09/08/19 09:24, Naresh Kamboju wrote:
> selftests kvm all test cases need pre-required kernel config for the
> tests to get pass.
>
> CONFIG_KVM=y
>
> The KVM tests are skipped without these configs:
>
> dev_fd = open(KVM_DEV_PATH, O_RDONLY);
> if (dev_fd < 0)
> exit(KSFT_SKIP);
>
> Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Acked-by: Shuah Khan <skhan@linuxfoundation.org>
> ---
> tools/testing/selftests/kvm/config | 1 +
> 1 file changed, 1 insertion(+)
> create mode 100644 tools/testing/selftests/kvm/config
>
> diff --git a/tools/testing/selftests/kvm/config b/tools/testing/selftests/kvm/config
> new file mode 100644
> index 000000000000..14f90d8d6801
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/config
> @@ -0,0 +1 @@
> +CONFIG_KVM=y
>
I think this is more complicated without a real benefit, so I'll merge v2.
Paolo
^ permalink raw reply
* Re: [PATCH v4 00/20] KVM RISC-V Support
From: Paolo Bonzini @ 2019-08-09 7:37 UTC (permalink / raw)
To: Paul Walmsley
Cc: Anup Patel, Palmer Dabbelt, Radim K, Daniel Lezcano,
Thomas Gleixner, Atish Patra, Alistair Francis, Damien Le Moal,
Christoph Hellwig, Anup Patel, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <alpine.DEB.2.21.9999.1908081824500.21111@viisi.sifive.com>
On 09/08/19 03:35, Paul Walmsley wrote:
> On Thu, 8 Aug 2019, Paolo Bonzini wrote:
>
>> However, for Linux releases after 5.4 I would rather get pull requests
>> for arch/riscv/kvm from Anup and Atish without involving the RISC-V
>> tree. Of course, they or I will ask for your ack, or for a topic
>> branch, on the occasion that something touches files outside their
>> maintainership area. This is how things are already being handled for
>> ARM, POWER and s390 and it allows me to handle conflicts in common KVM
>> files before they reach Linus; these are more common than conflicts in
>> arch files. If you have further questions on git and maintenance
>> workflows, just ask!
>
> In principle, that's fine with me, as long as the arch/riscv maintainers
> and mailing lists are kept in the loop. We already do something similar
> to this for the RISC-V BPF JIT. However, I'd like this to be explicitly
> documented in the MAINTAINERS file, as it is for BPF. It looks like it
> isn't for ARM, POWER, or S390, either looking at MAINTAINERS or
> spot-checking scripts/get_maintainer.pl:
>
> $ scripts/get_maintainer.pl -f arch/s390/kvm/interrupt.c
> Christian Borntraeger <borntraeger@de.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Janosch Frank <frankja@linux.ibm.com> (supporter:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> David Hildenbrand <david@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Cornelia Huck <cohuck@redhat.com> (reviewer:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> Heiko Carstens <heiko.carstens@de.ibm.com> (supporter:S390)
> Vasily Gorbik <gor@linux.ibm.com> (supporter:S390)
> linux-s390@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE for s390 (KVM/s390))
> linux-kernel@vger.kernel.org (open list)
> $
>
> Would you be willing to send a MAINTAINERS patch to formalize this
> practice?
Ah, I see, in the MAINTAINERS entry
KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
M: Anup Patel <anup.patel@wdc.com>
R: Atish Patra <atish.patra@wdc.com>
L: linux-riscv@lists.infradead.org
T: git git://github.com/avpatel/linux.git
S: Maintained
F: arch/riscv/include/uapi/asm/kvm*
F: arch/riscv/include/asm/kvm*
F: arch/riscv/kvm/
the L here should be kvm@vger.kernel.org. arch/riscv/kvm/ files would
still match RISC-V ARCHITECTURE and therefore
linux-riscv@lists.infradead.org would be CCed.
Unlike other subsystems, for KVM I ask the submaintainers to include the
patches in their pull requests, which is why you saw no kvm@vger entry
for KVM/s390. However, it's probably a good idea to add it and do the
same for RISC-V.
Is that what you meant?
Paolo
^ permalink raw reply
* Re: [PATCH v2] selftests: kvm: Adding config fragments
From: Naresh Kamboju @ 2019-08-09 7:35 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Andrew Jones, Shuah Khan, open list, sean.j.christopherson,
open list:KERNEL SELFTEST FRAMEWORK, kvm list
In-Reply-To: <b34e8232-ccfd-898c-49de-afef4168a165@redhat.com>
On Thu, 8 Aug 2019 at 21:30, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 08/08/19 17:10, Andrew Jones wrote:
> >>
> > What does the kselftests config file do? I was about to complain that this
> > would break compiling on non-x86 platforms, but 'make kselftest' and other
> > forms of invoking the build work fine on aarch64 even with this config
> > file. So is this just for documentation? If so, then its still obviously
> > wrong for non-x86 platforms. The only config that makes sense here is KVM.
> > If the other options need to be documented for x86, then should they get
> > an additional config file? tools/testing/selftests/kvm/x86_64/config?
>
> My understanding is that a config file fragment requires some kind of
> kconfig invocation to create a full .config file. When you do that,
> unknown configurations are dropped silently.
You are right on this point. As you said, unknown configs getting dropped for
arm64 cross compilation.
- Naresh
^ permalink raw reply
* [PATCH] MAINTAINERS: add KVM x86 reviewers
From: Paolo Bonzini @ 2019-08-09 7:34 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel
This is probably overdone---KVM x86 has quite a few contributors that
usually review each other's patches, which is really helpful to me.
Formalize this by listing them as reviewers. I am including people
with various expertise:
- Joerg for SVM (with designated reviewers, it makes more sense to have
him in the main KVM/x86 stanza)
- Sean for MMU and VMX
- Jim for VMX
- Vitaly for Hyper-V and possibly SVM
- Wanpeng for LAPIC and paravirtualization.
Please ack if you are okay with this arrangement, otherwise speak up.
In other news, Radim is going to leave Red Hat soon. However, he has
not been very much involved in upstream KVM development for some time,
and in the immediate future he is still going to help maintain kvm/queue
while I am on vacation. Since not much is going to change, I will let
him decide whether he wants to keep the maintainer role after he leaves.
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wanpeng Li <wanpengli@tencent.com>
Cc: Jim Mattson <jmattson@google.com>
Cc: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
MAINTAINERS | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6498ebaca2f6..c569bd194d2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8738,14 +8738,6 @@ F: virt/kvm/*
F: tools/kvm/
F: tools/testing/selftests/kvm/
-KERNEL VIRTUAL MACHINE FOR AMD-V (KVM/amd)
-M: Joerg Roedel <joro@8bytes.org>
-L: kvm@vger.kernel.org
-W: http://www.linux-kvm.org/
-S: Maintained
-F: arch/x86/include/asm/svm.h
-F: arch/x86/kvm/svm.c
-
KERNEL VIRTUAL MACHINE FOR ARM/ARM64 (KVM/arm, KVM/arm64)
M: Marc Zyngier <marc.zyngier@arm.com>
R: James Morse <james.morse@arm.com>
@@ -8803,6 +8795,11 @@ F: tools/testing/selftests/kvm/*/s390x/
KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
M: Paolo Bonzini <pbonzini@redhat.com>
M: Radim Krčmář <rkrcmar@redhat.com>
+R: Sean Christopherson <sean.j.christopherson@intel.com>
+R: Vitaly Kuznetsov <vkuznets@redhat.com>
+R: Wanpeng Li <wanpengli@tencent.com>
+R: Jim Mattson <jmattson@google.com>
+R: Joerg Roedel <joro@8bytes.org>
L: kvm@vger.kernel.org
W: http://www.linux-kvm.org
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
@@ -8810,8 +8807,12 @@ S: Supported
F: arch/x86/kvm/
F: arch/x86/kvm/*/
F: arch/x86/include/uapi/asm/kvm*
+F: arch/x86/include/uapi/asm/vmx.h
+F: arch/x86/include/uapi/asm/svm.h
F: arch/x86/include/asm/kvm*
F: arch/x86/include/asm/pvclock-abi.h
+F: arch/x86/include/asm/svm.h
+F: arch/x86/include/asm/vmx.h
F: arch/x86/kernel/kvm.c
F: arch/x86/kernel/kvmclock.c
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] selftests: kvm: Adding config fragments
From: Naresh Kamboju @ 2019-08-09 7:27 UTC (permalink / raw)
To: Andrew Jones
Cc: Paolo Bonzini, Shuah Khan, open list, sean.j.christopherson,
open list:KERNEL SELFTEST FRAMEWORK, kvm list
In-Reply-To: <20190808151010.ktbqbfevgcs3bkjy@kamzik.brq.redhat.com>
On Thu, 8 Aug 2019 at 20:40, Andrew Jones <drjones@redhat.com> wrote:
>
> On Thu, Aug 08, 2019 at 01:31:40PM +0100, Naresh Kamboju wrote:
> > selftests kvm all test cases need pre-required kernel configs for the
> > tests to get pass.
> >
> > The KVM tests are skipped without these configs:
> >
> > dev_fd = open(KVM_DEV_PATH, O_RDONLY);
> > if (dev_fd < 0)
> > exit(KSFT_SKIP);
> >
> > Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > ---
> > tools/testing/selftests/kvm/config | 3 +++
> > 1 file changed, 3 insertions(+)
> > create mode 100644 tools/testing/selftests/kvm/config
> >
> > diff --git a/tools/testing/selftests/kvm/config b/tools/testing/selftests/kvm/config
> > new file mode 100644
> > index 000000000000..63ed533f73d6
> > --- /dev/null
> > +++ b/tools/testing/selftests/kvm/config
> > @@ -0,0 +1,3 @@
> > +CONFIG_KVM=y
> > +CONFIG_KVM_INTEL=y
> > +CONFIG_KVM_AMD=y
> > --
> > 2.17.1
> >
>
> What does the kselftests config file do? I was about to complain that this
> would break compiling on non-x86 platforms, but 'make kselftest' and other
> forms of invoking the build work fine on aarch64 even with this config
> file. So is this just for documentation? If so, then its still obviously
> wrong for non-x86 platforms. The only config that makes sense here is KVM.
> If the other options need to be documented for x86, then should they get
> an additional config file? tools/testing/selftests/kvm/x86_64/config?
Addressed your comments and sent out v3 patch.
Thank for the review.
- Naresh
^ permalink raw reply
* [PATCH v3 2/2] selftests: kvm: x86_64: Adding config fragments
From: Naresh Kamboju @ 2019-08-09 7:24 UTC (permalink / raw)
To: naresh.kamboju, pbonzini, shuah
Cc: linux-kernel, drjones, sean.j.christopherson, linux-kselftest,
kvm
In-Reply-To: <20190809072415.29305-1-naresh.kamboju@linaro.org>
selftests kvm x86_64 test cases need pre-required kernel configs for the
tests to get pass when you are using Intel or AMD CPU.
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y
Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
---
tools/testing/selftests/kvm/x86_64/config | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86_64/config
diff --git a/tools/testing/selftests/kvm/x86_64/config b/tools/testing/selftests/kvm/x86_64/config
new file mode 100644
index 000000000000..4df8c7f54885
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86_64/config
@@ -0,0 +1,2 @@
+CONFIG_KVM_INTEL=y
+CONFIG_KVM_AMD=y
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox