This patchset add the necessary changes to support guests whose page size is larger than 4K.
Previous version: v1: https://lore.kernel.org/lkml/20200721014135.84140-1-boqun.f...@gmail.com/ Changes since v1: * Introduce a hv_ring_gpadl_send_offset() to improve the readability as per suggestion from Michael. * Use max(..., 2 * PAGE_SIZE) instead of hard-coding size for inputvsc ringbuffer to align with other ringbuffer settinngs * Calculate the exact size of storvsc payload (other than a maximum size) to save memory in storvsc_queuecommand() as per suggestion from Michael. * Use "unsigned int" for loop index inside a page, so that we can have the compiler's help for optimization in PAGE_SIZE == HV_HYP_PAGE_SIZE case as per suggestion from Michael. * Rebase on to v5.9-rc2 with Michael's latest core support patchset[1] Hyper-V always uses 4K as the page size and expects the same page size when communicating with guests. That is, all the "pfn"s in the hypervisor-guest communication protocol are the page numbers in the unit of HV_HYP_PAGE_SIZE rather than PAGE_SIZE. To support guests with larger page size, we need to convert between these two page sizes correctly in the hypervisor-guest communication, which is basically what this patchset does. In this conversion, one challenge is how to handle the ringbuffer. A ringbuffer has two parts: a header and a data part, both of which want to be PAGE_SIZE aligned in the guest, because we use the "double mapping" trick to map the data part twice in the guest virtual address space for faster wrap-around and ease to process data in place. However, the Hyper-V hypervisor always treats the ringbuffer headers as 4k pages. To overcome this gap, we enlarge the hv_ring_buffer structure to be always PAGE_SIZE aligned, and introduce the gpadl type concept to allow vmbus_establish_gpadl() to handle ringbuffer cases specially. Note that gpadl type is only meaningful to the guest, there is no such concept in Hyper-V hypervisor. This patchset consists of 11 patches: Patch 1~4: Introduce the types of gpadl, so that we can handle ringbuffer when PAGE_SIZE != HV_HYP_PAGE_SIZE, and also fix a few places where we should use HV_HYP_PAGE_SIZE other than PAGE_SIZE. Patch 5~6: Add a few helper functions to help calculate the hvpfn (page number in the unit of HV_HYP_PAGE_SIZE) and other related data. So that we can use them in the code of drivers. Patch 7~11: Use the helpers and change the driver code accordingly to make net/input/util/storage driver work with PAGE_SIZE != HV_HYP_PAGE_SIZE I've done some tests with PAGE_SIZE=64k and PAGE_SIZE=16k configurations on ARM64 guests (with Michael's patchset[1] for ARM64 Hyper-V guest support), nothing major breaks yet ;-) (I could observe an error caused by unaligned firmware data, but it's better to have it fixed in the Hyper-V). I also have done a build and boot test on x86, everything worked well. Looking forwards to comments and suggestions! Regards, Boqun [1]: https://lore.kernel.org/lkml/1598287583-71762-1-git-send-email-mikel...@microsoft.com/ Boqun Feng (11): Drivers: hv: vmbus: Always use HV_HYP_PAGE_SIZE for gpadl Drivers: hv: vmbus: Move __vmbus_open() Drivers: hv: vmbus: Introduce types of GPADL Drivers: hv: Use HV_HYP_PAGE in hv_synic_enable_regs() Drivers: hv: vmbus: Move virt_to_hvpfn() to hyperv header hv: hyperv.h: Introduce some hvpfn helper functions hv_netvsc: Use HV_HYP_PAGE_SIZE for Hyper-V communication Input: hyperv-keyboard: Make ringbuffer at least take two pages HID: hyperv: Make ringbuffer at least take two pages Driver: hv: util: Make ringbuffer at least take two pages scsi: storvsc: Support PAGE_SIZE larger than 4K drivers/hid/hid-hyperv.c | 4 +- drivers/hv/channel.c | 462 ++++++++++++++++---------- drivers/hv/hv.c | 4 +- drivers/hv/hv_util.c | 16 +- drivers/input/serio/hyperv-keyboard.c | 4 +- drivers/net/hyperv/netvsc.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 46 +-- drivers/net/hyperv/rndis_filter.c | 12 +- drivers/scsi/storvsc_drv.c | 60 +++- include/linux/hyperv.h | 63 +++- 10 files changed, 447 insertions(+), 226 deletions(-) -- 2.28.0
