<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/asm-generic/mshyperv.h, branch v6.4</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.4</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.4'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-04-17T19:19:05Z</updated>
<entry>
<title>x86/hyperv: Add callback filter to cpumask_to_vpset()</title>
<updated>2023-04-17T19:19:05Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2023-03-27T13:16:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d7b6ba9611aefc4bef207b16db8ff06b726efe35'/>
<id>urn:sha1:d7b6ba9611aefc4bef207b16db8ff06b726efe35</id>
<content type='text'>
When copying CPUs from a Linux cpumask to a Hyper-V VPset,
cpumask_to_vpset() currently has a "_noself" variant that doesn't copy
the current CPU to the VPset. Generalize this variant by replacing it
with a "_skip" variant having a callback function that is invoked for
each CPU to decide if that CPU should be copied. Update the one caller
of cpumask_to_vpset_noself() to use the new "_skip" variant instead.

No functional change.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lore.kernel.org/r/1679922967-26582-2-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>hv_netvsc: Remove second mapping of send and recv buffers</title>
<updated>2023-04-17T19:19:04Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2023-03-26T13:52:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=25727aaed6514b88f98a18862c6f2d65a0b0ec3b'/>
<id>urn:sha1:25727aaed6514b88f98a18862c6f2d65a0b0ec3b</id>
<content type='text'>
With changes to how Hyper-V guest VMs flip memory between private
(encrypted) and shared (decrypted), creating a second kernel virtual
mapping for shared memory is no longer necessary.  Everything needed
for the transition to shared is handled by set_memory_decrypted().

As such, remove the code to create and manage the second
mapping for the pre-allocated send and recv buffers.  This mapping
is the last user of hv_map_memory()/hv_unmap_memory(), so delete
these functions as well.  Finally, hv_map_memory() is the last
user of vmap_pfn() in Hyper-V guest code, so remove the Kconfig
selection of VMAP_PFN.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Reviewed-by: Tianyu Lan &lt;Tianyu.Lan@microsoft.com&gt;
Link: https://lore.kernel.org/r/1679838727-87310-11-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/hyperv: Change vTOM handling to use standard coco mechanisms</title>
<updated>2023-03-27T07:31:43Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2023-03-26T13:52:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=812b0597fb4043240724e4c7bed7ba1fe15c0e3f'/>
<id>urn:sha1:812b0597fb4043240724e4c7bed7ba1fe15c0e3f</id>
<content type='text'>
Hyper-V guests on AMD SEV-SNP hardware have the option of using the
"virtual Top Of Memory" (vTOM) feature specified by the SEV-SNP
architecture. With vTOM, shared vs. private memory accesses are
controlled by splitting the guest physical address space into two
halves.

vTOM is the dividing line where the uppermost bit of the physical
address space is set; e.g., with 47 bits of guest physical address
space, vTOM is 0x400000000000 (bit 46 is set).  Guest physical memory is
accessible at two parallel physical addresses -- one below vTOM and one
above vTOM.  Accesses below vTOM are private (encrypted) while accesses
above vTOM are shared (decrypted). In this sense, vTOM is like the
GPA.SHARED bit in Intel TDX.

Support for Hyper-V guests using vTOM was added to the Linux kernel in
two patch sets[1][2]. This support treats the vTOM bit as part of
the physical address. For accessing shared (decrypted) memory, these
patch sets create a second kernel virtual mapping that maps to physical
addresses above vTOM.

A better approach is to treat the vTOM bit as a protection flag, not
as part of the physical address. This new approach is like the approach
for the GPA.SHARED bit in Intel TDX. Rather than creating a second kernel
virtual mapping, the existing mapping is updated using recently added
coco mechanisms.

When memory is changed between private and shared using
set_memory_decrypted() and set_memory_encrypted(), the PTEs for the
existing kernel mapping are changed to add or remove the vTOM bit in the
guest physical address, just as with TDX. The hypercalls to change the
memory status on the host side are made using the existing callback
mechanism. Everything just works, with a minor tweak to map the IO-APIC
to use private accesses.

