Re: [PATCH v5 8/8] Documentation: document the ABI changes for KVM_CAP_ARM_MTE

[Cornelia Huck]

On Thu, Nov 03 2022, Peter Collingbourne  wrote:

> Document both the restriction on VM_MTE_ALLOWED mappings and
> the relaxation for shared mappings.
>
> Signed-off-by: Peter Collingbourne 
> Acked-by: Catalin Marinas 
> ---
>  Documentation/virt/kvm/api.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 7/8] KVM: arm64: permit all VM_MTE_ALLOWED mappings with MTE enabled

[Cornelia Huck]

On Thu, Nov 03 2022, Peter Collingbourne  wrote:

> Certain VMMs such as crosvm have features (e.g. sandboxing) that depend
> on being able to map guest memory as MAP_SHARED. The current restriction
> on sharing MAP_SHARED pages with the guest is preventing the use of
> those features with MTE. Now that the races between tasks concurrently
> clearing tags on the same page have been fixed, remove this restriction.
>
> Note that this is a relaxation of the ABI.
>
> Signed-off-by: Peter Collingbourne 
> Reviewed-by: Catalin Marinas 
> Reviewed-by: Steven Price 
> ---
>  arch/arm64/kvm/mmu.c | 8 
>  1 file changed, 8 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 6/8] KVM: arm64: unify the tests for VMAs in memslots when MTE is enabled

[Cornelia Huck]

On Thu, Nov 03 2022, Peter Collingbourne  wrote:

> Previously we allowed creating a memslot containing a private mapping that
> was not VM_MTE_ALLOWED, but would later reject KVM_RUN with -EFAULT. Now
> we reject the memory region at memslot creation time.
>
> Since this is a minor tweak to the ABI (a VMM that created one of
> these memslots would fail later anyway), no VMM to my knowledge has
> MTE support yet, and the hardware with the necessary features is not
> generally available, we can probably make this ABI change at this point.
>
> Signed-off-by: Peter Collingbourne 
> Reviewed-by: Catalin Marinas 
> Reviewed-by: Steven Price 
> ---
>  arch/arm64/kvm/mmu.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 5/8] arm64: mte: Lock a page for MTE tag initialisation

[Cornelia Huck]

On Thu, Nov 03 2022, Peter Collingbourne  wrote:

> From: Catalin Marinas 
>
> Initialising the tags and setting PG_mte_tagged flag for a page can race
> between multiple set_pte_at() on shared pages or setting the stage 2 pte
> via user_mem_abort(). Introduce a new PG_mte_lock flag as PG_arch_3 and
> set it before attempting page initialisation. Given that PG_mte_tagged
> is never cleared for a page, consider setting this flag to mean page
> unlocked and wait on this bit with acquire semantics if the page is
> locked:
>
> - try_page_mte_tagging() - lock the page for tagging, return true if it
>   can be tagged, false if already tagged. No acquire semantics if it
>   returns true (PG_mte_tagged not set) as there is no serialisation with
>   a previous set_page_mte_tagged().
>
> - set_page_mte_tagged() - set PG_mte_tagged with release semantics.
>
> The two-bit locking is based on Peter Collingbourne's idea.
>
> Signed-off-by: Catalin Marinas 
> Signed-off-by: Peter Collingbourne 
> Reviewed-by: Steven Price 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: Peter Collingbourne 
> ---
>  arch/arm64/include/asm/mte.h | 35 +++-
>  arch/arm64/include/asm/pgtable.h |  4 ++--
>  arch/arm64/kernel/cpufeature.c   |  2 +-
>  arch/arm64/kernel/mte.c  | 12 +++
>  arch/arm64/kvm/guest.c   | 16 +--
>  arch/arm64/kvm/mmu.c |  2 +-
>  arch/arm64/mm/copypage.c |  2 ++
>  arch/arm64/mm/fault.c|  2 ++
>  arch/arm64/mm/mteswap.c  | 14 +
>  9 files changed, 60 insertions(+), 29 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 3/8] KVM: arm64: Simplify the sanitise_mte_tags() logic

[Cornelia Huck]

On Thu, Nov 03 2022, Peter Collingbourne  wrote:

> From: Catalin Marinas 
>
> Currently sanitise_mte_tags() checks if it's an online page before
> attempting to sanitise the tags. Such detection should be done in the
> caller via the VM_MTE_ALLOWED vma flag. Since kvm_set_spte_gfn() does
> not have the vma, leave the page unmapped if not already tagged. Tag
> initialisation will be done on a subsequent access fault in
> user_mem_abort().
>
> Signed-off-by: Catalin Marinas 
> [p...@google.com: fix the page initializer]
> Signed-off-by: Peter Collingbourne 
> Reviewed-by: Steven Price 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: Peter Collingbourne 
> ---
>  arch/arm64/kvm/mmu.c | 40 +++-
>  1 file changed, 15 insertions(+), 25 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 04/44] KVM: Teardown VFIO ops earlier in kvm_exit()

[Cornelia Huck]

On Wed, Nov 02 2022, Sean Christopherson  wrote:

> Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and
> bring some amount of symmetry to the setup order in kvm_init(), and more
> importantly so that the arch hooks are invoked dead last by kvm_exit().
> This will allow arch code to move away from the arch hooks without any
> change in ordering between arch code and common code in kvm_exit().
>
> That kvm_vfio_ops_exit() is called last appears to be 100% arbitrary.  It
> was bolted on after the fact by commit 571ee1b68598 ("kvm: vfio: fix
> unregister kvm_device_ops of vfio").  The nullified kvm_device_ops_table
> is also local to kvm_main.c and is used only when there are active VMs,
> so unless arch code is doing something truly bizarre, nullifying the
> table earlier in kvm_exit() is little more than a nop.
>
> Signed-off-by: Sean Christopherson 
> ---
>  virt/kvm/kvm_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Looks safe to me.

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list

[Cornelia Huck]

On Fri, Oct 28 2022, Andrew Jones  wrote:

> On Fri, Oct 28, 2022 at 01:37:34PM +0200, Cornelia Huck wrote:
>> On Tue, Oct 25 2022, Cornelia Huck  wrote:
>> 
>> > KVM/arm64 development is moving to a new mailing list (see
>> > https://lore.kernel.org/all/20221001091245.3900668-1-...@kernel.org/);
>> > kvm-unit-tests should advertise the new list as well.
>> >
>> > Signed-off-by: Cornelia Huck 
>> > ---
>> >  MAINTAINERS | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index 90ead214a75d..649de509a511 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -67,7 +67,8 @@ ARM
>> >  M: Andrew Jones 
>> >  S: Supported
>> >  L: k...@vger.kernel.org
>> > -L: kvmarm@lists.cs.columbia.edu
>> > +L: kvm...@lists.linux.dev
>> > +L: kvmarm@lists.cs.columbia.edu (deprecated)
>> 
>> As the days of the Columbia list really seem to be numbered (see
>> https://lore.kernel.org/all/364100e884023234e4ab9e525774d...@kernel.org/),
>> should we maybe drop it completely from MAINTAINERS, depending on when
>> this gets merged?
>
> I'll merge your patch now with the old (deprecated) list still there. When
> mail starts bouncing it may help people better understand why. When the
> kernel drops it from its MAINTAINERS file, then we can drop it here too.

OK, makes sense.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list

[Cornelia Huck]

On Tue, Oct 25 2022, Cornelia Huck  wrote:

> KVM/arm64 development is moving to a new mailing list (see
> https://lore.kernel.org/all/20221001091245.3900668-1-...@kernel.org/);
> kvm-unit-tests should advertise the new list as well.
>
> Signed-off-by: Cornelia Huck 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 90ead214a75d..649de509a511 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -67,7 +67,8 @@ ARM
>  M: Andrew Jones 
>  S: Supported
>  L: k...@vger.kernel.org
> -L: kvmarm@lists.cs.columbia.edu
> +L: kvm...@lists.linux.dev
> +L: kvmarm@lists.cs.columbia.edu (deprecated)

As the days of the Columbia list really seem to be numbered (see
https://lore.kernel.org/all/364100e884023234e4ab9e525774d...@kernel.org/),
should we maybe drop it completely from MAINTAINERS, depending on when
this gets merged?

>  F: arm/
>  F: lib/arm/
>  F: lib/arm64/

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH] MAINTAINERS: new kvmarm mailing list

[Cornelia Huck]

KVM/arm64 development is moving to a new mailing list (see
https://lore.kernel.org/all/20221001091245.3900668-1-...@kernel.org/);
kvm-unit-tests should advertise the new list as well.

Signed-off-by: Cornelia Huck 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90ead214a75d..649de509a511 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -67,7 +67,8 @@ ARM
 M: Andrew Jones 
 S: Supported
 L: k...@vger.kernel.org
-L: kvmarm@lists.cs.columbia.edu
+L: kvm...@lists.linux.dev
+L: kvmarm@lists.cs.columbia.edu (deprecated)
 F: arm/
 F: lib/arm/
 F: lib/arm64/
-- 
2.37.3

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 1/7] arm64: mte: Fix/clarify the PG_mte_tagged semantics

[Cornelia Huck]

On Wed, Aug 10 2022, Peter Collingbourne  wrote:

> From: Catalin Marinas 
>
> Currently the PG_mte_tagged page flag mostly means the page contains
> valid tags and it should be set after the tags have been cleared or
> restored. However, in mte_sync_tags() it is set before setting the tags
> to avoid, in theory, a race with concurrent mprotect(PROT_MTE) for
> shared pages. However, a concurrent mprotect(PROT_MTE) with a copy on
> write in another thread can cause the new page to have stale tags.
> Similarly, tag reading via ptrace() can read stale tags of the

s/of/if/

> PG_mte_tagged flag is set before actually clearing/restoring the tags.
>
> Fix the PG_mte_tagged semantics so that it is only set after the tags
> have been cleared or restored. This is safe for swap restoring into a
> MAP_SHARED or CoW page since the core code takes the page lock. Add two
> functions to test and set the PG_mte_tagged flag with acquire and
> release semantics. The downside is that concurrent mprotect(PROT_MTE) on
> a MAP_SHARED page may cause tag loss. This is already the case for KVM
> guests if a VMM changes the page protection while the guest triggers a
> user_mem_abort().
>
> Signed-off-by: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: Steven Price 
> Cc: Peter Collingbourne 
> ---
> v3:
> - fix build with CONFIG_ARM64_MTE disabled
>
>  arch/arm64/include/asm/mte.h | 30 ++
>  arch/arm64/include/asm/pgtable.h |  2 +-
>  arch/arm64/kernel/cpufeature.c   |  4 +++-
>  arch/arm64/kernel/elfcore.c  |  2 +-
>  arch/arm64/kernel/hibernate.c|  2 +-
>  arch/arm64/kernel/mte.c  | 12 +++-
>  arch/arm64/kvm/guest.c   |  4 ++--
>  arch/arm64/kvm/mmu.c |  4 ++--
>  arch/arm64/mm/copypage.c |  4 ++--
>  arch/arm64/mm/fault.c|  2 +-
>  arch/arm64/mm/mteswap.c  |  2 +-
>  11 files changed, 51 insertions(+), 17 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs

[Cornelia Huck]

On Tue, Jul 19 2022, Peter Collingbourne  wrote:

> On Tue, Jul 19, 2022 at 7:50 AM Cornelia Huck  wrote:
>>
>> On Fri, Jul 08 2022, Peter Collingbourne  wrote:
>>
>> > Hi,
>> >
>> > This patch series contains a proposed extension to pKVM that allows MTE
>> > to be exposed to the protected guests. It is based on the base pKVM
>> > series previously sent to the list [1] and later rebased to 5.19-rc3
>> > and uploaded to [2].
>> >
>> > This series takes precautions against host compromise of the guests
>> > via direct access to their tag storage, by preventing the host from
>> > accessing the tag storage via stage 2 page tables. The device tree
>> > must describe the physical memory address of the tag storage, if any,
>> > and the memory nodes must declare that the tag storage location is
>> > described. Otherwise, the MTE feature is disabled in protected guests.
>> >
>> > Now that we can easily do so, we also prevent the host from accessing
>> > any unmapped reserved-memory regions without a driver, as the host
>> > has no business accessing that memory.
>> >
>> > A proposed extension to the devicetree specification is available at
>> > [3], a patched version of QEMU that produces the required device tree
>> > nodes is available at [4] and a patched version of the crosvm hypervisor
>> > that enables MTE is available at [5].
>>
>> I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU
>> patch adds mte-alloc properties to regions that are exposed as a
>> separate address space (which will not work with KVM). Is the magic in
>> that new shared section?
>
> Hi Cornelia,
>
> The intent is that the mte-alloc property may be set on memory whose
> allocation tag storage is not directly accessible via physical memory,
> since in this case there is no need for the hypervisor to do anything
> to protect allocation tag storage before exposing MTE to guests. In
> the case of QEMU + KVM, I would expect the emulated system to not
> expose the allocation tag storage directly, in which case it would be
> able to set mte-alloc on all memory nodes without further action,
> exactly as my patch implements for TCG. With the interface as
> proposed, QEMU would need to reject the mte-shared-alloc option when
> KVM is enabled, as there is currently no mechanism for KVM-accelerated
> virtualized tag storage.

Ok, that makes sense.

>
> Note that these properties are only relevant for guest kernels running
> under an emulated EL2 in which pKVM could conceivably run, which means
> that the host would need to implement FEAT_NV2. As far as I know there
> is currently no support for NV2 neither in QEMU TCG nor in the Linux
> kernel, and I'm unaware of any available hardware that supports both
> NV2 and MTE, so it'll be a while before any of this becomes relevant.

Nod.

I'm mostly interested because I wanted to figure out how this feature
might interact with enabling MTE for QEMU+KVM. I'll keep it in mind.

Thanks!

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs

[Cornelia Huck]

On Fri, Jul 08 2022, Peter Collingbourne  wrote:

> Hi,
>
> This patch series contains a proposed extension to pKVM that allows MTE
> to be exposed to the protected guests. It is based on the base pKVM
> series previously sent to the list [1] and later rebased to 5.19-rc3
> and uploaded to [2].
>
> This series takes precautions against host compromise of the guests
> via direct access to their tag storage, by preventing the host from
> accessing the tag storage via stage 2 page tables. The device tree
> must describe the physical memory address of the tag storage, if any,
> and the memory nodes must declare that the tag storage location is
> described. Otherwise, the MTE feature is disabled in protected guests.
>
> Now that we can easily do so, we also prevent the host from accessing
> any unmapped reserved-memory regions without a driver, as the host
> has no business accessing that memory.
>
> A proposed extension to the devicetree specification is available at
> [3], a patched version of QEMU that produces the required device tree
> nodes is available at [4] and a patched version of the crosvm hypervisor
> that enables MTE is available at [5].

I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU
patch adds mte-alloc properties to regions that are exposed as a
separate address space (which will not work with KVM). Is the magic in
that new shared section?

>
> v2:
> - refcount the PTEs owned by NOBODY
>
> [1] https://lore.kernel.org/all/20220519134204.5379-1-w...@kernel.org/
> [2] https://android-kvm.googlesource.com/linux/ for-upstream/pkvm-base-v2
> [3] https://github.com/pcc/devicetree-specification mte-alloc
> [4] https://github.com/pcc/qemu mte-shared-alloc
> [5] 
> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3719324
>
> Peter Collingbourne (3):
>   KVM: arm64: add a hypercall for disowning pages
>   KVM: arm64: disown unused reserved-memory regions
>   KVM: arm64: allow MTE in protected VMs if the tag storage is known
>
>  arch/arm64/include/asm/kvm_asm.h  |  1 +
>  arch/arm64/include/asm/kvm_host.h |  6 ++
>  arch/arm64/include/asm/kvm_pkvm.h |  4 +-
>  arch/arm64/kernel/image-vars.h|  3 +
>  arch/arm64/kvm/arm.c  | 83 ++-
>  arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |  1 +
>  arch/arm64/kvm/hyp/include/nvhe/pkvm.h|  1 +
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c|  9 ++
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c | 11 +++
>  arch/arm64/kvm/hyp/nvhe/pkvm.c|  8 +-
>  arch/arm64/kvm/mmu.c  |  4 +-
>  11 files changed, 123 insertions(+), 8 deletions(-)

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled

[Cornelia Huck]

On Fri, Jul 08 2022, Peter Xu  wrote:

> On Fri, Jul 08, 2022 at 03:03:34PM +0200, Cornelia Huck wrote:

>> I was thinking about a new flag that implies "copy metadata"; not sure
>> how we would get the same atomicity with a separate ioctl. I've only
>> just started looking at userfaultfd, though, and I might be on a wrong
>> track... One thing I'd like to avoid is having something that is too
>> ARM-specific, I think there are other architecture features that might
>> have similar issues.
>
> Agreed, to propose such an interface we'd better make sure it'll be easily
> applicable to other similar memory protection mechanisms elsewhere.

There's storage keys on s390, although I believe they are considered
legacy by now. I dimly recall something in x86 land.

>
>> 
>> Maybe someone more familiar with uffd and/or postcopy can chime in?
>
> Hanving UFFDIO_COPY provide a new flag sounds reasonable to me.  I'm
> curious what's the maximum possible size of the tags and whether they can
> be embeded already into struct uffdio_copy somehow.

Each tag is four bits and covers 16 bytes (also see the defs in
arch/arm64/include/asm/mte-def.h).

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled

[Cornelia Huck]

On Mon, Jul 04 2022, Steven Price  wrote:

> On 04/07/2022 13:19, Cornelia Huck wrote:
>> On Mon, Jul 04 2022, Steven Price  wrote:
>> 
>>> On 29/06/2022 09:45, Catalin Marinas wrote:
>>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote:
>>>
>>>>> [Postcopy needs a different interface, I guess, so that the migration
>>>>> target can atomically place a received page and its metadata. I see
>>>>> https://lore.kernel.org/all/cajc+z1fzxsyb_zjit4+0utr-88vqql+-01xnmsefua-dxdy...@mail.gmail.com/;
>>>>> has there been any follow-up?]
>>>>
>>>> I don't follow the qemu list, so I wasn't even aware of that thread. But
>>>> postcopy, the VMM needs to ensure that both the data and tags are up to
>>>> date before mapping such page into the guest address space.
>>>>
>>>
>>> I'm not sure I see how atomically updating data+tags is different from
>>> the existing issues around atomically updating the data. The VMM needs
>>> to ensure that the guest doesn't see the page before all the data+all
>>> the tags are written. It does mean lazy setting of the tags isn't
>>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway.
>>> Perhaps I'm missing something?
>> 
>> For postcopy, we basically want to fault in any not-yet-migrated page
>> via uffd once the guest accesses it. We only get the page data that way,
>> though, not the tag. I'm wondering whether we'd need a 'page+metadata'
>> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop
>> the guest while grabbing the tags for the page as well, and stopping is
>> the thing we want to avoid here.
>
> Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page
> and ensures that no thread will see the partially populated page. But
> there's currently no way of doing that with tags as well.

Nod.

>
> I'd not looked at the implementation of userfaultfd before and I'd
> assumed it avoided the need for an 'atomic' operation like this. But
> apparently not! AFAICT either a new ioctl would be needed (which can
> take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the
> alignment requirements of `src` and would copy the tags along with the data.

I was thinking about a new flag that implies "copy metadata"; not sure
how we would get the same atomicity with a separate ioctl. I've only
just started looking at userfaultfd, though, and I might be on a wrong
track... One thing I'd like to avoid is having something that is too
ARM-specific, I think there are other architecture features that might
have similar issues.

Maybe someone more familiar with uffd and/or postcopy can chime in?

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled

[Cornelia Huck]

On Mon, Jul 04 2022, Steven Price  wrote:

> On 29/06/2022 09:45, Catalin Marinas wrote:
>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote:
>>> [I'm still in the process of trying to grok the issues surrounding
>>> MTE+KVM, so apologies in advance if I'm muddying the waters]
>> 
>> No worries, we are not that far ahead either ;).
>> 
>>> On Sat, Jun 25 2022, Steven Price  wrote:
>>>> On 24/06/2022 18:05, Catalin Marinas wrote:
>>>>> + Steven as he added the KVM and swap support for MTE.
>>>>>
>>>>> On Thu, Jun 23, 2022 at 04:49:44PM -0700, Peter Collingbourne wrote:
>>>>>> Certain VMMs such as crosvm have features (e.g. sandboxing, pmem) that
>>>>>> depend on being able to map guest memory as MAP_SHARED. The current
>>>>>> restriction on sharing MAP_SHARED pages with the guest is preventing
>>>>>> the use of those features with MTE. Therefore, remove this restriction.
>>>>>
>>>>> We already have some corner cases where the PG_mte_tagged logic fails
>>>>> even for MAP_PRIVATE (but page shared with CoW). Adding this on top for
>>>>> KVM MAP_SHARED will potentially make things worse (or hard to reason
>>>>> about; for example the VMM sets PROT_MTE as well). I'm more inclined to
>>>>> get rid of PG_mte_tagged altogether, always zero (or restore) the tags
>>>>> on user page allocation, copy them on write. For swap we can scan and if
>>>>> all tags are 0 and just skip saving them.
>>>>>
>>>>> Another aspect is a change in the KVM ABI with this patch. It's probably
>>>>> not that bad since it's rather a relaxation but it has the potential to
>>>>> confuse the VMM, especially as it doesn't know whether it's running on
>>>>> older kernels or not (it would have to probe unless we expose this info
>>>>> to the VMM in some other way).
>>>
>>> Which VMMs support KVM+MTE so far? (I'm looking at adding support in QEMU.)
>> 
>> Steven to confirm but I think he only played with kvmtool. Adding
>> Jean-Philippe who also had Qemu on his plans at some point.
>
> Yes I've only played with kvmtool so far. 'basic support' at the moment
> is little more than enabling the cap - that allows the guest to access
> tags. However obviously aspects such as migration need to understand
> what's going on to correctly save/restore tags - which is mostly only
> relevant to Qemu.

Yes, simply only enabling the cap seems to work fine in QEMU as well (as
in, 'mte selftests work fine'). Migration support is the
hard/interesting part.

>
>>> What happens in kvm_vm_ioctl_mte_copy_tags()? I think we would just end
>>> up copying zeroes?
>> 
>> Yes. For migration, the VMM could ignore sending over tags that are all
>> zeros or maybe use some simple compression. We don't have a way to
>> disable MTE for guests, so all pages mapped into the guest address space
>> end up with PG_mte_tagged.
>
> Architecturally we don't (yet) have a way of describing memory without
> tags, so indeed you will get all zeros if the guest hasn't populated the
> tags yet.

Nod.

>
>>> That said, do we make any assumptions about when KVM_ARM_MTE_COPY_TAGS
>>> will be called? I.e. when implementing migration, it should be ok to
>>> call it while the vm is paused, but you probably won't get a consistent
>>> state while the vm is running?
>> 
>> Wouldn't this be the same as migrating data? The VMM would only copy it
>> after it was marked read-only. BTW, I think sanitise_mte_tags() needs a
>> barrier before setting the PG_mte_tagged() flag (unless we end up with
>> some lock for reading the tags).
>
> As Catalin says, tags are no different from data so the VMM needs to
> either pause the VM or mark the page read-only to protect it from guest
> updates during the copy.

Yes, that seems reasonable; not sure whether the documentation should
call that out explicitly.

>
> The whole test_bit/set_bit dance does seem to be leaving open race
> conditions. I /think/ that Peter's extra flag as a lock with an added
> memory barrier is sufficient to mitigate it, but at this stage I'm also
> thinking some formal modelling would be wise as I don't trust my
> intuition when it comes to memory barriers.
>
>>> [Postcopy needs a different interface, I guess, so that the migration
>>> target can atomically place a received page and its metadata. I see
>>> https://lore.kernel.org/all/cajc+z1fzxsyb_zjit4+0utr-88vqql+-01xnmsefua-dxdy...@mail.gmail.com/;
&

Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled

[Cornelia Huck]

[I'm still in the process of trying to grok the issues surrounding
MTE+KVM, so apologies in advance if I'm muddying the waters]

On Sat, Jun 25 2022, Steven Price  wrote:

> On 24/06/2022 18:05, Catalin Marinas wrote:
>> + Steven as he added the KVM and swap support for MTE.
>> 
>> On Thu, Jun 23, 2022 at 04:49:44PM -0700, Peter Collingbourne wrote:
>>> Certain VMMs such as crosvm have features (e.g. sandboxing, pmem) that
>>> depend on being able to map guest memory as MAP_SHARED. The current
>>> restriction on sharing MAP_SHARED pages with the guest is preventing
>>> the use of those features with MTE. Therefore, remove this restriction.
>> 
>> We already have some corner cases where the PG_mte_tagged logic fails
>> even for MAP_PRIVATE (but page shared with CoW). Adding this on top for
>> KVM MAP_SHARED will potentially make things worse (or hard to reason
>> about; for example the VMM sets PROT_MTE as well). I'm more inclined to
>> get rid of PG_mte_tagged altogether, always zero (or restore) the tags
>> on user page allocation, copy them on write. For swap we can scan and if
>> all tags are 0 and just skip saving them.
>> 
>> Another aspect is a change in the KVM ABI with this patch. It's probably
>> not that bad since it's rather a relaxation but it has the potential to
>> confuse the VMM, especially as it doesn't know whether it's running on
>> older kernels or not (it would have to probe unless we expose this info
>> to the VMM in some other way).

Which VMMs support KVM+MTE so far? (I'm looking at adding support in QEMU.)

>> 
>>> To avoid races between multiple tasks attempting to clear tags on the
>>> same page, introduce a new page flag, PG_mte_tag_clearing, and test-set it
>>> atomically before beginning to clear tags on a page. If the flag was not
>>> initially set, spin until the other task has finished clearing the tags.
>> 
>> TBH, I can't mentally model all the corner cases, so maybe a formal
>> model would help (I can have a go with TLA+, though not sure when I find
>> a bit of time this summer). If we get rid of PG_mte_tagged altogether,
>> this would simplify things (hopefully).
>> 
>> As you noticed, the problem is that setting PG_mte_tagged and clearing
>> (or restoring) the tags is not an atomic operation. There are places
>> like mprotect() + CoW where one task can end up with stale tags. Another
>> is shared memfd mappings if more than one mapping sets PROT_MTE and
>> there's the swap restoring on top.
>> 
>>> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
>>> index f6b00743c399..8f9655053a9f 100644
>>> --- a/arch/arm64/kernel/mte.c
>>> +++ b/arch/arm64/kernel/mte.c
>>> @@ -57,7 +57,18 @@ static void mte_sync_page_tags(struct page *page, pte_t 
>>> old_pte,
>>>  * the new page->flags are visible before the tags were updated.
>>>  */
>>> smp_wmb();
>>> -   mte_clear_page_tags(page_address(page));
>>> +   mte_ensure_page_tags_cleared(page);
>>> +}
>>> +
>>> +void mte_ensure_page_tags_cleared(struct page *page)
>>> +{
>>> +   if (test_and_set_bit(PG_mte_tag_clearing, >flags)) {
>>> +   while (!test_bit(PG_mte_tagged, >flags))
>>> +   ;
>>> +   } else {
>>> +   mte_clear_page_tags(page_address(page));
>>> +   set_bit(PG_mte_tagged, >flags);
>>> +   }
>
> I'm pretty sure we need some form of barrier in here to ensure the tag
> clearing is visible to the other CPU. Otherwise I can't immediately see
> any problems with the approach of a second flag (it was something I had
> considered). But I do also think we should seriously consider Catalin's
> approach of simply zeroing tags unconditionally - it would certainly
> simplify the code.

What happens in kvm_vm_ioctl_mte_copy_tags()? I think we would just end
up copying zeroes?

That said, do we make any assumptions about when KVM_ARM_MTE_COPY_TAGS
will be called? I.e. when implementing migration, it should be ok to
call it while the vm is paused, but you probably won't get a consistent
state while the vm is running?

[Postcopy needs a different interface, I guess, so that the migration
target can atomically place a received page and its metadata. I see
https://lore.kernel.org/all/cajc+z1fzxsyb_zjit4+0utr-88vqql+-01xnmsefua-dxdy...@mail.gmail.com/;
has there been any follow-up?]

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH v2 0/7] unify header guards

[Cornelia Huck]

On Thu, Jun 10 2021, Paolo Bonzini  wrote:

> On Wed, 9 Jun 2021 16:37:05 +0200, Cornelia Huck wrote:
>> This is an extension of "s390x: unify header guards" to the rest
>> of kvm-unit-tests. I tried to choose a pattern that minimizes the
>> changes; most of them are for s390x and x86.
>> 
>> v1->v2:
>> - change the patterns and document them
>> - change other architectures and architecture-independent code as well
>> 
>> [...]
>
> Applied, thanks!
>
> [1/7] README.md: add guideline for header guards format
>   commit: 844669a9631d78a54b47f6667c9a2750b65d101c
> [2/7] lib: unify header guards
>   commit: 9f0ae3012430ed7072d04247fb674125c616a6b4
> [3/7] asm-generic: unify header guards
>   commit: 951e6299b30016bf04a343973296c4274e87f0e2
> [4/7] arm: unify header guards
>   commit: 16f52ec9a4763e62e35453497e4f077031abcbfb
> [5/7] powerpc: unify header guards
>   commit: 040ee6d9aee563b2b1f28e810c5e36fbbcc17bd9
> [6/7] s390x: unify header guards
>   commit: eb5a1bbab00619256b76177e7a88cfe05834b026
> [7/7] x86: unify header guards
>   commit: c865f654ffe4c5955038aaf74f702ba62f3eb014

Oh, that was quick :)

I'll do some further (small) updates on top, then.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH v2 4/7] arm: unify header guards

[Cornelia Huck]

On Wed, Jun 09 2021, Laurent Vivier  wrote:

> On 09/06/2021 16:37, Cornelia Huck wrote:
>> The assembler.h files were the only ones not already following
>> the convention.
>> 
>> Signed-off-by: Cornelia Huck 
>> ---
>>  lib/arm/asm/assembler.h   | 6 +++---
>>  lib/arm64/asm/assembler.h | 6 +++---
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> What about lib/arm/io.h?

It didn't have a guard yet, so I didn't touch it.

>
> I think you can remove the guard from
>
> lib/arm/asm/memory_areas.h
>
> as the other files including directly a header doesn't guard it.

I see other architectures doing that, though. I guess it doesn't hurt,
but we can certainly also remove it. Other opinions?

>
> Missing lib/arm/asm/mmu-api.h, lib/arm/asm/mmu.h, lib/arm64/asm/mmu.h

Oops, overlooked the extra underscore there.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH v2 2/7] lib: unify header guards

[Cornelia Huck]

On Wed, Jun 09 2021, Laurent Vivier  wrote:

> On 09/06/2021 16:37, Cornelia Huck wrote:
>> Standardize header guards to _LIB_HEADER_H_.
>> 
>> Signed-off-by: Cornelia Huck 
>> ---
>>  lib/alloc_page.h   | 4 ++--
>>  lib/libcflat.h | 4 ++--
>>  lib/list.h | 4 ++--
>>  lib/pci-edu.h  | 4 ++--
>>  lib/pci-host-generic.h | 4 ++--
>>  lib/setjmp.h   | 4 ++--
>>  lib/string.h   | 6 +++---
>>  lib/vmalloc.h  | 4 ++--
>>  8 files changed, 17 insertions(+), 17 deletions(-)
>
> What about lib/argv.h and lib/pci.h?

argv.h does not have a header guard yet (it probably should?)

I forgot to commit my changes to pci.h, I think :(

>
> And there is also this instance of CONFIG_H in lib/config.h generated
> by configure.

Yeah, we should tweak the generator for that.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [kvm-unit-tests PATCH v2 1/7] README.md: add guideline for header guards format

[Cornelia Huck]

On Wed, Jun 09 2021, David Hildenbrand  wrote:

> On 09.06.21 16:37, Cornelia Huck wrote:
>> Signed-off-by: Cornelia Huck 
>> ---
>>   README.md | 9 +
>>   1 file changed, 9 insertions(+)
>> 
>> diff --git a/README.md b/README.md
>> index 24d4bdaaee0d..687ff50d0af1 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -156,6 +156,15 @@ Exceptions:
>>   
>> - While the kernel standard requires 80 columns, we allow up to 120.
>>   
>> +Header guards:
>> +
>> +Please try to adhere to adhere to the following patterns when adding
>> +"#ifndef <...> #define <...>" header guards:
>> +./lib: _HEADER_H_
>> +./lib/:  _ARCH_HEADER_H_
>> +./lib//asm:  _ASMARCH_HEADER_H_
>
> I'd have used _ARCH_ASM_HEADER_H_

I had that first, but the pattern I ended up using caused way less churn
(this is basically what arm[64] uses.)

>
> Reviewed-by: David Hildenbrand 

Thanks!

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 7/7] x86: unify header guards

[Cornelia Huck]

Standardize header guards to _ASMX86_HEADER_H_, _X86_HEADER_H_,
and X86_HEADER_H.

Signed-off-by: Cornelia Huck 
---
 lib/x86/acpi.h | 4 ++--
 lib/x86/apic-defs.h| 6 +++---
 lib/x86/apic.h | 4 ++--
 lib/x86/asm/barrier.h  | 4 ++--
 lib/x86/asm/debugreg.h | 6 +++---
 lib/x86/asm/io.h   | 4 ++--
 lib/x86/asm/memory_areas.h | 4 ++--
 lib/x86/asm/page.h | 4 ++--
 lib/x86/asm/pci.h  | 4 ++--
 lib/x86/asm/spinlock.h | 4 ++--
 lib/x86/asm/stack.h| 4 ++--
 lib/x86/atomic.h   | 4 ++--
 lib/x86/delay.h| 4 ++--
 lib/x86/desc.h | 4 ++--
 lib/x86/fault_test.h   | 4 ++--
 lib/x86/fwcfg.h| 4 ++--
 lib/x86/intel-iommu.h  | 4 ++--
 lib/x86/isr.h  | 4 ++--
 lib/x86/msr.h  | 6 +++---
 lib/x86/processor.h| 4 ++--
 lib/x86/smp.h  | 4 ++--
 lib/x86/usermode.h | 4 ++--
 lib/x86/vm.h   | 4 ++--
 x86/hyperv.h   | 4 ++--
 x86/ioram.h| 4 ++--
 x86/kvmclock.h | 4 ++--
 x86/svm.h  | 4 ++--
 x86/types.h| 4 ++--
 x86/vmx.h  | 4 ++--
 29 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/lib/x86/acpi.h b/lib/x86/acpi.h
index 08aaf57a7890..1b803740f331 100644
--- a/lib/x86/acpi.h
+++ b/lib/x86/acpi.h
@@ -1,5 +1,5 @@
-#ifndef KVM_ACPI_H
-#define KVM_ACPI_H 1
+#ifndef _X86_ACPI_H_
+#define _X86_ACPI_H_
 
 #include "libcflat.h"
 
diff --git a/lib/x86/apic-defs.h b/lib/x86/apic-defs.h
index b2014de800a7..dabefe7879ea 100644
--- a/lib/x86/apic-defs.h
+++ b/lib/x86/apic-defs.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_APICDEF_H
-#define _ASM_X86_APICDEF_H
+#ifndef _X86_APIC_DEFS_H_
+#define _X86_APIC_DEFS_H_
 
 /*
  * Abuse this header file to hold the number of max-cpus, making it available
@@ -144,4 +144,4 @@
 
 #define APIC_BASE_MSR  0x800
 
-#endif /* _ASM_X86_APICDEF_H */
+#endif /* _X86_APIC_DEFS_H_ */
diff --git a/lib/x86/apic.h b/lib/x86/apic.h
index a7eff6354a83..c4821716b352 100644
--- a/lib/x86/apic.h
+++ b/lib/x86/apic.h
@@ -1,5 +1,5 @@
-#ifndef CFLAT_APIC_H
-#define CFLAT_APIC_H
+#ifndef _X86_APIC_H_
+#define _X86_APIC_H_
 
 #include 
 #include "apic-defs.h"
diff --git a/lib/x86/asm/barrier.h b/lib/x86/asm/barrier.h
index 193fb4c2e712..66c8f56f1c9a 100644
--- a/lib/x86/asm/barrier.h
+++ b/lib/x86/asm/barrier.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_BARRIER_H_
-#define _ASM_X86_BARRIER_H_
+#ifndef _ASMX86_BARRIER_H_
+#define _ASMX86_BARRIER_H_
 /*
  * Copyright (C) 2016, Red Hat Inc, Alexander Gordeev 
  *
diff --git a/lib/x86/asm/debugreg.h b/lib/x86/asm/debugreg.h
index d95d080b30e3..e86f5a629480 100644
--- a/lib/x86/asm/debugreg.h
+++ b/lib/x86/asm/debugreg.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_ASM_X86_DEBUGREG_H
-#define _UAPI_ASM_X86_DEBUGREG_H
+#ifndef _ASMX86_DEBUGREG_H_
+#define _ASMX86_DEBUGREG_H_
 
 
 /* Indicate the register numbers for a number of the specific
@@ -78,4 +78,4 @@
  * HW breakpoint additions
  */
 
-#endif /* _UAPI_ASM_X86_DEBUGREG_H */
+#endif /* _ASMX86_DEBUGREG_H_ */
diff --git a/lib/x86/asm/io.h b/lib/x86/asm/io.h
index 35a5c7347411..88734320aa93 100644
--- a/lib/x86/asm/io.h
+++ b/lib/x86/asm/io.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_IO_H_
-#define _ASM_X86_IO_H_
+#ifndef _ASMX86_IO_H_
+#define _ASMX86_IO_H_
 
 #define __iomem
 
diff --git a/lib/x86/asm/memory_areas.h b/lib/x86/asm/memory_areas.h
index e84016f8b060..bd47a89aba7d 100644
--- a/lib/x86/asm/memory_areas.h
+++ b/lib/x86/asm/memory_areas.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_MEMORY_AREAS_H_
-#define _ASM_X86_MEMORY_AREAS_H_
+#ifndef _ASMX86_MEMORY_AREAS_H_
+#define _ASMX86_MEMORY_AREAS_H_
 
 #define AREA_NORMAL_PFN BIT(36-12)
 #define AREA_NORMAL_NUMBER 0
diff --git a/lib/x86/asm/page.h b/lib/x86/asm/page.h
index 2cf8881e16d2..fc1416071ec9 100644
--- a/lib/x86/asm/page.h
+++ b/lib/x86/asm/page.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_X86_PAGE_H_
-#define _ASM_X86_PAGE_H_
+#ifndef _ASMX86_PAGE_H_
+#define _ASMX86_PAGE_H_
 /*
  * Copyright (C) 2016, Red Hat Inc, Alexander Gordeev 
  *
diff --git a/lib/x86/asm/pci.h b/lib/x86/asm/pci.h
index c937e5cd71e1..03e55c277f12 100644
--- a/lib/x86/asm/pci.h
+++ b/lib/x86/asm/pci.h
@@ -1,5 +1,5 @@
-#ifndef ASM_PCI_H
-#define ASM_PCI_H
+#ifndef _ASMX86_PCI_H_
+#define _ASMX86_PCI_H_
 /*
  * Copyright (C) 2013, Red Hat Inc, Michael S. Tsirkin 
  *
diff --git a/lib/x86/asm/spinlock.h b/lib/x86/asm/spinlock.h
index 692020c5185c..34fadf771c11 100644
--- a/lib/x86/asm/spinlock.h
+++ b/lib/x86/asm/spinlock.h
@@ -1,5 +1,5 @@
-#ifndef __ASM_SPINLOCK_H
-#define __ASM_SPINLOCK_H
+#ifndef _ASMX86_SPINLOCK_H_
+#define _ASMX86_SPINLOCK_H_
 
 #include 
 
diff --git a/lib/x86/asm/stack.h b/lib/x86/asm/stack.h
index b14e2c0fa012..417695373801 100644
--- a/lib/x86/asm/stack.h
+++ b/lib/x86/asm/stack.h
@@ -1,5 +1,5 @@
-#ifndef _X86ASM_STACK_H_
-#define _X86ASM_STACK_H_
+#ifndef _ASMX

[kvm-unit-tests PATCH v2 6/7] s390x: unify header guards

[Cornelia Huck]

Standardize header guards to _ASMS390X_HEADER_H_, _S390X_HEADER_H_,
and S390X_HEADER_H, respectively.

Signed-off-by: Cornelia Huck 
---
 lib/s390x/asm/arch_def.h | 4 ++--
 lib/s390x/asm/barrier.h  | 4 ++--
 lib/s390x/asm/cpacf.h| 6 +++---
 lib/s390x/asm/facility.h | 4 ++--
 lib/s390x/asm/float.h| 4 ++--
 lib/s390x/asm/mem.h  | 4 ++--
 lib/s390x/asm/sigp.h | 6 +++---
 lib/s390x/asm/spinlock.h | 4 ++--
 lib/s390x/asm/time.h | 4 ++--
 lib/s390x/asm/uv.h   | 4 ++--
 lib/s390x/css.h  | 4 ++--
 lib/s390x/interrupt.h| 4 ++--
 lib/s390x/mmu.h  | 4 ++--
 lib/s390x/sclp.h | 6 +++---
 lib/s390x/sie.h  | 6 +++---
 lib/s390x/smp.h  | 4 ++--
 lib/s390x/uv.h   | 4 ++--
 lib/s390x/vm.h   | 6 +++---
 s390x/sthyi.h| 4 ++--
 19 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/lib/s390x/asm/arch_def.h b/lib/s390x/asm/arch_def.h
index 7e2c5e623ab2..76f9e3862965 100644
--- a/lib/s390x/asm/arch_def.h
+++ b/lib/s390x/asm/arch_def.h
@@ -5,8 +5,8 @@
  * Authors:
  *  David Hildenbrand 
  */
-#ifndef _ASM_S390X_ARCH_DEF_H_
-#define _ASM_S390X_ARCH_DEF_H_
+#ifndef _ASMS390X_ARCH_DEF_H_
+#define _ASMS390X_ARCH_DEF_H_
 
 struct stack_frame {
struct stack_frame *back_chain;
diff --git a/lib/s390x/asm/barrier.h b/lib/s390x/asm/barrier.h
index 8e2fd6d90034..9534f9e8fa96 100644
--- a/lib/s390x/asm/barrier.h
+++ b/lib/s390x/asm/barrier.h
@@ -6,8 +6,8 @@
  *  Thomas Huth 
  *  David Hildenbrand 
  */
-#ifndef _ASM_S390X_BARRIER_H_
-#define _ASM_S390X_BARRIER_H_
+#ifndef _ASMS390X_BARRIER_H_
+#define _ASMS390X_BARRIER_H_
 
 #include 
 
diff --git a/lib/s390x/asm/cpacf.h b/lib/s390x/asm/cpacf.h
index 805fcf1a2d71..685262b0ff62 100644
--- a/lib/s390x/asm/cpacf.h
+++ b/lib/s390x/asm/cpacf.h
@@ -8,8 +8,8 @@
  *   Harald Freudenberger (fre...@de.ibm.com)
  *   Martin Schwidefsky 
  */
-#ifndef _ASM_S390_CPACF_H
-#define _ASM_S390_CPACF_H
+#ifndef _ASMS390X_CPACF_H_
+#define _ASMS390X_CPACF_H_
 
 #include 
 #include 
@@ -471,4 +471,4 @@ static inline void cpacf_pckmo(long func, void *param)
: "cc", "memory");
 }
 
-#endif /* _ASM_S390_CPACF_H */
+#endif /* _ASMS390X_CPACF_H_ */
diff --git a/lib/s390x/asm/facility.h b/lib/s390x/asm/facility.h
index 95d4a15fe34f..ef0fd037ed35 100644
--- a/lib/s390x/asm/facility.h
+++ b/lib/s390x/asm/facility.h
@@ -5,8 +5,8 @@
  * Authors:
  *  David Hildenbrand 
  */
-#ifndef _ASM_S390X_FACILITY_H_
-#define _ASM_S390X_FACILITY_H_
+#ifndef _ASMS390X_FACILITY_H_
+#define _ASMS390X_FACILITY_H_
 
 #include 
 #include 
diff --git a/lib/s390x/asm/float.h b/lib/s390x/asm/float.h
index 136794475849..eb752050b162 100644
--- a/lib/s390x/asm/float.h
+++ b/lib/s390x/asm/float.h
@@ -5,8 +5,8 @@
  * Authors:
  *  David Hildenbrand 
  */
-#ifndef _ASM_S390X_FLOAT_H_
-#define _ASM_S390X_FLOAT_H_
+#ifndef _ASMS390X_FLOAT_H_
+#define _ASMS390X_FLOAT_H_
 
 static inline void set_fpc(uint32_t fpc)
 {
diff --git a/lib/s390x/asm/mem.h b/lib/s390x/asm/mem.h
index 281390ebd816..1963cef7ec03 100644
--- a/lib/s390x/asm/mem.h
+++ b/lib/s390x/asm/mem.h
@@ -5,8 +5,8 @@
  * Copyright IBM Corp. 2018
  * Author(s): Janosch Frank 
  */
-#ifndef _ASM_S390_MEM_H
-#define _ASM_S390_MEM_H
+#ifndef _ASMS390X_MEM_H_
+#define _ASMS390X_MEM_H_
 
 #define SKEY_ACC   0xf0
 #define SKEY_FP0x08
diff --git a/lib/s390x/asm/sigp.h b/lib/s390x/asm/sigp.h
index 00844d26d15a..61d2c6256fed 100644
--- a/lib/s390x/asm/sigp.h
+++ b/lib/s390x/asm/sigp.h
@@ -5,8 +5,8 @@
  * Copied from the Linux kernel file arch/s390/include/asm/sigp.h
  */
 
-#ifndef ASM_S390X_SIGP_H
-#define ASM_S390X_SIGP_H
+#ifndef _ASMS390X_SIGP_H_
+#define _ASMS390X_SIGP_H_
 
 /* SIGP order codes */
 #define SIGP_SENSE 1
@@ -73,4 +73,4 @@ static inline int sigp_retry(uint16_t addr, uint8_t order, 
unsigned long parm,
 }
 
 #endif /* __ASSEMBLER__ */
-#endif /* ASM_S390X_SIGP_H */
+#endif /* _ASMS390X_SIGP_H_ */
diff --git a/lib/s390x/asm/spinlock.h b/lib/s390x/asm/spinlock.h
index 677d2cd6e287..22d4d3899569 100644
--- a/lib/s390x/asm/spinlock.h
+++ b/lib/s390x/asm/spinlock.h
@@ -6,8 +6,8 @@
  *  Thomas Huth 
  *  David Hildenbrand 
  */
-#ifndef __ASMS390X_SPINLOCK_H
-#define __ASMS390X_SPINLOCK_H
+#ifndef _ASMS390X_SPINLOCK_H_
+#define _ASMS390X_SPINLOCK_H_
 
 #include 
 
diff --git a/lib/s390x/asm/time.h b/lib/s390x/asm/time.h
index 0d67f7231992..7652a151e87a 100644
--- a/lib/s390x/asm/time.h
+++ b/lib/s390x/asm/time.h
@@ -8,8 +8,8 @@
  * Copied from the s390/intercept test by:
  *  Pierre Morel 
  */
-#ifndef ASM_S390X_TIME_H
-#define ASM_S390X_TIME_H
+#ifndef _ASMS390X_TIME_H_
+#define _ASMS390X_TIME_H_
 
 #define STCK_SHIFT_US  (63 - 51)
 #define STCK_MAX   ((1UL << 52) - 1)
diff --git a/lib/s390x/asm/uv.h b/lib/s390x/asm/uv.h
index b22cbaa87109..dc3e02dea1b4 100644
--- a/lib/s390x/asm/uv.h
+++ b/lib/s390x/asm/uv.h
@@ -9,8 +9,8 @@
  * This code is free software; you can red

[kvm-unit-tests PATCH v2 5/7] powerpc: unify header guards

[Cornelia Huck]

Only spapr.h needed a tweak.

Signed-off-by: Cornelia Huck 
---
 powerpc/spapr.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/powerpc/spapr.h b/powerpc/spapr.h
index b41aece07968..3a29598be44f 100644
--- a/powerpc/spapr.h
+++ b/powerpc/spapr.h
@@ -1,6 +1,6 @@
-#ifndef _ASMPOWERPC_SPAPR_H_
-#define _ASMPOWERPC_SPAPR_H_
+#ifndef POWERPC_SPAPR_H
+#define POWERPC_SPAPR_H
 
 #define SPAPR_KERNEL_LOAD_ADDR 0x40
 
-#endif /* _ASMPOWERPC_SPAPR_H_ */
+#endif /* POWERPC_SPAPR_H */
-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 4/7] arm: unify header guards

[Cornelia Huck]

The assembler.h files were the only ones not already following
the convention.

Signed-off-by: Cornelia Huck 
---
 lib/arm/asm/assembler.h   | 6 +++---
 lib/arm64/asm/assembler.h | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/arm/asm/assembler.h b/lib/arm/asm/assembler.h
index dfd3c51bf6ad..4200252dd14d 100644
--- a/lib/arm/asm/assembler.h
+++ b/lib/arm/asm/assembler.h
@@ -8,8 +8,8 @@
 #error "Only include this from assembly code"
 #endif
 
-#ifndef __ASM_ASSEMBLER_H
-#define __ASM_ASSEMBLER_H
+#ifndef _ASMARM_ASSEMBLER_H_
+#define _ASMARM_ASSEMBLER_H_
 
 /*
  * dcache_line_size - get the minimum D-cache line size from the CTR register
@@ -50,4 +50,4 @@
dsb \domain
.endm
 
-#endif /* __ASM_ASSEMBLER_H */
+#endif /* _ASMARM_ASSEMBLER_H_ */
diff --git a/lib/arm64/asm/assembler.h b/lib/arm64/asm/assembler.h
index 0a6ab9720bdd..a271e4ceefe6 100644
--- a/lib/arm64/asm/assembler.h
+++ b/lib/arm64/asm/assembler.h
@@ -12,8 +12,8 @@
 #error "Only include this from assembly code"
 #endif
 
-#ifndef __ASM_ASSEMBLER_H
-#define __ASM_ASSEMBLER_H
+#ifndef _ASMARM64_ASSEMBLER_H_
+#define _ASMARM64_ASSEMBLER_H_
 
 /*
  * raw_dcache_line_size - get the minimum D-cache line size on this CPU
@@ -51,4 +51,4 @@
dsb \domain
.endm
 
-#endif /* __ASM_ASSEMBLER_H */
+#endif /* _ASMARM64_ASSEMBLER_H_ */
-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 3/7] asm-generic: unify header guards

[Cornelia Huck]

Standardize header guards to _ASM_GENERIC_HEADER_H_.

Signed-off-by: Cornelia Huck 
---
 lib/asm-generic/atomic.h  | 4 ++--
 lib/asm-generic/barrier.h | 6 +++---
 lib/asm-generic/memory_areas.h| 4 ++--
 lib/asm-generic/pci-host-bridge.h | 4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/asm-generic/atomic.h b/lib/asm-generic/atomic.h
index 26b645a7cc18..b09ce95053e7 100644
--- a/lib/asm-generic/atomic.h
+++ b/lib/asm-generic/atomic.h
@@ -1,5 +1,5 @@
-#ifndef __ASM_GENERIC_ATOMIC_H__
-#define __ASM_GENERIC_ATOMIC_H__
+#ifndef _ASM_GENERIC_ATOMIC_H_
+#define _ASM_GENERIC_ATOMIC_H_
 
 /* From QEMU include/qemu/atomic.h */
 #define atomic_fetch_inc(ptr)  __sync_fetch_and_add(ptr, 1)
diff --git a/lib/asm-generic/barrier.h b/lib/asm-generic/barrier.h
index 6a990ff8d5a5..5499a5664d4d 100644
--- a/lib/asm-generic/barrier.h
+++ b/lib/asm-generic/barrier.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_BARRIER_H_
-#define _ASM_BARRIER_H_
+#ifndef _ASM_GENERIC_BARRIER_H_
+#define _ASM_GENERIC_BARRIER_H_
 /*
  * asm-generic/barrier.h
  *
@@ -32,4 +32,4 @@
 #define cpu_relax()asm volatile ("":::"memory")
 #endif
 
-#endif /* _ASM_BARRIER_H_ */
+#endif /* _ASM_GENERIC_BARRIER_H_ */
diff --git a/lib/asm-generic/memory_areas.h b/lib/asm-generic/memory_areas.h
index 3074afe23393..c86db255ecee 100644
--- a/lib/asm-generic/memory_areas.h
+++ b/lib/asm-generic/memory_areas.h
@@ -1,5 +1,5 @@
-#ifndef __ASM_GENERIC_MEMORY_AREAS_H__
-#define __ASM_GENERIC_MEMORY_AREAS_H__
+#ifndef _ASM_GENERIC_MEMORY_AREAS_H_
+#define _ASM_GENERIC_MEMORY_AREAS_H_
 
 #define AREA_NORMAL_PFN 0
 #define AREA_NORMAL_NUMBER 0
diff --git a/lib/asm-generic/pci-host-bridge.h 
b/lib/asm-generic/pci-host-bridge.h
index 9e91499b9446..174ff341dd0d 100644
--- a/lib/asm-generic/pci-host-bridge.h
+++ b/lib/asm-generic/pci-host-bridge.h
@@ -1,5 +1,5 @@
-#ifndef _ASM_PCI_HOST_BRIDGE_H_
-#define _ASM_PCI_HOST_BRIDGE_H_
+#ifndef _ASM_GENERIC_PCI_HOST_BRIDGE_H_
+#define _ASM_GENERIC_PCI_HOST_BRIDGE_H_
 /*
  * Copyright (C) 2016, Red Hat Inc, Alexander Gordeev 
  *
-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 2/7] lib: unify header guards

[Cornelia Huck]

Standardize header guards to _LIB_HEADER_H_.

Signed-off-by: Cornelia Huck 
---
 lib/alloc_page.h   | 4 ++--
 lib/libcflat.h | 4 ++--
 lib/list.h | 4 ++--
 lib/pci-edu.h  | 4 ++--
 lib/pci-host-generic.h | 4 ++--
 lib/setjmp.h   | 4 ++--
 lib/string.h   | 6 +++---
 lib/vmalloc.h  | 4 ++--
 8 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/alloc_page.h b/lib/alloc_page.h
index 1af1419d49b6..eed2ba06eeaf 100644
--- a/lib/alloc_page.h
+++ b/lib/alloc_page.h
@@ -5,8 +5,8 @@
  * with byte granularity.
  */
 
-#ifndef ALLOC_PAGE_H
-#define ALLOC_PAGE_H 1
+#ifndef _ALLOC_PAGE_H_
+#define _ALLOC_PAGE_H_
 
 #include 
 #include 
diff --git a/lib/libcflat.h b/lib/libcflat.h
index 460a1234ea6a..f40b431d1550 100644
--- a/lib/libcflat.h
+++ b/lib/libcflat.h
@@ -17,8 +17,8 @@
  * Authors: Hollis Blanchard 
  */
 
-#ifndef __LIBCFLAT_H
-#define __LIBCFLAT_H
+#ifndef _LIBCFLAT_H_
+#define _LIBCFLAT_H_
 
 #ifndef __ASSEMBLY__
 
diff --git a/lib/list.h b/lib/list.h
index 7f9717ef6258..ed3e52b40075 100644
--- a/lib/list.h
+++ b/lib/list.h
@@ -1,5 +1,5 @@
-#ifndef LIST_H
-#define LIST_H
+#ifndef _LIST_H_
+#define _LIST_H_
 
 #include 
 
diff --git a/lib/pci-edu.h b/lib/pci-edu.h
index 44b4ba168768..9db94aec0bc7 100644
--- a/lib/pci-edu.h
+++ b/lib/pci-edu.h
@@ -12,8 +12,8 @@
  * Edu device is a virtualized device in QEMU. Please refer to
  * docs/specs/edu.txt in QEMU repository for EDU device manual.
  */
-#ifndef __PCI_EDU_H__
-#define __PCI_EDU_H__
+#ifndef _PCI_EDU_H_
+#define _PCI_EDU_H_
 
 #include "pci.h"
 #include "asm/io.h"
diff --git a/lib/pci-host-generic.h b/lib/pci-host-generic.h
index 0ffe6380ec8f..3020ee22c837 100644
--- a/lib/pci-host-generic.h
+++ b/lib/pci-host-generic.h
@@ -1,5 +1,5 @@
-#ifndef PCI_HOST_GENERIC_H
-#define PCI_HOST_GENERIC_H
+#ifndef _PCI_HOST_GENERIC_H_
+#define _PCI_HOST_GENERIC_H_
 /*
  * PCI host bridge supporting structures and constants
  *
diff --git a/lib/setjmp.h b/lib/setjmp.h
index 2c56b4c68aaa..6afdf665681a 100644
--- a/lib/setjmp.h
+++ b/lib/setjmp.h
@@ -4,8 +4,8 @@
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU Library General Public License version 2.
  */
-#ifndef LIBCFLAT_SETJMP_H
-#define LIBCFLAT_SETJMP_H 1
+#ifndef _LIBCFLAT_SETJMP_H_
+#define _LIBCFLAT_SETJMP_H_
 
 typedef struct jmp_buf_tag {
long int regs[8];
diff --git a/lib/string.h b/lib/string.h
index e1febfed7fb2..b07763eaef10 100644
--- a/lib/string.h
+++ b/lib/string.h
@@ -4,8 +4,8 @@
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU Library General Public License version 2.
  */
-#ifndef __STRING_H
-#define __STRING_H
+#ifndef _STRING_H_
+#define _STRING_H_
 
 extern size_t strlen(const char *buf);
 extern size_t strnlen(const char *buf, size_t maxlen);
@@ -23,4 +23,4 @@ extern int memcmp(const void *s1, const void *s2, size_t n);
 extern void *memmove(void *dest, const void *src, size_t n);
 extern void *memchr(const void *s, int c, size_t n);
 
-#endif /* _STRING_H */
+#endif /* _STRING_H_ */
diff --git a/lib/vmalloc.h b/lib/vmalloc.h
index 8b158f591d75..346f94f198c5 100644
--- a/lib/vmalloc.h
+++ b/lib/vmalloc.h
@@ -1,5 +1,5 @@
-#ifndef VMALLOC_H
-#define VMALLOC_H 1
+#ifndef _VMALLOC_H_
+#define _VMALLOC_H_
 
 #include 
 
-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 1/7] README.md: add guideline for header guards format

[Cornelia Huck]

Signed-off-by: Cornelia Huck 
---
 README.md | 9 +
 1 file changed, 9 insertions(+)

diff --git a/README.md b/README.md
index 24d4bdaaee0d..687ff50d0af1 100644
--- a/README.md
+++ b/README.md
@@ -156,6 +156,15 @@ Exceptions:
 
   - While the kernel standard requires 80 columns, we allow up to 120.
 
+Header guards:
+
+Please try to adhere to adhere to the following patterns when adding
+"#ifndef <...> #define <...>" header guards:
+./lib: _HEADER_H_
+./lib/:  _ARCH_HEADER_H_
+./lib//asm:  _ASMARCH_HEADER_H_
+./:  ARCH_HEADER_H
+
 ## Patches
 
 Patches are welcome at the KVM mailing list .
-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[kvm-unit-tests PATCH v2 0/7] unify header guards

[Cornelia Huck]

This is an extension of "s390x: unify header guards" to the rest
of kvm-unit-tests. I tried to choose a pattern that minimizes the
changes; most of them are for s390x and x86.

v1->v2:
- change the patterns and document them
- change other architectures and architecture-independent code as well

Cornelia Huck (7):
  README.md: add guideline for header guards format
  lib: unify header guards
  asm-generic: unify header guards
  arm: unify header guards
  powerpc: unify header guards
  s390x: unify header guards
  x86: unify header guards

 README.md | 9 +
 lib/alloc_page.h  | 4 ++--
 lib/arm/asm/assembler.h   | 6 +++---
 lib/arm64/asm/assembler.h | 6 +++---
 lib/asm-generic/atomic.h  | 4 ++--
 lib/asm-generic/barrier.h | 6 +++---
 lib/asm-generic/memory_areas.h| 4 ++--
 lib/asm-generic/pci-host-bridge.h | 4 ++--
 lib/libcflat.h| 4 ++--
 lib/list.h| 4 ++--
 lib/pci-edu.h | 4 ++--
 lib/pci-host-generic.h| 4 ++--
 lib/s390x/asm/arch_def.h  | 4 ++--
 lib/s390x/asm/barrier.h   | 4 ++--
 lib/s390x/asm/cpacf.h | 6 +++---
 lib/s390x/asm/facility.h  | 4 ++--
 lib/s390x/asm/float.h | 4 ++--
 lib/s390x/asm/mem.h   | 4 ++--
 lib/s390x/asm/sigp.h  | 6 +++---
 lib/s390x/asm/spinlock.h  | 4 ++--
 lib/s390x/asm/time.h  | 4 ++--
 lib/s390x/asm/uv.h| 4 ++--
 lib/s390x/css.h   | 4 ++--
 lib/s390x/interrupt.h | 4 ++--
 lib/s390x/mmu.h   | 4 ++--
 lib/s390x/sclp.h  | 6 +++---
 lib/s390x/sie.h   | 6 +++---
 lib/s390x/smp.h   | 4 ++--
 lib/s390x/uv.h| 4 ++--
 lib/s390x/vm.h| 6 +++---
 lib/setjmp.h  | 4 ++--
 lib/string.h  | 6 +++---
 lib/vmalloc.h | 4 ++--
 lib/x86/acpi.h| 4 ++--
 lib/x86/apic-defs.h   | 6 +++---
 lib/x86/apic.h| 4 ++--
 lib/x86/asm/barrier.h | 4 ++--
 lib/x86/asm/debugreg.h| 6 +++---
 lib/x86/asm/io.h  | 4 ++--
 lib/x86/asm/memory_areas.h| 4 ++--
 lib/x86/asm/page.h| 4 ++--
 lib/x86/asm/pci.h | 4 ++--
 lib/x86/asm/spinlock.h| 4 ++--
 lib/x86/asm/stack.h   | 4 ++--
 lib/x86/atomic.h  | 4 ++--
 lib/x86/delay.h   | 4 ++--
 lib/x86/desc.h| 4 ++--
 lib/x86/fault_test.h  | 4 ++--
 lib/x86/fwcfg.h   | 4 ++--
 lib/x86/intel-iommu.h | 4 ++--
 lib/x86/isr.h | 4 ++--
 lib/x86/msr.h | 6 +++---
 lib/x86/processor.h   | 4 ++--
 lib/x86/smp.h | 4 ++--
 lib/x86/usermode.h| 4 ++--
 lib/x86/vm.h  | 4 ++--
 powerpc/spapr.h   | 6 +++---
 s390x/sthyi.h | 4 ++--
 x86/hyperv.h  | 4 ++--
 x86/ioram.h   | 4 ++--
 x86/kvmclock.h| 4 ++--
 x86/svm.h | 4 ++--
 x86/types.h   | 4 ++--
 x86/vmx.h | 4 ++--
 64 files changed, 148 insertions(+), 139 deletions(-)

-- 
2.31.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] memory: Skip dirty tracking for un-migratable memory regions

[Cornelia Huck]

On Mon, 16 Nov 2020 21:22:10 +0800
Zenghui Yu  wrote:

> It makes no sense to track dirty pages for those un-migratable memory
> regions (e.g., Memory BAR region of the VFIO PCI device) and doing so
> will potentially lead to some unpleasant issues during migration [1].
> 
> Skip dirty tracking for those regions by evaluating if the region is
> migratable before setting dirty_log_mask (DIRTY_MEMORY_MIGRATION).
> 
> [1] https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg03757.html
> 
> Signed-off-by: Zenghui Yu 
> ---
>  softmmu/memory.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/softmmu/memory.c b/softmmu/memory.c
> index 71951fe4dc..aa393f1bb0 100644
> --- a/softmmu/memory.c
> +++ b/softmmu/memory.c
> @@ -1806,7 +1806,10 @@ bool memory_region_is_ram_device(MemoryRegion *mr)
>  uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
>  {
>  uint8_t mask = mr->dirty_log_mask;
> -if (global_dirty_log && (mr->ram_block || memory_region_is_iommu(mr))) {
> +RAMBlock *rb = mr->ram_block;
> +
> +if (global_dirty_log && ((rb && qemu_ram_is_migratable(rb)) ||
> + memory_region_is_iommu(mr))) {
>      mask |= (1 << DIRTY_MEMORY_MIGRATION);
>  }
>  return mask;

Looks reasonable.

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters

[Cornelia Huck]

On Thu, 23 Apr 2020 11:01:43 +0800
Tianjia Zhang  wrote:

> On 2020/4/23 0:04, Cornelia Huck wrote:
> > On Wed, 22 Apr 2020 17:58:04 +0200
> > Christian Borntraeger  wrote:
> >   
> >> On 22.04.20 15:45, Cornelia Huck wrote:  
> >>> On Wed, 22 Apr 2020 20:58:04 +0800
> >>> Tianjia Zhang  wrote:
> >>>  
> >>>> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> >>>> structure. Earlier than historical reasons, many kvm-related function  
> >>>
> >>> s/Earlier than/For/ ?
> >>>  
> >>>> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same 
> >>>> time.
> >>>> This patch does a unified cleanup of these remaining redundant 
> >>>> parameters.
> >>>>
> >>>> Signed-off-by: Tianjia Zhang 
> >>>> ---
> >>>>   arch/s390/kvm/kvm-s390.c | 37 ++---
> >>>>   1 file changed, 22 insertions(+), 15 deletions(-)
> >>>>
> >>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> >>>> index e335a7e5ead7..d7bb2e7a07ff 100644
> >>>> --- a/arch/s390/kvm/kvm-s390.c
> >>>> +++ b/arch/s390/kvm/kvm-s390.c
> >>>> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> >>>>  return rc;
> >>>>   }
> >>>>   
> >>>> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run 
> >>>> *kvm_run)
> >>>> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
> >>>>   {
> >>>> +struct kvm_run *kvm_run = vcpu->run;
> >>>>  struct runtime_instr_cb *riccb;
> >>>>  struct gs_cb *gscb;
> >>>>   
> >>>> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, 
> >>>> struct kvm_run *kvm_run)
> >>>>  }
> >>>>  if (vcpu->arch.gs_enabled) {
> >>>>  current->thread.gs_cb = (struct gs_cb *)
> >>>> ->run->s.regs.gscb;
> >>>> +_run->s.regs.gscb;  
> >>>
> >>> Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
> >>> it. (It seems they amount to at least as much as the changes advertised
> >>> in the patch description.)
> >>>
> >>> Other opinions?  
> >>
> >> Agreed. It feels kind of random. Maybe just do the first line (move 
> >> kvm_run from the
> >> function parameter list into the variable declaration)? Not sure if this 
> >> is better.
> >>  
> > 
> > There's more in this patch that I cut... but I think just moving
> > kvm_run from the parameter list would be much less disruptive.
> >   
> 
> I think there are two kinds of code(`vcpu->run->` and `kvm_run->`), but 
> there will be more disruptive, not less.

I just fail to see the benefit; sure, kvm_run-> is convenient, but the
current code is just fine, and any rework should be balanced against
the cost (e.g. cluttering git annotate).

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters

[Cornelia Huck]

On Wed, 22 Apr 2020 17:58:04 +0200
Christian Borntraeger  wrote:

> On 22.04.20 15:45, Cornelia Huck wrote:
> > On Wed, 22 Apr 2020 20:58:04 +0800
> > Tianjia Zhang  wrote:
> >   
> >> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> >> structure. Earlier than historical reasons, many kvm-related function  
> > 
> > s/Earlier than/For/ ?
> >   
> >> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
> >> This patch does a unified cleanup of these remaining redundant parameters.
> >>
> >> Signed-off-by: Tianjia Zhang 
> >> ---
> >>  arch/s390/kvm/kvm-s390.c | 37 ++---
> >>  1 file changed, 22 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> >> index e335a7e5ead7..d7bb2e7a07ff 100644
> >> --- a/arch/s390/kvm/kvm-s390.c
> >> +++ b/arch/s390/kvm/kvm-s390.c
> >> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> >>return rc;
> >>  }
> >>  
> >> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
> >> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
> >>  {
> >> +  struct kvm_run *kvm_run = vcpu->run;
> >>struct runtime_instr_cb *riccb;
> >>struct gs_cb *gscb;
> >>  
> >> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, 
> >> struct kvm_run *kvm_run)
> >>}
> >>if (vcpu->arch.gs_enabled) {
> >>current->thread.gs_cb = (struct gs_cb *)
> >> -  >run->s.regs.gscb;
> >> +  _run->s.regs.gscb;  
> > 
> > Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
> > it. (It seems they amount to at least as much as the changes advertised
> > in the patch description.)
> > 
> > Other opinions?  
> 
> Agreed. It feels kind of random. Maybe just do the first line (move kvm_run 
> from the
> function parameter list into the variable declaration)? Not sure if this is 
> better.
> 

There's more in this patch that I cut... but I think just moving
kvm_run from the parameter list would be much less disruptive.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 1/7] KVM: s390: clean up redundant 'kvm_run' parameters

[Cornelia Huck]

On Wed, 22 Apr 2020 20:58:04 +0800
Tianjia Zhang  wrote:

> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. Earlier than historical reasons, many kvm-related function

s/Earlier than/For/ ?

> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
> This patch does a unified cleanup of these remaining redundant parameters.
> 
> Signed-off-by: Tianjia Zhang 
> ---
>  arch/s390/kvm/kvm-s390.c | 37 ++---
>  1 file changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index e335a7e5ead7..d7bb2e7a07ff 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -4176,8 +4176,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
>   return rc;
>  }
>  
> -static void sync_regs_fmt2(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
> +static void sync_regs_fmt2(struct kvm_vcpu *vcpu)
>  {
> + struct kvm_run *kvm_run = vcpu->run;
>   struct runtime_instr_cb *riccb;
>   struct gs_cb *gscb;
>  
> @@ -4235,7 +4236,7 @@ static void sync_regs_fmt2(struct kvm_vcpu *vcpu, 
> struct kvm_run *kvm_run)
>   }
>   if (vcpu->arch.gs_enabled) {
>   current->thread.gs_cb = (struct gs_cb *)
> - >run->s.regs.gscb;
> + _run->s.regs.gscb;

Not sure if these changes (vcpu->run-> => kvm_run->) are really worth
it. (It seems they amount to at least as much as the changes advertised
in the patch description.)

Other opinions?

>   restore_gs_cb(current->thread.gs_cb);
>   }
>   preempt_enable();

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function

[Cornelia Huck]

On Thu, 16 Apr 2020 16:45:33 +0800
Tianjia Zhang  wrote:

> On 2020/4/16 16:28, Marc Zyngier wrote:
> > On 2020-04-16 08:03, Vitaly Kuznetsov wrote:  
> >> Tianjia Zhang  writes:
> >>  
> >>> In earlier versions of kvm, 'kvm_run' is an independent structure
> >>> and is not included in the vcpu structure. At present, 'kvm_run'
> >>> is already included in the vcpu structure, so the parameter
> >>> 'kvm_run' is redundant.
> >>>
> >>> This patch simplify the function definition, removes the extra
> >>> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
> >>> if necessary.
> >>>
> >>> Signed-off-by: Tianjia Zhang 
> >>> ---
> >>>
> >>> v2 change:
> >>>   remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
> >>>
> >>>  arch/mips/kvm/mips.c   |  3 ++-
> >>>  arch/powerpc/kvm/powerpc.c |  3 ++-
> >>>  arch/s390/kvm/kvm-s390.c   |  3 ++-
> >>>  arch/x86/kvm/x86.c | 11 ++-
> >>>  include/linux/kvm_host.h   |  2 +-
> >>>  virt/kvm/arm/arm.c |  6 +++---
> >>>  virt/kvm/kvm_main.c    |  2 +-
> >>>  7 files changed, 17 insertions(+), 13 deletions(-)

> > Overall, there is a large set of cleanups to be done when both the vcpu 
> > and the run
> > structures are passed as parameters at the same time. Just grepping the 
> > tree for
> > kvm_run is pretty instructive.
> > 
> >      M.  
> 
> Sorry, it's my mistake, I only compiled the x86 platform, I will submit 
> patch again.

I think it's completely fine (and even preferable) to do cleanups like
that on top.

[FWIW, I compiled s390 here.]

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function

[Cornelia Huck]

On Thu, 16 Apr 2020 13:10:57 +0800
Tianjia Zhang  wrote:

> In earlier versions of kvm, 'kvm_run' is an independent structure
> and is not included in the vcpu structure. At present, 'kvm_run'
> is already included in the vcpu structure, so the parameter
> 'kvm_run' is redundant.
> 
> This patch simplify the function definition, removes the extra

s/simplify/simplifies/

> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure

s/extract/extracts/

> if necessary.
> 
> Signed-off-by: Tianjia Zhang 
> ---
> 
> v2 change:
>   remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
> 
>  arch/mips/kvm/mips.c   |  3 ++-
>  arch/powerpc/kvm/powerpc.c |  3 ++-
>  arch/s390/kvm/kvm-s390.c   |  3 ++-
>  arch/x86/kvm/x86.c | 11 ++-
>  include/linux/kvm_host.h   |  2 +-
>  virt/kvm/arm/arm.c |  6 +++---
>  virt/kvm/kvm_main.c|  2 +-
>  7 files changed, 17 insertions(+), 13 deletions(-)
> 

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2] kvm_host: unify VM_STAT and VCPU_STAT definitions in a single place

[Cornelia Huck]

On Tue, 14 Apr 2020 17:56:25 +0200
Emanuele Giuseppe Esposito  wrote:

> The macros VM_STAT and VCPU_STAT are redundantly implemented in multiple
> files, each used by a different architecure to initialize the debugfs
> entries for statistics. Since they all have the same purpose, they can be
> unified in a single common definition in include/linux/kvm_host.h
> 
> Signed-off-by: Emanuele Giuseppe Esposito 
> ---
>  arch/arm64/kvm/guest.c|  23 ++---
>  arch/mips/kvm/mips.c  |  61 ++--
>  arch/powerpc/kvm/book3s.c |  61 ++--
>  arch/powerpc/kvm/booke.c  |  41 
>  arch/s390/kvm/kvm-s390.c  | 203 +++---
>  arch/x86/kvm/x86.c|  80 +++
>  include/linux/kvm_host.h  |   5 +
>  7 files changed, 231 insertions(+), 243 deletions(-)

Adds a bit of churn, but the end result does look nicer. Looks sane,
but did not review in detail.

Acked-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 1/5] KVM: Pass kvm_init()'s opaque param to additional arch funcs

