morev vs. more.
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
Link: https://lore.kernel.org/r/20221105115401.21592-1-olaf@aepfle.deSigned-off-by: NWei Liu <wei.liu@kernel.org>

The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventually, and such function takes a spinlock for the
ring buffer operations.

Panic path runs in atomic context, with local interrupts and
preemption disabled, and all secondary CPUs shutdown. That said,
taking a spinlock might cause a lockup if a secondary CPU was
disabled with such lock taken. Fix it here by checking if the
ring buffer spinlock is busy on Hyper-V framebuffer panic notifier;
if so, bail-out avoiding the potential lockup scenario.

Cc: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Tianyu Lan <Tianyu.Lan@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Tested-by: NFabio A M Martins <fabiomirmar@gmail.com>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220819221731.480795-10-gpiccoli@igalia.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The VMbus driver has special case code for running on the first released
versions of Hyper-V: 2008 and 2008 R2/Windows 7. These versions are now
out of support (except for extended security updates) and lack the
performance features needed for effective production usage of Linux
guests.

Simplify the code by removing the negotiation of the VMbus protocol
versions required for these releases of Hyper-V, and by removing the
special case code for handling these VMbus protocol versions.
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Reviewed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/1651509391-2058-2-git-send-email-mikelley@microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

With no users of hv_pkt_iter_next_raw() and no "external" users of
hv_pkt_iter_first_raw(), the iterator functions can be refactored
and simplified to remove some indirection/code.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220428145107.7878-6-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

So that isolated guests can communicate with the host via hv_sock
channels.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220428145107.7878-5-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

For additional robustness in the face of Hyper-V errors or malicious
behavior, validate all values that originate from packets that Hyper-V
has sent to the guest in the host-to-guest ring buffer.  Ensure that
invalid values cannot cause data being copied out of the bounds of the
source buffer in hvs_stream_dequeue().
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
Link: https://lore.kernel.org/r/20220428145107.7878-4-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

To abtract the lock and unlock operations on the requestor spin lock.
The helpers will come in handy in hv_pci.

No functional change.
Suggested-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220419122325.10078-6-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The function can be used to retrieve and clear/remove a transation ID
from a channel requestor, provided the memory address corresponding to
the ID equals a specified address.  The function, and its 'lockless'
variant __vmbus_request_addr_match(), will be used by hv_pci.

Refactor vmbus_request_addr() to reuse the 'newly' introduced code.

No functional change.
Suggested-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220419122325.10078-5-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The function can be used to send a VMbus packet and retrieve the
corresponding transaction ID.  It will be used by hv_pci.

No functional change.
Suggested-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220419122325.10078-4-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Hyper-V may offer an Initial Machine Configuration (IMC) synthetic
device to guest VMs. The device may be used by Windows guests to get
specialization information, such as the hostname.  But the device
is not used in Linux and there is no Linux driver, so it is
unsupported.

Currently, the IMC device GUID is not recognized by the VMbus driver,
which results in an "Unknown GUID" error message during boot. Add
the GUID to the list of known but unsupported devices so that the
error message is not generated. Other than avoiding the error message,
there is no change in guest behavior.
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1649818140-100953-1-git-send-email-mikelley@microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Use a helper to set driver_override to the reduce amount of duplicated
code.  Make the driver_override field const char, because it is not
modified by the core and it matches other subsystems.
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220419113435.246203-5-krzysztof.kozlowski@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Using DMA_BIT_MASK(64) as an initializer for a global variable
causes problems with Clang 12.0.1. The compiler doesn't understand
that value 64 is excluded from the shift at compile time, resulting
in a build error.

While this is a compiler problem, avoid the issue by setting up
the dma_mask memory as part of struct hv_device, and initialize
it using dma_set_mask().
Reported-by: NNathan Chancellor <nathan@kernel.org>
Reported-by: NVitaly Chikunov <vt@altlinux.org>
Reported-by: NJakub Kicinski <kuba@kernel.org>
Fixes: 743b237c ("scsi: storvsc: Add Isolation VM support for storvsc driver")
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Tested-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/1644176216-12531-1-git-send-email-mikelley@microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

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: NTianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20211213071407.314309-6-ltykernel@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

In Isolation VM, all shared memory with host needs to mark visible
to host via hvcall. vmbus_establish_gpadl() has already done it for
storvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
mpb_desc() still needs to be handled. Use DMA API(scsi_dma_map/unmap)
to map these memory during sending/receiving packet and return swiotlb
bounce buffer dma address. In Isolation VM, swiotlb  bounce buffer is
marked to be visible to host and the swiotlb force mode is enabled.

