On Wed, 02 Oct 2024 20:53:28 -0700, mhkelle...@gmail.com wrote:
> Code specific to Hyper-V guests currently assumes the cpu_possible_mask
> is "dense" -- i.e., all bit positions 0 thru (nr_cpu_ids - 1) are set,
> with no "holes". Therefore, num_possible_cpus() is assumed to be equal
> to nr_cpu_id
When device memory blocks are hot-added via add_memory_driver_managed(),
the HV balloon driver intercepts them but fails to online these memory
blocks. This could result in device driver initialization failures.
To address this, fall back to the generic online callback for memory
blocks not added
Receive and send buffer allocation was originally introduced to support
DPDK's networking use case. These buffer sizes were further increased to
meet DPDK performance requirements. However, these large buffers are
unnecessary for any other UIO use cases.
Restrict the allocation of receive and send
Channel offers are requested during VMBus initialization and resume from
hibernation. Add support to wait for all boot-time channel offers to
be delivered and processed before returning from vmbus_request_offers.
This is in analogy to a PCI bus not returning from probe until it has
scanned all dev
From: John Starks
When resuming from hibernation, log any channels that were present
before hibernation but now are gone.
In general, the boot-time devices configured for a resuming VM should be
the same as the devices in the VM at the time of hibernation. It's
uncommon for the configuration to h
After VM requests for channel offers during boot or resume from
hibernation, host offers the devices that the VM is configured with and
then sends a separate message indicating that all the boot-time channel
offers are delivered. Wait for this message to make this boot-time offers
request and recei