[Cornelia Huck]

On Wed, 29 Jan 2020 16:10:19 -0800
Sean Christopherson  wrote:

> Pass @opaque to kvm_arch_hardware_setup() and
> kvm_arch_check_processor_compat() to allow architecture specific code to
> reference @opaque without having to stash it away in a temporary global
> variable.  This will enable x86 to separate its vendor specific callback
> ops, which are passed via @opaque, into "init" and "runtime" ops without
> having to stash away the "init" ops.
> 
> No functional change intended.
> 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/mips/kvm/mips.c   |  4 ++--
>  arch/powerpc/kvm/powerpc.c |  4 ++--
>  arch/s390/kvm/kvm-s390.c   |  4 ++--
>  arch/x86/kvm/x86.c |  4 ++--
>  include/linux/kvm_host.h   |  4 ++--
>  virt/kvm/arm/arm.c |  4 ++--
>  virt/kvm/kvm_main.c| 18 ++
>  7 files changed, 26 insertions(+), 16 deletions(-)

> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index eb3709d55139..5ad252defa54 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4345,14 +4345,22 @@ struct kvm_vcpu * __percpu 
> *kvm_get_running_vcpus(void)
>  return _running_vcpu;
>  }
>  
> -static void check_processor_compat(void *rtn)
> +struct kvm_cpu_compat_check {
> + void *opaque;
> + int *ret;
> +};
> +
> +static void check_processor_compat(void *data)
>  {
> - *(int *)rtn = kvm_arch_check_processor_compat();
> + struct kvm_cpu_compat_check *c = data;
> +
> +     *c->ret = kvm_arch_check_processor_compat(c->opaque);
>  }