Set device's dma min align mask to HV_HYP_PAGE_SIZE - 1 in order to
keep the original data offset in the bounce buffer.
Signed-off-by: NTianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: NLong Li <longli@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20211213071407.314309-5-ltykernel@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The last caller of vmbus_are_subchannels_present() was removed in commit
c9675904 ("scsi: storvsc: Fix a race in sub-channel creation that can cause panic").

Remove this dead code, and the utility function invoke_sc_cb() that it is
the only caller of.
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1635191674-34407-1-git-send-email-mikelley@microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Mark vmbus ring buffer visible with set_memory_decrypted() when
establish gpadl handle.
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NTianyu Lan <Tianyu.Lan@microsoft.com>
Link: https://lore.kernel.org/r/20211025122116.264793-5-ltykernel@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

There are some unused inline functions in hyper.h.

Remove those unused functions.
Signed-off-by: NSonia Sharma <sonia.sharma@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1626903663-23615-1-git-send-email-sosha@linux.microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Use blk_mq_unique_tag() to generate requestIDs for StorVSC, avoiding
all issues with allocating enough entries in the VMbus requestor.
Suggested-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Link: https://lore.kernel.org/r/20210510210841.370472-1-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Pointers to ring-buffer packets sent by Hyper-V are used within the
guest VM. Hyper-V can send packets with erroneous values or modify
packet fields after they are processed by the guest. To defend
against these scenarios, return a copy of the incoming VMBus packet
after validating its length and offset fields in hv_pkt_iter_first().
In this way, the packet can no longer be modified by the host.
Signed-off-by: NAndres Beltran <lkmlabelt@gmail.com>
Co-developed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210408161439.341988-1-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Introduce the CHANNELMSG_MODIFYCHANNEL_RESPONSE message type, and code
to receive and process such a message.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210416143449.16185-3-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Hyper-V has added VMBus protocol version 5.3.  Allow Linux guests to
negotiate the new version on version of Hyper-V that support it.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210416143449.16185-2-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

s/sructure/structure/
s/extention/extension/
s/offerred/offered/
s/adversley/adversely/
Signed-off-by: NBhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210321233108.3885240-1-unixbhaskar@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

storvsc currently sets .dma_boundary to limit scatterlist entries to 4
Kbytes, which is less efficient with huge pages that offer large chunks of
contiguous physical memory. Improve the algorithm for creating the Hyper-V
guest physical address PFN array so that scatterlist entries with lengths >
4Kbytes are handled.  As a result, remove the .dma_boundary setting.

The improved algorithm also adds support for scatterlist entries with
offsets >= 4Kbytes, which is supported by many other SCSI low-level
drivers.  And it retains support for architectures where possibly PAGE_SIZE
!= HV_HYP_PAGE_SIZE (such as ARM64).

Link: https://lore.kernel.org/r/1614120294-1930-1-git-send-email-mikelley@microsoft.comReviewed-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

This reverts commit a8c32099.

It is reported that the said commit caused regression in netvsc.
Reported-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NWei Liu <wei.liu@kernel.org>

There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].

Refactor the code according to the use of a flexible-array member in
struct icmsg_negotiate, instead of a one-element array.

Also, this helps the ongoing efforts to enable -Warray-bounds and fix the
following warnings:

drivers/hv/channel_mgmt.c:315:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds]
drivers/hv/channel_mgmt.c:316:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds]

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/109Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210201174334.GA171933@embeddedorSigned-off-by: NWei Liu <wei.liu@kernel.org>

Only the VSCs or ICs that have been hardened and that are critical for
the successful adoption of Confidential VMs should be allowed if the
guest is running isolated.  This change reduces the footprint of the
code that will be exercised by Confidential VMs and hence the exposure
to bugs and vulnerabilities.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210201144814.2701-3-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

An erroneous or malicious host could send multiple rescind messages for
a same channel.  In vmbus_onoffer_rescind(), the guest maps the channel
ID to obtain a pointer to the channel object and it eventually releases
such object and associated data.  The host could time rescind messages
and lead to an use-after-free.  Add a new flag to the channel structure
to make sure that only one instance of vmbus_onoffer_rescind() can get
the reference to the channel object.
Reported-by: NJuan Vazquez <juvazq@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201209070827.29335-6-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

