<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/Documentation/virt, branch v6.2</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.2</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.2'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-02-04T13:57:43Z</updated>
<entry>
<title>Merge tag 'kvmarm-fixes-6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD</title>
<updated>2023-02-04T13:57:43Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2023-02-04T13:57:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=25b72cf7da9f0d66eef3979187ddfda98d4efcd0'/>
<id>urn:sha1:25b72cf7da9f0d66eef3979187ddfda98d4efcd0</id>
<content type='text'>
KVM/arm64 fixes for 6.2, take #3

- Yet another fix for non-CPU accesses to the memory backing
  the VGICv3 subsystem

- A set of fixes for the setlftest checking for the S1PTW
  behaviour after the fix that went in ealier in the cycle
</content>
</entry>
<entry>
<title>KVM: arm64: Allow no running vcpu on saving vgic3 pending table</title>
<updated>2023-01-29T18:46:11Z</updated>
<author>
<name>Gavin Shan</name>
<email>gshan@redhat.com</email>
</author>
<published>2023-01-26T23:54:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6028acbe3a5f2119a2a6ddd3e06453c87c09cae0'/>
<id>urn:sha1:6028acbe3a5f2119a2a6ddd3e06453c87c09cae0</id>
<content type='text'>
We don't have a running VCPU context to save vgic3 pending table due
to KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} command on KVM
device "kvm-arm-vgic-v3". The unknown case is caught by kvm-unit-tests.

   # ./kvm-unit-tests/tests/its-pending-migration
   WARNING: CPU: 120 PID: 7973 at arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3325 \
   mark_page_dirty_in_slot+0x60/0xe0
    :
   mark_page_dirty_in_slot+0x60/0xe0
   __kvm_write_guest_page+0xcc/0x100
   kvm_write_guest+0x7c/0xb0
   vgic_v3_save_pending_tables+0x148/0x2a0
   vgic_set_common_attr+0x158/0x240
   vgic_v3_set_attr+0x4c/0x5c
   kvm_device_ioctl+0x100/0x160
   __arm64_sys_ioctl+0xa8/0xf0
   invoke_syscall.constprop.0+0x7c/0xd0
   el0_svc_common.constprop.0+0x144/0x160
   do_el0_svc+0x34/0x60
   el0_svc+0x3c/0x1a0
   el0t_64_sync_handler+0xb4/0x130
   el0t_64_sync+0x178/0x17c

Use vgic_write_guest_lock() to save vgic3 pending table.

Reported-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Signed-off-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20230126235451.469087-5-gshan@redhat.com
</content>
</entry>
<entry>
<title>KVM: arm64: Allow no running vcpu on restoring vgic3 LPI pending status</title>
<updated>2023-01-29T18:46:11Z</updated>
<author>
<name>Gavin Shan</name>
<email>gshan@redhat.com</email>
</author>
<published>2023-01-26T23:54:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2f8b1ad2228a7f1f1e2458864f4bfc1cbdf511ed'/>
<id>urn:sha1:2f8b1ad2228a7f1f1e2458864f4bfc1cbdf511ed</id>
<content type='text'>
We don't have a running VCPU context to restore vgic3 LPI pending status
due to command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM
device "kvm-arm-vgic-its".

Use vgic_write_guest_lock() to restore vgic3 LPI pending status.

Signed-off-by: Gavin Shan &lt;gshan@redhat.com&gt;
Reviewed-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20230126235451.469087-4-gshan@redhat.com
</content>
</entry>
<entry>
<title>KVM: x86/xen: Avoid deadlock by adding kvm-&gt;arch.xen.xen_lock leaf node lock</title>
<updated>2023-01-11T22:45:58Z</updated>
<author>
<name>David Woodhouse</name>
<email>dwmw@amazon.co.uk</email>
</author>
<published>2023-01-11T18:06:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=310bc39546a435c83cc27a0eba878afac0d74714'/>
<id>urn:sha1:310bc39546a435c83cc27a0eba878afac0d74714</id>
<content type='text'>
In commit 14243b387137a ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN
and event channel delivery") the clever version of me left some helpful
notes for those who would come after him:

       /*
        * For the irqfd workqueue, using the main kvm-&gt;lock mutex is
        * fine since this function is invoked from kvm_set_irq() with
        * no other lock held, no srcu. In future if it will be called
        * directly from a vCPU thread (e.g. on hypercall for an IPI)
        * then it may need to switch to using a leaf-node mutex for
        * serializing the shared_info mapping.
        */
       mutex_lock(&amp;kvm-&gt;lock);

In commit 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests")
the other version of me ran straight past that comment without reading it,
and introduced a potential deadlock by taking vcpu-&gt;mutex and kvm-&gt;lock
in the wrong order.

Solve this as originally suggested, by adding a leaf-node lock in the Xen
state rather than using kvm-&gt;lock for it.

Fixes: 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests")
Signed-off-by: David Woodhouse &lt;dwmw@amazon.co.uk&gt;
Message-Id: &lt;20230111180651.14394-4-dwmw2@infradead.org&gt;
[Rebase, add docs. - Paolo]
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'kvmarm-fixes-6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master</title>
<updated>2023-01-11T18:31:53Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2023-01-11T18:31:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=71d0393576e9e1ef536c3bc3cf11f661c58dded9'/>
<id>urn:sha1:71d0393576e9e1ef536c3bc3cf11f661c58dded9</id>
<content type='text'>
KVM/arm64 fixes for 6.2, take #1