This function also looks better now :)

Reviewed-by: Cornelia Huck 
Tested-by: Cornelia Huck  #s390

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 35/45] KVM: s390: Manually invoke vcpu setup during kvm_arch_vcpu_create()

[Cornelia Huck]

On Fri, 20 Dec 2019 07:56:07 -0800
Sean Christopherson  wrote:

> On Fri, Dec 20, 2019 at 11:04:45AM +0100, Cornelia Huck wrote:
> > On Wed, 18 Dec 2019 13:55:20 -0800
> > Sean Christopherson  wrote:
> >   
> > > Rename kvm_arch_vcpu_setup() to kvm_s390_vcpu_setup() and manually call
> > > the new function during kvm_arch_vcpu_create().  Define an empty
> > > kvm_arch_vcpu_setup() as it's still required for compilation.  This
> > > is effectively a nop as kvm_arch_vcpu_create() and kvm_arch_vcpu_setup()
> > > are called back-to-back by common KVM code.  Obsoleting
> > > kvm_arch_vcpu_setup() paves the way for its removal.
> > > 
> > > Note, gmap_remove() is now called if setup fails, as s390 was previously
> > > freeing it via kvm_arch_vcpu_destroy(), which is called by common KVM
> > > code if kvm_arch_vcpu_setup() fails.  
> > 
> > Yes, this looks like the only thing that needs to be undone
> > (sca_add_vcpu() is done later in the process.)
> > 
> > Maybe mention that gmap_remove() is for ucontrol only? I was confused
> > for a moment :)  
> 
> Will do.
> 
> Would it also make sense to open code __kvm_ucontrol_vcpu_init() in a
> separate patch immediately preceding this change?  That'd make it a little
> more obvious why gmap_remove() is called, and it would eliminate the
> "uninit" verbiage in the label, e.g.:

I'm a bit undecided here; especially as I'm not sure if there are any
future plans with ucontrol. I'll leave that for Christian and Janosch
to decide.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 30/45] KVM: Move vcpu alloc and init invocation to common code

[Cornelia Huck]

On Fri, 20 Dec 2019 07:53:30 -0800
Sean Christopherson  wrote:

> On Fri, Dec 20, 2019 at 10:33:25AM +0100, Cornelia Huck wrote:
> > On Wed, 18 Dec 2019 13:55:15 -0800
> > Sean Christopherson  wrote:  
> > > +int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
> > >  {
> > > - struct kvm_vcpu *vcpu;
> > >   struct sie_page *sie_page;
> > >   int rc;
> > >  
> > > - rc = -ENOMEM;
> > > -
> > > - vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
> > > - if (!vcpu)
> > > - goto out;
> > > -
> > > - rc = kvm_vcpu_init(vcpu, kvm, id);
> > > - if (rc)
> > > - goto out_free_cpu;
> > > -
> > > - rc = -ENOMEM;
> > > -
> > >   BUILD_BUG_ON(sizeof(struct sie_page) != 4096);
> > >   sie_page = (struct sie_page *) get_zeroed_page(GFP_KERNEL);
> > >   if (!sie_page)
> > > - goto out_uninit_vcpu;
> > > + return -ENOMEM;
> > >  
> > >   vcpu->arch.sie_block = _page->sie_block;
> > >   vcpu->arch.sie_block->itdba = (unsigned long) _page->itdb;
> > > @@ -3087,15 +3070,11 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm 
> > > *kvm,
> > >vcpu->arch.sie_block);
> > >   trace_kvm_s390_create_vcpu(id, vcpu, vcpu->arch.sie_block);
> > >  
> > > - return vcpu;
> > > + return 0;
> > > +
> > >  out_free_sie_block:
> > >   free_page((unsigned long)(vcpu->arch.sie_block));
> > > -out_uninit_vcpu:
> > > - kvm_vcpu_uninit(vcpu);
> > > -out_free_cpu:
> > > - kmem_cache_free(kvm_vcpu_cache, vcpu);
> > > -out:
> > > - return ERR_PTR(rc);
> > > + return rc;  
> > 
> > This is getting a bit hard to follow across the patches, but I think rc
> > is now only set for ucontrol guests. So this looks correct right now,
> > but feels a bit brittle... should we maybe init rc to 0 and always
> > return rc instead?  
> 
> Yes, but only for a few patches until kvm_s390_vcpu_setup() is introduced,
> at which point @rc is unconditionally set at the end.