To accomplish the switch in approach, the following must be done:

* Update Hyper-V initialization to set the cc_mask based on vTOM
  and do other coco initialization.

* Update physical_mask so the vTOM bit is no longer treated as part
  of the physical address

* Remove CC_VENDOR_HYPERV and merge the associated vTOM functionality
  under CC_VENDOR_AMD. Update cc_mkenc() and cc_mkdec() to set/clear
  the vTOM bit as a protection flag.

* Code already exists to make hypercalls to inform Hyper-V about pages
  changing between shared and private.  Update this code to run as a
  callback from __set_memory_enc_pgtable().

* Remove the Hyper-V special case from __set_memory_enc_dec()

* Remove the Hyper-V specific call to swiotlb_update_mem_attributes()
  since mem_encrypt_init() will now do it.

* Add a Hyper-V specific implementation of the is_private_mmio()
  callback that returns true for the IO-APIC and vTPM MMIO addresses

  [1] https://lore.kernel.org/all/20211025122116.264793-1-ltykernel@gmail.com/
  [2] https://lore.kernel.org/all/20211213071407.314309-1-ltykernel@gmail.com/

  [ bp: Touchups. ]

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Link: https://lore.kernel.org/r/1679838727-87310-7-git-send-email-mikelley@microsoft.com
</content>
</entry>
<entry>
<title>x86/hyperv: Add support for detecting nested hypervisor</title>
<updated>2023-01-12T15:23:26Z</updated>
<author>
<name>Jinank Jain</name>
<email>jinankjain@linux.microsoft.com</email>
</author>
<published>2023-01-02T07:12:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c4bdf94f97c86bdee8bacc87f8f85dc67866c928'/>
<id>urn:sha1:c4bdf94f97c86bdee8bacc87f8f85dc67866c928</id>
<content type='text'>
Detect if Linux is running as a nested hypervisor in the root
partition for Microsoft Hypervisor, using flags provided by MSHV.
Expose a new variable hv_nested that is used later for decisions
specific to the nested use case.

Signed-off-by: Jinank Jain &lt;jinankjain@linux.microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lore.kernel.org/r/8e3e7112806e81d2292a66a56fe547162754ecea.1672639707.git.jinankjain@linux.microsoft.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/hyperv: Introduce HV_MAX_SPARSE_VCPU_BANKS/HV_VCPUS_PER_SPARSE_BANK constants</title>
<updated>2022-11-18T17:59:07Z</updated>
<author>
<name>Vitaly Kuznetsov</name>
<email>vkuznets@redhat.com</email>
</author>
<published>2022-11-01T14:53:52Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=bd19c94a19b09b563a20862c651859f6e3d73847'/>
<id>urn:sha1:bd19c94a19b09b563a20862c651859f6e3d73847</id>
<content type='text'>
It may not come clear from where the magical '64' value used in
__cpumask_to_vpset() come from. Moreover, '64' means both the maximum
sparse bank number as well as the number of vCPUs per bank. Add defines
to make things clear. These defines are also going to be used by KVM.

No functional change.

Reviewed-by: Maxim Levitsky &lt;mlevitsk@redhat.com&gt;
Reviewed-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Vitaly Kuznetsov &lt;vkuznets@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Message-Id: &lt;20221101145426.251680-15-vkuznets@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
</content>
</entry>
<entry>
<title>hyperv: simplify and rename generate_guest_id</title>
<updated>2022-09-28T13:36:56Z</updated>
<author>
<name>Li kunyu</name>
<email>kunyu@nfschina.com</email>
</author>
<published>2022-09-28T06:40:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d5ebde1e2b46154d7e03efb1ae3039a304e5386d'/>
<id>urn:sha1:d5ebde1e2b46154d7e03efb1ae3039a304e5386d</id>
<content type='text'>
The generate_guest_id function is more suitable for use after the
following modifications.

1. The return value of the function is modified to u64.
2. Remove the d_info1 and d_info2 parameters from the function, keep the
   u64 type kernel_version parameter.