- Fix the PMCR_EL0 reset value after the PMU rework

- Correctly handle S2 fault triggered by a S1 page table walk
  by not always classifying it as a write, as this breaks on
  R/O memslots

- Document why we cannot exit with KVM_EXIT_MMIO when taking
  a write fault from a S1 PTW on a R/O memslot

- Put the Apple M2 on the naughty step for not being able to
  correctly implement the vgic SEIS feature, just liek the M1
  before it

- Reviewer updates: Alex is stepping down, replaced by Zenghui
</content>
</entry>
<entry>
<title>Documentation: kvm: fix SRCU locking order docs</title>
<updated>2023-01-11T18:31:33Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2023-01-09T11:02:16Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3a9ae31ac26a58d33008c42f6cd022afc2af2dc0'/>
<id>urn:sha1:3a9ae31ac26a58d33008c42f6cd022afc2af2dc0</id>
<content type='text'>
kvm-&gt;srcu is taken in KVM_RUN and several other vCPU ioctls, therefore
vcpu-&gt;mutex is susceptible to the same deadlock that is documented
for kvm-&gt;slots_lock.  The same holds for kvm-&gt;lock, since kvm-&gt;lock
is held outside vcpu-&gt;mutex.  Fix the documentation and rearrange it
to highlight the difference between these locks and kvm-&gt;slots_arch_lock,
and how kvm-&gt;slots_arch_lock can be useful while processing a vmexit.

Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID</title>
<updated>2023-01-09T10:35:21Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2022-10-22T08:17:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=45e966fcca03ecdcccac7cb236e16eea38cc18af'/>
<id>urn:sha1:45e966fcca03ecdcccac7cb236e16eea38cc18af</id>
<content type='text'>
Passing the host topology to the guest is almost certainly wrong
and will confuse the scheduler.  In addition, several fields of
these CPUID leaves vary on each processor; it is simply impossible to
return the right values from KVM_GET_SUPPORTED_CPUID in such a way that
they can be passed to KVM_SET_CPUID2.

The values that will most likely prevent confusion are all zeroes.
Userspace will have to override it anyway if it wishes to present a
specific topology to the guest.

Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/s1ptw-write-fault into kvmarm-master/fixes</title>
<updated>2023-01-05T15:25:54Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2023-01-05T15:25:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=afbb1b1caef7fb8b23f31f32162dd5756d877dd5'/>
<id>urn:sha1:afbb1b1caef7fb8b23f31f32162dd5756d877dd5</id>
<content type='text'>
* kvm-arm64/s1ptw-write-fault:
  : .
  : Fix S1PTW fault handling that was until then always taken
  : as a write. From the cover letter:
  :
  : `Recent developments on the EFI front have resulted in guests that
  : simply won't boot if the page tables are in a read-only memslot and
  : that you're a bit unlucky in the way S2 gets paged in... The core
  : issue is related to the fact that we treat a S1PTW as a write, which
  : is close enough to what needs to be done. Until to get to RO memslots.
  :
  : The first patch fixes this and is definitely a stable candidate. It
  : splits the faulting of page tables in two steps (RO translation fault,
  : followed by a writable permission fault -- should it even happen).
  : The second one documents the slightly odd behaviour of PTW writes to
  : RO memslot, which do not result in a KVM_MMIO exit. The last patch is
  : totally optional, only tangentially related, and randomly repainting
  : stuff (maybe that's contagious, who knows)."
  :
  : .
  KVM: arm64: Convert FSC_* over to ESR_ELx_FSC_*
  KVM: arm64: Document the behaviour of S1PTW faults on RO memslots
  KVM: arm64: Fix S1PTW handling on RO memslots

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Document the behaviour of S1PTW faults on RO memslots</title>
<updated>2023-01-03T10:01:52Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2022-12-22T09:26:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b8f8d190fa8fa1909dda12d771df67125d6fbf0c'/>
<id>urn:sha1:b8f8d190fa8fa1909dda12d771df67125d6fbf0c</id>
<content type='text'>
Although the KVM API says that a write to a RO memslot must result
in a KVM_EXIT_MMIO describing the write, the arm64 architecture
doesn't provide the *data* written by a Stage-1 page table walk
(we only get the address).

Since there isn't much userspace can do with so little information
anyway, document the fact that such an access results in a guest
exception, not an exit. This is consistent with the guest being
terminally broken anyway.

Reviewed-by: Oliver Upton &lt;oliver.upton@linux.dev&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'kvm-late-6.1-fixes' into HEAD</title>
<updated>2022-12-28T12:19:14Z</updated>
<author>
<name>Paolo Bonzini</name>
<email>pbonzini@redhat.com</email>
</author>
<published>2022-12-28T11:26:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a5496886eb130ea08b1a5cd5c284543909bde749'/>
<id>urn:sha1:a5496886eb130ea08b1a5cd5c284543909bde749</id>
<content type='text'>
x86:

* several fixes to nested VMX execution controls

* fixes and clarification to the documentation for Xen emulation

* do not unnecessarily release a pmu event with zero period

* MMU fixes

* fix Coverity warning in kvm_hv_flush_tlb()

selftests:

* fixes for the ucall mechanism in selftests

* other fixes mostly related to compilation with clang
</content>
</entry>
</feed>