Indeed; so feel free to leave this as-is.

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 45/45] KVM: Move vcpu->run page allocation out of kvm_vcpu_init()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:30 -0800
Sean Christopherson  wrote:

> Open code the allocation and freeing of the vcpu->run page in
> kvm_vm_ioctl_create_vcpu() and kvm_vcpu_destroy() respectively.  Doing
> so allows kvm_vcpu_init() to be a pure init function and eliminates
> kvm_vcpu_uninit() entirely.
> 
> Signed-off-by: Sean Christopherson 
> ---
>  virt/kvm/kvm_main.c | 34 +-
>  1 file changed, 13 insertions(+), 21 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 44/45] KVM: Move putting of vcpu->pid to kvm_vcpu_destroy()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:29 -0800
Sean Christopherson  wrote:

> Move the putting of vcpu->pid to kvm_vcpu_destroy().  vcpu->pid is
> guaranteed to be NULL when kvm_vcpu_uninit() is called in the error path
> of kvm_vm_ioctl_create_vcpu(), e.g. it is explicitly nullified by
> kvm_vcpu_init() and is only changed by KVM_RUN.
> 
> No functional change intended.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  virt/kvm/kvm_main.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 43/45] KVM: Drop kvm_arch_vcpu_init() and kvm_arch_vcpu_uninit()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:28 -0800
Sean Christopherson  wrote:

> Remove kvm_arch_vcpu_init() and kvm_arch_vcpu_uninit() now that all
> arch specific implementations are nops.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/arm/include/asm/kvm_host.h   |  1 -
>  arch/arm64/include/asm/kvm_host.h |  1 -
>  arch/arm64/kvm/reset.c|  5 -
>  arch/mips/kvm/mips.c  | 10 --
>  arch/powerpc/kvm/powerpc.c| 10 --
>  arch/s390/include/asm/kvm_host.h  |  1 -
>  arch/s390/kvm/kvm-s390.c  |  5 -
>  arch/x86/kvm/x86.c| 10 --
>  include/linux/kvm_host.h  |  3 ---
>  virt/kvm/arm/arm.c|  5 -
>  virt/kvm/kvm_main.c   | 16 ++--
>  11 files changed, 2 insertions(+), 65 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 37/45] KVM: Drop kvm_arch_vcpu_setup()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:22 -0800
Sean Christopherson  wrote:

> Remove kvm_arch_vcpu_setup() now that all arch specific implementations
> are nops.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/arm/kvm/guest.c  | 5 -
>  arch/arm64/kvm/guest.c| 5 -
>  arch/mips/kvm/mips.c  | 5 -
>  arch/powerpc/kvm/book3s.c | 5 -
>  arch/powerpc/kvm/booke.c  | 5 -
>  arch/s390/kvm/kvm-s390.c  | 5 -
>  arch/x86/kvm/x86.c| 5 -
>  include/linux/kvm_host.h  | 1 -
>  virt/kvm/kvm_main.c   | 5 -
>  9 files changed, 41 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 35/45] KVM: s390: Manually invoke vcpu setup during kvm_arch_vcpu_create()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:20 -0800
Sean Christopherson  wrote:

> Rename kvm_arch_vcpu_setup() to kvm_s390_vcpu_setup() and manually call
> the new function during kvm_arch_vcpu_create().  Define an empty
> kvm_arch_vcpu_setup() as it's still required for compilation.  This
> is effectively a nop as kvm_arch_vcpu_create() and kvm_arch_vcpu_setup()
> are called back-to-back by common KVM code.  Obsoleting
> kvm_arch_vcpu_setup() paves the way for its removal.
> 
> Note, gmap_remove() is now called if setup fails, as s390 was previously
> freeing it via kvm_arch_vcpu_destroy(), which is called by common KVM
> code if kvm_arch_vcpu_setup() fails.

Yes, this looks like the only thing that needs to be undone
(sca_add_vcpu() is done later in the process.)

Maybe mention that gmap_remove() is for ucontrol only? I was confused
for a moment :)


> 
> No functional change intended.
> 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/s390/kvm/kvm-s390.c | 11 +++
>  1 file changed, 11 insertions(+)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 32/45] KVM: Move initialization of preempt notifier to kvm_vcpu_init()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:17 -0800
Sean Christopherson  wrote:

> Initialize the preempt notifier immediately in kvm_vcpu_init() to pave
> the way for removing kvm_arch_vcpu_setup(), i.e. to allow arch specific
> code to call vcpu_load() during kvm_arch_vcpu_create().
> 
> Back when preemption support was added, the location of the call to init
> the preempt notifier was perfectly sane.  The overall vCPU creation flow
> featured a single arch specific hook and the preempt notifer was used
> immediately after its initialization (by vcpu_load()).  E.g.:
> 
> vcpu = kvm_arch_ops->vcpu_create(kvm, n);
> if (IS_ERR(vcpu))
> return PTR_ERR(vcpu);
> 
> preempt_notifier_init(>preempt_notifier, _preempt_ops);
> 
> vcpu_load(vcpu);
> r = kvm_mmu_setup(vcpu);
> vcpu_put(vcpu);
> if (r < 0)
> goto free_vcpu;
> 
> Today, the call to preempt_notifier_init() is sandwiched between two
> arch specific calls, kvm_arch_vcpu_create() and kvm_arch_vcpu_setup(),
> which needlessly forces x86 (and possibly others?) to split its vCPU
> creation flow.  Init the preempt notifier prior to any arch specific
> call so that each arch can independently decide how best to organize
> its creation flow.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  virt/kvm/kvm_main.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 31/45] KVM: Unexport kvm_vcpu_cache and kvm_vcpu_{un}init()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:16 -0800
Sean Christopherson  wrote:

> Unexport kvm_vcpu_cache and kvm_vcpu_{un}init() and make them static
> now that they are referenced only in kvm_main.c.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  include/linux/kvm_host.h | 4 
>  virt/kvm/kvm_main.c  | 9 +++--
>  2 files changed, 3 insertions(+), 10 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 30/45] KVM: Move vcpu alloc and init invocation to common code

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:15 -0800
Sean Christopherson  wrote:

> Now that all architectures tightly couple vcpu allocation/free with the
> mandatory calls to kvm_{un}init_vcpu(), move the sequences verbatim to
> common KVM code.
> 
> Move both allocation and initialization in a single patch to eliminate
> thrash in arch specific code.  The bisection benefits of moving the two
> pieces in separate patches is marginal at best, whereas the odds of
> introducing a transient arch specific bug are non-zero.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/mips/kvm/mips.c   | 33 ++---
>  arch/powerpc/kvm/powerpc.c | 27 ---
>  arch/s390/kvm/kvm-s390.c   | 31 +--
>  arch/x86/kvm/x86.c | 28 ++--
>  include/linux/kvm_host.h   |  2 +-
>  virt/kvm/arm/arm.c | 29 ++---
>  virt/kvm/kvm_main.c| 21 ++---
>  7 files changed, 38 insertions(+), 133 deletions(-)

(...)

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 8543d338a06a..2ed76584ebd9 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2530,9 +2530,6 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>   if (vcpu->kvm->arch.use_cmma)
>   kvm_s390_vcpu_unsetup_cmma(vcpu);
>   free_page((unsigned long)(vcpu->arch.sie_block));
> -
> - kvm_vcpu_uninit(vcpu);
> - kmem_cache_free(kvm_vcpu_cache, vcpu);
>  }
>  
>  static void kvm_free_vcpus(struct kvm *kvm)
> @@ -3014,29 +3011,15 @@ int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned 
> int id)
>   return 0;
>  }
>  
> -struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
> -   unsigned int id)
> +int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
>  {
> - struct kvm_vcpu *vcpu;
>   struct sie_page *sie_page;
>   int rc;
>  
> - rc = -ENOMEM;
> -
> - vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
> - if (!vcpu)
> - goto out;
> -
> - rc = kvm_vcpu_init(vcpu, kvm, id);
> - if (rc)
> - goto out_free_cpu;
> -
> - rc = -ENOMEM;
> -
>   BUILD_BUG_ON(sizeof(struct sie_page) != 4096);
>   sie_page = (struct sie_page *) get_zeroed_page(GFP_KERNEL);
>   if (!sie_page)
> - goto out_uninit_vcpu;
> + return -ENOMEM;
>  
>   vcpu->arch.sie_block = _page->sie_block;
>   vcpu->arch.sie_block->itdba = (unsigned long) _page->itdb;
> @@ -3087,15 +3070,11 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
>vcpu->arch.sie_block);
>   trace_kvm_s390_create_vcpu(id, vcpu, vcpu->arch.sie_block);
>  
> - return vcpu;
> + return 0;
> +
>  out_free_sie_block:
>   free_page((unsigned long)(vcpu->arch.sie_block));
> -out_uninit_vcpu:
> - kvm_vcpu_uninit(vcpu);
> -out_free_cpu:
> - kmem_cache_free(kvm_vcpu_cache, vcpu);
> -out:
> - return ERR_PTR(rc);
> + return rc;