3. Rename the function to make it clearly a Hyper-V related function,
   and modify it to hv_generate_guest_id.

Signed-off-by: Li kunyu &lt;kunyu@nfschina.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lore.kernel.org/r/20220928064046.3545-1-kunyu@nfschina.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: vmbus: Propagate VMbus coherence to each VMbus device</title>
<updated>2022-03-29T12:12:50Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2022-03-24T16:14:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=37200078ed6aa2ac3c88a01a64996133dccfdd34'/>
<id>urn:sha1:37200078ed6aa2ac3c88a01a64996133dccfdd34</id>
<content type='text'>
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not hardware coherent.
Drivers for some of these synthetic devices have been recently
updated to use the standard DMA APIs, and they are incurring extra
overhead of unneeded software coherence management.

Fix this by propagating coherence information from the VMbus node
in ACPI to the individual synthetic devices. There's no effect on
x86/x64 where devices are always hardware coherent.

Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Acked-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Link: https://lore.kernel.org/r/1648138492-2191-2-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>Drivers: hv: Fix definition of hypercall input &amp; output arg variables</title>
<updated>2021-12-28T14:18:43Z</updated>
<author>
<name>Michael Kelley</name>
<email>mikelley@microsoft.com</email>
</author>
<published>2021-12-28T03:31:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=db3c65bc3a1308db8c914b2bf477b5a36005c3d3'/>
<id>urn:sha1:db3c65bc3a1308db8c914b2bf477b5a36005c3d3</id>
<content type='text'>
The percpu variables hyperv_pcpu_input_arg and hyperv_pcpu_output_arg
have been incorrectly defined since their inception.  The __percpu
qualifier should be associated with the void * (i.e., a pointer), not
with the target of the pointer. This distinction makes no difference
to gcc and the generated code, but sparse correctly complains.  Fix
the definitions in the interest of general correctness in addition
to making sparse happy.

No functional change.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lore.kernel.org/r/1640662315-22260-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: netvsc: Add Isolation VM support for netvsc driver</title>
<updated>2021-12-20T18:01:09Z</updated>
<author>
<name>Tianyu Lan</name>
<email>Tianyu.Lan@microsoft.com</email>
</author>
<published>2021-12-13T07:14:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=846da38de0e8224f2f94b885125cf1fd2d7b0d39'/>
<id>urn:sha1:846da38de0e8224f2f94b885125cf1fd2d7b0d39</id>
<content type='text'>
In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
pagebuffer() stills need to be handled. Use DMA API to map/umap
these memory during sending/receiving packet and Hyper-V swiotlb
bounce buffer dma address will be returned. The swiotlb bounce buffer
has been masked to be visible to host during boot up.

rx/tx ring buffer is allocated via vzalloc() and they need to be
mapped into unencrypted address space(above vTOM) before sharing
with host and accessing. Add hv_map/unmap_memory() to map/umap rx
/tx ring buffer.

Signed-off-by: Tianyu Lan &lt;Tianyu.Lan@microsoft.com&gt;
Reviewed-by: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Link: https://lore.kernel.org/r/20211213071407.314309-6-ltykernel@gmail.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/hyperv: Add ghcb hvcall support for SNP VM</title>
<updated>2021-10-28T11:22:49Z</updated>
<author>
<name>Tianyu Lan</name>
<email>Tianyu.Lan@microsoft.com</email>
</author>
<published>2021-10-25T12:21:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=20c89a559e00dfe352b73e867211a669113ae881'/>
<id>urn:sha1:20c89a559e00dfe352b73e867211a669113ae881</id>
<content type='text'>
hyperv provides ghcb hvcall to handle VMBus
HVCALL_SIGNAL_EVENT and HVCALL_POST_MESSAGE
msg in SNP Isolation VM. Add such support.

Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Tianyu Lan &lt;Tianyu.Lan@microsoft.com&gt;
Link: https://lore.kernel.org/r/20211025122116.264793-8-ltykernel@gmail.com
Signed-off-by: Wei Liu &lt;wei.liu@kernel.org&gt;
</content>
</entry>
</feed>