For additional robustness in the face of Hyper-V errors or malicious
behavior, validate all values that originate from packets that Hyper-V
has sent to the guest in the host-to-guest ring buffer. Ensure that
invalid values cannot cause indexing off the end of the icversion_data
array in vmbus_prep_negotiate_resp().
Signed-off-by: NAndres Beltran <lkmlabelt@gmail.com>
Co-developed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201109100704.9152-1-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Pointers to ring-buffer packets sent by Hyper-V are used within the
guest VM. Hyper-V can send packets with erroneous values or modify
packet fields after they are processed by the guest. To defend
against these scenarios, return a copy of the incoming VMBus packet
after validating its length and offset fields in hv_pkt_iter_first().
In this way, the packet can no longer be modified by the host.
Signed-off-by: NAndres Beltran <lkmlabelt@gmail.com>
Co-developed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: netdev@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201208045311.10244-1-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Currently, pointers to guest memory are passed to Hyper-V as
transaction IDs in netvsc. In the face of errors or malicious
behavior in Hyper-V, netvsc should not expose or trust the transaction
IDs returned by Hyper-V to be valid guest memory addresses. Instead,
use small integers generated by vmbus_requestor as requests
(transaction) IDs.
Signed-off-by: NAndres Beltran <lkmlabelt@gmail.com>
Co-developed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NWei Liu <wei.liu@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Link: https://lore.kernel.org/r/20201109100402.8946-4-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Currently, VMbus drivers use pointers into guest memory as request IDs
for interactions with Hyper-V. To be more robust in the face of errors
or malicious behavior from a compromised Hyper-V, avoid exposing
guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a
bad request ID that is then treated as the address of a guest data
structure with no validation. Instead, encapsulate these memory
addresses and provide small integers as request IDs.
Signed-off-by: NAndres Beltran <lkmlabelt@gmail.com>
Co-developed-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Reviewed-by: NWei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20201109100402.8946-2-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

When a guest communicate with the hypervisor, it must use HV_HYP_PAGE to
calculate PFN, so introduce a few hvpfn helper functions as the
counterpart of the page helper functions. This is the preparation for
supporting guest whose PAGE_SIZE is not 4k.
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200916034817.30282-7-boqun.feng@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

There will be more places other than vmbus where we need to calculate
the Hyper-V page PFN from a virtual address, so move virt_to_hvpfn() to
hyperv generic header.
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200916034817.30282-6-boqun.feng@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

This patch introduces two types of GPADL: HV_GPADL_{BUFFER, RING}. The
types of GPADL are purely the concept in the guest, IOW the hypervisor
treat them as the same.

The reason of introducing the types for GPADL is to support guests whose
page size is not 4k (the page size of Hyper-V hypervisor). In these
guests, both the headers and the data parts of the ringbuffers need to
be aligned to the PAGE_SIZE, because 1) some of the ringbuffers will be
mapped into userspace and 2) we use "double mapping" mechanism to
support fast wrap-around, and "double mapping" relies on ringbuffers
being page-aligned. However, the Hyper-V hypervisor only uses 4k
(HV_HYP_PAGE_SIZE) headers. Our solution to this is that we always make
the headers of ringbuffers take one guest page and when GPADL is
established between the guest and hypervisor, the only first 4k of
header is used. To handle this special case, we need the types of GPADL
to differ different guest memory usage for GPADL.

Type enum is introduced along with several general interfaces to
describe the differences between normal buffer GPADL and ringbuffer
GPADL.
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200916034817.30282-4-boqun.feng@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The spinlock is (now) *not used to protect test-and-set accesses
to attributes of the structure or sc_list operations.

There is, AFAICT, a distinct lack of {WRITE,READ}_ONCE()s in the
handling of channel->state, but the changes below do not seem to
make things "worse".  ;-)
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/20200617164642.37393-9-parri.andrea@gmail.comReviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NWei Liu <wei.liu@kernel.org>

The field is read only in numa_node_show() and it is already stored twice
(after a call to cpu_to_node()) in target_cpu_store() and init_vp_index();
there is no need to "cache" its value in the channel data structure.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/20200617164642.37393-3-parri.andrea@gmail.comReviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NWei Liu <wei.liu@kernel.org>

The field is read only in __vmbus_open() and it is already stored twice
(after a call to hv_cpu_number_to_vp_number()) in target_cpu_store() and
init_vp_index(); there is no need to "cache" its value in the channel
data structure.
Suggested-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/20200617164642.37393-2-parri.andrea@gmail.comReviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NWei Liu <wei.liu@kernel.org>

init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map.  This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.

To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).

Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical.  init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes.  A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.

Fixes: 75278105 ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507185323.GA14416@embeddedorSigned-off-by: NWei Liu <wei.liu@kernel.org>

For each storvsc_device, storvsc keeps track of the channel target CPUs
associated to the device (alloced_cpus) and it uses this information to
fill a "cache" (stor_chns) mapping CPU->channel according to a certain
heuristic.  Update the alloced_cpus mask and the stor_chns array when a
channel of the storvsc device is re-assigned to a different CPU.
Signed-off-by: NAndrea Parri (Microsoft) <parri.andrea@gmail.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: <linux-scsi@vger.kernel.org>
Link: https://lore.kernel.org/r/20200406001514.19876-12-parri.andrea@gmail.com
Reviewed-by; Long Li <longli@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
[ wei: fix a small issue reported by kbuild test robot <lkp@intel.com> ]
Signed-off-by: NWei Liu <wei.liu@kernel.org>