This is getting a bit hard to follow across the patches, but I think rc
is now only set for ucontrol guests. So this looks correct right now,
but feels a bit brittle... should we maybe init rc to 0 and always
return rc instead?

>  }
>  
>  int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)

Otherwise, looks good.

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 29/45] KVM: Introduce kvm_vcpu_destroy()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:14 -0800
Sean Christopherson  wrote:

> Add kvm_vcpu_destroy() and wire up all architectures to call the common
> function instead of their arch specific implementation.  The common
> destruction function will be used by future patches to move allocation
> and initialization of vCPUs to common KVM code, i.e. to free resources
> that are allocated by arch agnostic code.
> 
> No functional change intended.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/mips/kvm/mips.c   | 2 +-
>  arch/powerpc/kvm/powerpc.c | 2 +-
>  arch/s390/kvm/kvm-s390.c   | 2 +-
>  arch/x86/kvm/x86.c | 2 +-
>  include/linux/kvm_host.h   | 1 +
>  virt/kvm/arm/arm.c | 2 +-
>  virt/kvm/kvm_main.c| 6 ++
>  7 files changed, 12 insertions(+), 5 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 26/45] KVM: s390: Invoke kvm_vcpu_init() before allocating sie_page

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:11 -0800
Sean Christopherson  wrote:

> Now that s390's implementation of kvm_arch_vcpu_init() is empty, move
> the call to kvm_vcpu_init() above the allocation of the sie_page.  This
> paves the way for moving vcpu allocation and initialization into common
> KVM code without any associated functional change.
> 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/s390/kvm/kvm-s390.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)

Seems to be fine.

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 25/45] KVM: s390: Move guts of kvm_arch_vcpu_init() into kvm_arch_vcpu_create()

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:10 -0800
Sean Christopherson  wrote:

> Move all of kvm_arch_vcpu_init(), which is invoked at the very end of
> kvm_vcpu_init(), into kvm_arch_vcpu_create() in preparation of moving
> the call to kvm_vcpu_init().  Moving kvm_vcpu_init() is itself a
> preparatory step for moving allocation and initialization to common KVM
> code.
> 
> No functional change inteded.
> 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/s390/kvm/kvm-s390.c | 62 ++--
>  1 file changed, 34 insertions(+), 28 deletions(-)

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 24/45] KVM: Add kvm_arch_vcpu_precreate() to handle pre-allocation issues

[Cornelia Huck]

On Wed, 18 Dec 2019 13:55:09 -0800
Sean Christopherson  wrote:

> Add a pre-allocation arch hook to handle checks that are currently done
> by arch specific code prior to allocating the vCPU object.  This paves
> the way for moving the allocation to common KVM code.
> 
> Acked-by: Christoffer Dall 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/mips/kvm/mips.c   |  5 +
>  arch/powerpc/kvm/powerpc.c |  5 +
>  arch/s390/kvm/kvm-s390.c   | 12 
>  arch/x86/kvm/x86.c | 14 +-
>  include/linux/kvm_host.h   |  1 +
>  virt/kvm/arm/arm.c | 21 +++--
>  virt/kvm/kvm_main.c|  4 
>  7 files changed, 43 insertions(+), 19 deletions(-)
> 

(...)

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index d9e6bf3d54f0..57c6838dff37 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3035,15 +3035,19 @@ int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
>   return rc;
>  }
>  
> +int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
> +{
> + if (!kvm_is_ucontrol(kvm) && !sca_can_add_vcpu(kvm, id))
> + return -EINVAL;
> + return 0;
> +}
> +
>  struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
> unsigned int id)
>  {
>   struct kvm_vcpu *vcpu;
>   struct sie_page *sie_page;
> - int rc = -EINVAL;
> -
> - if (!kvm_is_ucontrol(kvm) && !sca_can_add_vcpu(kvm, id))
> - goto out;
> + int rc;

You might want to make this

int rc = -ENOMEM;

instead.

>  
>   rc = -ENOMEM;
>  

(...)

Regardless,

Reviewed-by: Cornelia Huck 

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: Directly return result from kvm_arch_check_processor_compat()

[Cornelia Huck]

On Fri, 19 Apr 2019 22:18:17 -0700
Sean Christopherson  wrote:

> Add a wrapper to invoke kvm_arch_check_processor_compat() so that the
> boilerplate ugliness of checking virtualization support on all CPUs is
> hidden from the arch specific code.  x86's implementation in particular
> is quite heinous, as it unnecessarily propagates the out-param pattern
> into kvm_x86_ops.
> 
> While the x86 specific issue could be resolved solely by changing
> kvm_x86_ops, make the change for all architectures as returning a value
> directly is prettier and technically more robust, e.g. s390 doesn't set
> the out param, which could lead to subtle breakage in the (highly
> unlikely) scenario where the out-param was not pre-initialized by the
> caller.
> 
> Opportunistically annotate svm_check_processor_compat() with __init.
> 
> Signed-off-by: Sean Christopherson 
> ---
> 
> Tested on VMX only.
> 
>  arch/mips/kvm/mips.c | 4 ++--
>  arch/powerpc/kvm/powerpc.c   | 4 ++--
>  arch/s390/include/asm/kvm_host.h | 1 -
>  arch/s390/kvm/kvm-s390.c | 5 +
>  arch/x86/include/asm/kvm_host.h  | 2 +-
>  arch/x86/kvm/svm.c   | 4 ++--
>  arch/x86/kvm/vmx/vmx.c   | 8 
>  arch/x86/kvm/x86.c   | 4 ++--
>  include/linux/kvm_host.h | 2 +-
>  virt/kvm/arm/arm.c   | 4 ++--
>  virt/kvm/kvm_main.c  | 9 ++---
>  11 files changed, 27 insertions(+), 20 deletions(-)

Yes, this does look nicer.

Reviewed-by: Cornelia Huck 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v2 01/27] KVM: Call kvm_arch_memslots_updated() before updating memslots

[Cornelia Huck]

On Tue,  5 Feb 2019 12:54:17 -0800
Sean Christopherson  wrote:

> kvm_arch_memslots_updated() is at this point in time an x86-specific
> hook for handling MMIO generation wraparound.  x86 stashes 19 bits of
> the memslots generation number in its MMIO sptes in order to avoid
> full page fault walks for repeat faults on emulated MMIO addresses.
> Because only 19 bits are used, wrapping the MMIO generation number is
> possible, if unlikely.  kvm_arch_memslots_updated() alerts x86 that
> the generation has changed so that it can invalidate all MMIO sptes in
> case the effective MMIO generation has wrapped so as to avoid using a
> stale spte, e.g. a (very) old spte that was created with generation==0.
> 
> Given that the purpose of kvm_arch_memslots_updated() is to prevent
> consuming stale entries, it needs to be called before the new generation
> is propagated to memslots.  Invalidating the MMIO sptes after updating
> memslots means that there is a window where a vCPU could dereference
> the new memslots generation, e.g. 0, and incorrectly reuse an old MMIO
> spte that was created with (pre-wrap) generation==0.
> 
> Fixes: e59dbe09f8e6 ("KVM: Introduce kvm_arch_memslots_updated()")
> Cc: 
> Signed-off-by: Sean Christopherson 
> ---
>  arch/mips/include/asm/kvm_host.h| 2 +-
>  arch/powerpc/include/asm/kvm_host.h | 2 +-
>  arch/s390/include/asm/kvm_host.h| 2 +-
>  arch/x86/include/asm/kvm_host.h | 2 +-
>  arch/x86/kvm/mmu.c  | 4 ++--
>  arch/x86/kvm/x86.c  | 4 ++--
>  include/linux/kvm_host.h| 2 +-
>  virt/kvm/arm/mmu.c  | 2 +-
>  virt/kvm/kvm_main.c | 7 +--
>  9 files changed, 15 insertions(+), 12 deletions(-)

Not an x86 person, but I think that makes sense.

Reviewed-by: Cornelia Huck 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] kvm: Change return type to vm_fault_t

[Cornelia Huck]

On Thu, 19 Apr 2018 00:49:58 +0530
Souptick Joarder <jrdr.li...@gmail.com> wrote:

> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
> 
> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
> 
> Signed-off-by: Souptick Joarder <jrdr.li...@gmail.com>
> Reviewed-by: Matthew Wilcox <mawil...@microsoft.com>
> ---
>  arch/mips/kvm/mips.c   | 2 +-
>  arch/powerpc/kvm/powerpc.c | 2 +-
>  arch/s390/kvm/kvm-s390.c   | 2 +-
>  arch/x86/kvm/x86.c | 2 +-
>  include/linux/kvm_host.h   | 2 +-
>  virt/kvm/arm/arm.c | 2 +-
>  virt/kvm/kvm_main.c    | 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 14/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:36 +0100
Christoffer Dall  wrote:

> From: Christoffer Dall 
> 
> Move the calls to vcpu_load() and vcpu_put() in to the architecture
> specific implementations of kvm_arch_vcpu_ioctl() which dispatches
> further architecture-specific ioctls on to other functions.
> 
> Some architectures support asynchronous vcpu ioctls which cannot call
> vcpu_load() or take the vcpu->mutex, because that would prevent
> concurrent execution with a running VCPU, which is the intended purpose
> of these ioctls, for example because they inject interrupts.
> 
> We repeat the separate checks for these specifics in the architecture
> code for MIPS, S390 and PPC, and avoid taking the vcpu->mutex and
> calling vcpu_load for these ioctls.
> 
> Signed-off-by: Christoffer Dall 
> ---
>  arch/mips/kvm/mips.c   | 49 +++
>  arch/powerpc/kvm/powerpc.c | 13 ++-
>  arch/s390/kvm/kvm-s390.c   | 19 ---
>  arch/x86/kvm/x86.c | 22 +-
>  virt/kvm/arm/arm.c | 58 
> --
>  virt/kvm/kvm_main.c|  2 --
>  6 files changed, 103 insertions(+), 60 deletions(-)
> 
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index 3a898712d6cd..4a039341dc29 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -913,56 +913,65 @@ long kvm_arch_vcpu_ioctl(struct file *filp, unsigned 
> int ioctl,
>   void __user *argp = (void __user *)arg;
>   long r;
>  
> + if (ioctl == KVM_INTERRUPT) {

I would add a comment here that this ioctl is async to vcpu execution,
so it is understandable why you skip the vcpu_load().

[As an aside, it is nice that this is now more obvious when looking at
the architectures' handlers.]

> + struct kvm_mips_interrupt irq;
> +
> + if (copy_from_user(, argp, sizeof(irq)))
> + return -EFAULT;
> + kvm_debug("[%d] %s: irq: %d\n", vcpu->vcpu_id, __func__,
> +   irq.irq);
> +
> + return kvm_vcpu_ioctl_interrupt(vcpu, );
> + }
> +
> + vcpu_load(vcpu);
> +
>   switch (ioctl) {

(...)

> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index c06bc9552438..6b5dd3a25fe8 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1617,16 +1617,16 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   void __user *argp = (void __user *)arg;
>   long r;
>  
> - switch (ioctl) {
> - case KVM_INTERRUPT: {
> + if (ioctl == KVM_INTERRUPT) {

Same here.

>   struct kvm_interrupt irq;
> - r = -EFAULT;
>   if (copy_from_user(, argp, sizeof(irq)))
> - goto out;
> - r = kvm_vcpu_ioctl_interrupt(vcpu, );
> - goto out;
> + return -EFAULT;
> + return kvm_vcpu_ioctl_interrupt(vcpu, );
>   }
>  
> + vcpu_load(vcpu);
> +
> + switch (ioctl) {
>   case KVM_ENABLE_CAP:
>   {
>   struct kvm_enable_cap cap;
> @@ -1666,6 +1666,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   }
>  
>  out:
> + vcpu_put(vcpu);
>   return r;
>  }
>  
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 43278f334ce3..cd067b63d77f 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3743,24 +3743,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   case KVM_S390_IRQ: {
>   struct kvm_s390_irq s390irq;
>  
> - r = -EFAULT;
>   if (copy_from_user(, argp, sizeof(s390irq)))
> - break;
> - r = kvm_s390_inject_vcpu(vcpu, );
> - break;
> + return -EFAULT;
> + return kvm_s390_inject_vcpu(vcpu, );
>   }
>   case KVM_S390_INTERRUPT: {
>   struct kvm_s390_interrupt s390int;
>   struct kvm_s390_irq s390irq;
>  
> - r = -EFAULT;
>   if (copy_from_user(, argp, sizeof(s390int)))
> - break;
> + return -EFAULT;
>   if (s390int_to_s390irq(, ))
>   return -EINVAL;
> - r = kvm_s390_inject_vcpu(vcpu, );
> - break;
> + return kvm_s390_inject_vcpu(vcpu, );
>   }
> + }

I find the special casing with the immediate return a bit ugly. Maybe
introduce a helper async_vcpu_ioctl() or so that sets -ENOIOCTLCMD in
its default case and return here if ret != -ENOIOCTLCMD? Christian,
what do you think?

> +
> + vcpu_load(vcpu);
> +
> + switch (ioctl) {
>   case KVM_S390_STORE_STATUS:
>   idx = srcu_read_lock(>kvm->srcu);
>   r = kvm_s390_vcpu_store_status(vcpu, arg);
> @@ -3883,6 +3884,8 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   default:
>   r = 

Re: [PATCH v3 13/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_fpu

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:35 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_fpu().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/s390/kvm/kvm-s390.c | 15 ---
>  arch/x86/kvm/x86.c   |  8 ++--
>  virt/kvm/kvm_main.c  |  2 --
>  3 files changed, 18 insertions(+), 7 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 12/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_fpu

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:34 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_fpu().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/s390/kvm/kvm-s390.c | 4 
>  arch/x86/kvm/x86.c   | 7 +--
>  virt/kvm/kvm_main.c  | 2 --
>  3 files changed, 9 insertions(+), 4 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 11/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_guest_debug

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:33 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_guest_debug().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/arm64/kvm/guest.c| 15 ---
>  arch/powerpc/kvm/book3s.c |  2 ++
>  arch/powerpc/kvm/booke.c  | 19 +--
>  arch/s390/kvm/kvm-s390.c  | 16 
>  arch/x86/kvm/x86.c|  4 +++-
>  virt/kvm/kvm_main.c   |  2 --
>  6 files changed, 42 insertions(+), 16 deletions(-)
> 

> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1b491b89cd43..7cb0e2677e60 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -2018,12 +2018,15 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct 
> kvm_vcpu *vcpu,
>  {
>   struct debug_reg *dbg_reg;
>   int n, b = 0, w = 0;
> + int ret = 0;
> +
> + vcpu_load(vcpu);
>  
>   if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
>   vcpu->arch.dbg_reg.dbcr0 = 0;
>   vcpu->guest_debug = 0;
>   kvm_guest_protect_msr(vcpu, MSR_DE, false);
> - return 0;
> + goto out;
>   }
>  
>   kvm_guest_protect_msr(vcpu, MSR_DE, true);
> @@ -2055,8 +2058,9 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu 
> *vcpu,
>  #endif
>  
>   if (!(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP))
> - return 0;
> + goto out;
>  
> + ret = -EINVAL;
>   for (n = 0; n < (KVMPPC_BOOKE_IAC_NUM + KVMPPC_BOOKE_DAC_NUM); n++) {
>   uint64_t addr = dbg->arch.bp[n].addr;
>   uint32_t type = dbg->arch.bp[n].type;
> @@ -2067,21 +2071,24 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct 
> kvm_vcpu *vcpu,
>   if (type & ~(KVMPPC_DEBUG_WATCH_READ |
>KVMPPC_DEBUG_WATCH_WRITE |
>KVMPPC_DEBUG_BREAKPOINT))
> - return -EINVAL;
> + goto out;
>  
>   if (type & KVMPPC_DEBUG_BREAKPOINT) {
>   /* Setting H/W breakpoint */
>   if (kvmppc_booke_add_breakpoint(dbg_reg, addr, b++))
> - return -EINVAL;
> + goto out;
>   } else {
>   /* Setting H/W watchpoint */
>   if (kvmppc_booke_add_watchpoint(dbg_reg, addr,
>   type, w++))
> - return -EINVAL;
> + goto out;
>   }
>   }
>  
> - return 0;
> + ret = 0;

I would probably set the -EINVAL in the individual branches (so it is
clear that something is wrong, and it is not just a benign exit as in
the cases above), but your code is correct as well. Let the powerpc
folks decide.

> +out:
> + vcpu_put(vcpu);
> + return ret;
>  }
>  
>  void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu)

In any case,

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 10/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_translate

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:32 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_translate().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/powerpc/kvm/booke.c | 2 ++
>  arch/x86/kvm/x86.c   | 3 +++
>  virt/kvm/kvm_main.c  | 2 --
>  3 files changed, 5 insertions(+), 2 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 09/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_mpstate

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:31 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_mpstate().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/s390/kvm/kvm-s390.c |  3 +++
>  arch/x86/kvm/x86.c   | 14 +++---
>  virt/kvm/arm/arm.c   |  9 +++--
>  virt/kvm/kvm_main.c  |  2 --
>  4 files changed, 21 insertions(+), 7 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 08/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_mpstate

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:30 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_mpstate().
> 
> Reviewed-by: David Hildenbrand <da...@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/s390/kvm/kvm-s390.c | 11 +--
>  arch/x86/kvm/x86.c   |  3 +++
>  virt/kvm/arm/arm.c   |  3 +++
>  virt/kvm/kvm_main.c  |  2 --
>  4 files changed, 15 insertions(+), 4 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 07/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:29 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_sregs().
> 
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/powerpc/kvm/book3s.c |  8 +++-
>  arch/powerpc/kvm/booke.c  | 15 +++
>  arch/s390/kvm/kvm-s390.c  |  4 
>  arch/x86/kvm/x86.c| 13 ++---
>  virt/kvm/kvm_main.c   |  2 --
>  5 files changed, 32 insertions(+), 10 deletions(-)

With David's suggestions included:

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 03/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_run

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:25 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_run().
> 
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/mips/kvm/mips.c   |  3 +++
>  arch/powerpc/kvm/powerpc.c |  6 +-
>  arch/s390/kvm/kvm-s390.c   | 10 --
>  arch/x86/kvm/x86.c |  3 +++
>  virt/kvm/arm/arm.c | 15 +++
>  virt/kvm/kvm_main.c|  2 --
>  6 files changed, 30 insertions(+), 9 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 05/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_regs

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:27 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_regs().
> 
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/mips/kvm/mips.c  | 3 +++
>  arch/powerpc/kvm/book3s.c | 3 +++
>  arch/powerpc/kvm/booke.c  | 3 +++
>  arch/s390/kvm/kvm-s390.c  | 2 ++
>  arch/x86/kvm/x86.c| 3 +++
>  virt/kvm/kvm_main.c   | 2 --
>  6 files changed, 14 insertions(+), 2 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 04/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_regs

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:26 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_regs().
> 
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/mips/kvm/mips.c  | 3 +++
>  arch/powerpc/kvm/book3s.c | 3 +++
>  arch/powerpc/kvm/booke.c  | 3 +++
>  arch/s390/kvm/kvm-s390.c  | 2 ++
>  arch/x86/kvm/x86.c| 3 +++
>  virt/kvm/kvm_main.c   | 2 --
>  6 files changed, 14 insertions(+), 2 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v3 01/16] KVM: Take vcpu->mutex outside vcpu_load

[Cornelia Huck]

On Mon,  4 Dec 2017 21:35:23 +0100
Christoffer Dall <cd...@kernel.org> wrote:

> From: Christoffer Dall <christoffer.d...@linaro.org>
> 
> As we're about to call vcpu_load() from architecture-specific
> implementations of the KVM vcpu ioctls, but yet we access data
> structures protected by the vcpu->mutex in the generic code, factor
> this logic out from vcpu_load().
> 
> x86 is the only architecture which calls vcpu_load() outside of the main
> vcpu ioctl function, and these calls will no longer take the vcpu mutex
> following this patch.  However, with the exception of
> kvm_arch_vcpu_postcreate (see below), the callers are either in the
> creation or destruction path of the VCPU, which means there cannot be
> any concurrent access to the data structure, because the file descriptor
> is not yet accessible, or is already gone.
> 
> kvm_arch_vcpu_postcreate makes the newly created vcpu potentially
> accessible by other in-kernel threads through the kvm->vcpus array, and
> we therefore take the vcpu mutex in this case directly.
> 
> Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org>
> ---
>  arch/x86/kvm/vmx.c   |  4 +---
>  arch/x86/kvm/x86.c   | 20 +++-
>  include/linux/kvm_host.h |  2 +-
>  virt/kvm/kvm_main.c  | 17 ++---
>  4 files changed, 15 insertions(+), 28 deletions(-)

Reviewed-by: Cornelia Huck <coh...@redhat.com>
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 2/2] KVM: Make KVM_CAP_IRQFD dependent on KVM_CAP_IRQCHIP

[Cornelia Huck]

On Mon, 30 Nov 2015 15:41:20 +0300
Pavel Fedin  wrote:

>  Hello!
> 
> > >  Thank you for the note, i didn't know about irqchip-specific capability 
> > > codes. There's the
> > > same issue with PowerPC, now i
> > > understand why there's no KVM_CAP_IRQCHIP for them. Because they have 
> > > KVM_CAP_IRQ_MPIC and
> > > KVM_CAP_IRQ_XICS, similar to S390.
> > >  But isn't it just weird? I understand that perhaps we have some real 
> > > need to distinguish
> > > between different irqchip types, but
> > > shouldn't the kernel also publish KVM_CAP_IRQCHIP, which stands just for 
> > > "we support some
> > > irqchip virtualization"?
> > >  May be we should just add this for PowerPC and S390, to make things less 
> > > ambiguous?
> > 
> > Note that we explicitly need to _enable_ the s390 cap (for
> > compatibility). I'd need to recall the exact details but I came to the
> > conclusion back than that I could not simply enable KVM_CAP_IRQCHIP for
> > s390 (and current qemu would fail to enable the s390 cap if we started
> > advertising KVM_CAP_IRQCHIP now).
> 
>  OMG... I've looked at the code, what a mess...
>  If i was implementing this, i'd simply introduce kvm_vm_enable_cap(s, 
> KVM_CAP_IRQCHIP, 0),
> which would be allowed to fail with -ENOSYS, so that backwards compatibility 
> is kept and an existing API is reused... But, well,
> it's already impossible to unscramble an egg... :)
>  Ok, i think in current situation we could choose one of these ways (both are 
> based on the fact that it's obvious that irqfd require
> IRQCHIP).
>  a) I look for an alternate way to report KVM_CAP_IRQFD dynamically, and 
> maybe PowerPC and S390 follow this way.

The thing is: _when_ can you report KVM_CAP_IRQFD? It obviously
requires an irqchip; but if you need some configuration/enablement
beforehand, you'll get different values depending on when you retrieve
the cap. So does KVM_CAP_IRQFD mean "irqfds are available in principle"
or "everything has been setup for usage of irqfds"? I'd assume the
former.

>  b) I simply drop it as it is, because current qemu knows about the 
> dependency and does not try to use irqfd without irqchip,
> because there's simply no use for them. But, well, perhaps there would be an 
> exception in vhost, i don't remember testing it.

Wouldn't an irqfd emulation cover vhost?

>  So what shall we do?

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 2/2] KVM: Make KVM_CAP_IRQFD dependent on KVM_CAP_IRQCHIP

[Cornelia Huck]

On Mon, 30 Nov 2015 14:56:38 +0300
Pavel Fedin  wrote:

>  Hello!
> 
> > >   case KVM_CAP_INTERNAL_ERROR_DATA:
> > >  #ifdef CONFIG_HAVE_KVM_MSI
> > >   case KVM_CAP_SIGNAL_MSI:
> > > + /* Fallthrough */
> > >  #endif
> > > + case KVM_CAP_CHECK_EXTENSION_VM:
> > > + return 1;
> > >  #ifdef CONFIG_HAVE_KVM_IRQFD
> > >   case KVM_CAP_IRQFD:
> > >   case KVM_CAP_IRQFD_RESAMPLE:
> > > + return kvm_vm_ioctl_check_extension(kvm, KVM_CAP_IRQCHIP);
> > 
> > This won't work for s390, as it doesn't have KVM_CAP_IRQCHIP but
> > KVM_CAP_S390_IRQCHIP (which needs to be enabled).
> 
>  Thank you for the note, i didn't know about irqchip-specific capability 
> codes. There's the same issue with PowerPC, now i
> understand why there's no KVM_CAP_IRQCHIP for them. Because they have 
> KVM_CAP_IRQ_MPIC and KVM_CAP_IRQ_XICS, similar to S390.
>  But isn't it just weird? I understand that perhaps we have some real need to 
> distinguish between different irqchip types, but
> shouldn't the kernel also publish KVM_CAP_IRQCHIP, which stands just for "we 
> support some irqchip virtualization"?
>  May be we should just add this for PowerPC and S390, to make things less 
> ambiguous?

Note that we explicitly need to _enable_ the s390 cap (for
compatibility). I'd need to recall the exact details but I came to the
conclusion back than that I could not simply enable KVM_CAP_IRQCHIP for
s390 (and current qemu would fail to enable the s390 cap if we started
advertising KVM_CAP_IRQCHIP now).

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 2/2] KVM: Make KVM_CAP_IRQFD dependent on KVM_CAP_IRQCHIP

[Cornelia Huck]

On Mon, 30 Nov 2015 12:40:45 +0300
Pavel Fedin  wrote:

> Now at least ARM is able to determine whether the machine has
> virtualization support for irqchip or not at runtime. Obviously,
> irqfd requires irqchip.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  virt/kvm/kvm_main.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 7873d6d..a057d5e 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2716,13 +2716,15 @@ static long 
> kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>   case KVM_CAP_INTERNAL_ERROR_DATA:
>  #ifdef CONFIG_HAVE_KVM_MSI
>   case KVM_CAP_SIGNAL_MSI:
> + /* Fallthrough */
>  #endif
> + case KVM_CAP_CHECK_EXTENSION_VM:
> + return 1;
>  #ifdef CONFIG_HAVE_KVM_IRQFD
>   case KVM_CAP_IRQFD:
>   case KVM_CAP_IRQFD_RESAMPLE:
> + return kvm_vm_ioctl_check_extension(kvm, KVM_CAP_IRQCHIP);

This won't work for s390, as it doesn't have KVM_CAP_IRQCHIP but
KVM_CAP_S390_IRQCHIP (which needs to be enabled).

>  #endif
> - case KVM_CAP_CHECK_EXTENSION_VM:
> - return 1;
>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>   case KVM_CAP_IRQ_ROUTING:
>   return KVM_MAX_IRQ_ROUTES;

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: Add Kconfig option to signal cross-endian guests

[Cornelia Huck]

On Thu,  9 Jul 2015 09:49:05 +0200
Thomas Huth th...@redhat.com wrote:

 The option for supporting cross-endianness legacy guests in

s/cross-endianness/cross-endian/ ?

 the vhost and tun code should only be available on systems
 that support cross-endian guests.
 
 Signed-off-by: Thomas Huth th...@redhat.com
 ---
  arch/arm/kvm/Kconfig | 1 +
  arch/arm64/kvm/Kconfig   | 1 +
  arch/powerpc/kvm/Kconfig | 1 +
  drivers/net/Kconfig  | 1 +
  drivers/vhost/Kconfig| 1 +
  virt/kvm/Kconfig | 3 +++
  6 files changed, 8 insertions(+)

Acked-by: Cornelia Huck cornelia.h...@de.ibm.com

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v14 01/10] linux-headers: update headers according to 4.1-rc1

[Cornelia Huck]

On Wed, 29 Apr 2015 15:51:58 +0100
Eric Auger eric.au...@linaro.org wrote:

 This updates linux-headers against master 4.1-rc1 (commit
 b787f68c36d49bb1d9236f403813641efa74a031).
 
 This includes, among other things, VFIO platform driver and
 irqfd/arm.
 
 Signed-off-by: Eric Auger eric.au...@linaro.org
 
 ---
 v13 - v14:
 - update to precise 4.1-rc1, precise the commit and change the title
 
 v12 - v13:
 - update for 4.1-rc0 headers
 
 v10 - v11:
 - only includes header modifications related to vfio platform
   driver v14 and not those related to
   vfio: type1: support for ARM SMMUS with VFIO_IOMMU_TYPE1
 
 Signed-off-by: Eric Auger eric.au...@linaro.org
 ---
  include/standard-headers/linux/virtio_balloon.h |  28 +++-
  include/standard-headers/linux/virtio_blk.h |   8 +-
  include/standard-headers/linux/virtio_ids.h |   1 +
  linux-headers/asm-arm/kvm.h |   9 +-
  linux-headers/asm-arm64/kvm.h   |   9 +-
  linux-headers/asm-mips/kvm.h| 164 
 +++-
  linux-headers/asm-s390/kvm.h|   4 +
  linux-headers/asm-x86/hyperv.h  |   2 +
  linux-headers/linux/kvm.h   |  66 +-
  linux-headers/linux/vfio.h  |   2 +
  10 files changed, 223 insertions(+), 70 deletions(-)

Not trying to be a pain, but have you figured out why the virtio-input
header is missing for you?

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm