Re: [PATCH RFC 2/2] PCI: hv: Add vPCI device reset support

On Tue, Aug 11, 2026 at 04:10:33PM +0000, Michael Kelley wrote:
> From: [email protected] <[email protected]> Sent: Friday, July 24, 2026 4:09 PM
> > 
> > Hyper-V vPCI protocol version 1.5 adds a RESET_DEVICE request for projected
> > PCI functions. Negotiate the new protocol version and issue the request
> > through the vPCI VMBus channel from the PCI controller reset callback.
> > 
> > Use the existing VMBus response path. Return -ENOTTY when the host reports
> > STATUS_NOT_SUPPORTED so PCI core may try another reset method.
> > 
> > Signed-off-by: Wei Liu <[email protected]>
> > ---
> >  Documentation/virt/hyperv/vpci.rst  |  2 +-
> >  drivers/pci/controller/pci-hyperv.c | 61 +++++++++++++++++++++++++++++
> >  2 files changed, 62 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/virt/hyperv/vpci.rst b/Documentation/virt/hyperv/vpci.rst
> > index b65b2126ede3..6bfee7225c14 100644
> > --- a/Documentation/virt/hyperv/vpci.rst
> > +++ b/Documentation/virt/hyperv/vpci.rst
> > @@ -65,7 +65,7 @@ exchange messages with the vPCI VSP for the purpose of setting
> >  up and configuring the vPCI device in Linux.  Once the device
> >  is fully configured in Linux as a PCI device, the VMBus
> >  channel is used only if Linux changes the vCPU to be interrupted
> > -in the guest, or if the vPCI device is removed from
> > +in the guest, or if the vPCI device is reset or removed from
> >  the VM while the VM is running.  The ongoing operation of the
> >  device happens directly between the Linux device driver for
> >  the device and the hardware, with VMBus and the VMBus channel
> > diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> > index cfc8fa403dad..d3c0fd5e1d8e 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -68,6 +68,7 @@ enum pci_protocol_version_t {
> >  	PCI_PROTOCOL_VERSION_1_2 = PCI_MAKE_VERSION(1, 2),	/* RS1 */
> >  	PCI_PROTOCOL_VERSION_1_3 = PCI_MAKE_VERSION(1, 3),	/* Vibranium */
> >  	PCI_PROTOCOL_VERSION_1_4 = PCI_MAKE_VERSION(1, 4),	/* WS2022 */
> > +	PCI_PROTOCOL_VERSION_1_5 = PCI_MAKE_VERSION(1, 5),	/* GE, device reset */
> 
> I wish there were a better way to identify the Hyper-V version than internal
> code names that mean nothing to the Linux community. "GE" refers to
> Germanium, which would be the Build 26100 series, right?
> 

Yes, you're right about Germanium. I see the numbers also match, though
I don't have a clear idea that the numbering will stay the same.

> >  };
> > 
> >  #define CPU_AFFINITY_ALL	-1ULL
> > @@ -77,6 +78,7 @@ enum pci_protocol_version_t {
> >   * first.
> >   */
> >  static enum pci_protocol_version_t pci_protocol_versions[] = {
> > +	PCI_PROTOCOL_VERSION_1_5,
> >  	PCI_PROTOCOL_VERSION_1_4,
> >  	PCI_PROTOCOL_VERSION_1_3,
> >  	PCI_PROTOCOL_VERSION_1_2,
> > @@ -90,6 +92,7 @@ static enum pci_protocol_version_t pci_protocol_versions[] = {
> >  #define MAX_SUPPORTED_MSI_MESSAGES 0x400
> > 
> >  #define STATUS_REVISION_MISMATCH 0xC0000059
> > +#define STATUS_NOT_SUPPORTED     0xC00000BB
> > 
> >  /* space for 32bit serial number as string */
> >  #define SLOT_NAME_SIZE 11
> > @@ -136,6 +139,7 @@ enum pci_message_type {
> >  	PCI_BUS_RELATIONS2		= PCI_MESSAGE_BASE + 0x19,
> >  	PCI_RESOURCES_ASSIGNED3         = PCI_MESSAGE_BASE + 0x1A,
> >  	PCI_CREATE_INTERRUPT_MESSAGE3   = PCI_MESSAGE_BASE + 0x1B,
> > +	PCI_RESET_DEVICE                = PCI_MESSAGE_BASE + 0x1C,
> >  	PCI_MESSAGE_MAXIMUM
> >  };
> > 
> > @@ -1397,10 +1401,66 @@ static int hv_pcifront_write_config(struct pci_bus *bus,
> > unsigned int devfn,
> >  	return PCIBIOS_SUCCESSFUL;
> >  }
> > 
> > +static int hv_pcifront_reset(struct pci_dev *pdev, bool probe)
> > +{
> > +	struct hv_pcibus_device *hbus =
> > +		container_of(pdev->bus->sysdata, struct hv_pcibus_device, sysdata);
> > +	struct pci_child_message reset = {};
> > +	struct hv_pci_compl comp_pkt;
> > +	struct pci_packet pkt = {
> > +		.completion_func = hv_pci_generic_compl,
> > +		.compl_ctxt = &comp_pkt,
> > +	};
> > +	enum hv_pcibus_state state;
> > +	int ret;
> > +
> > +	/* Device reset was added in vPCI protocol version 1.5. */
> > +	if (hbus->protocol_version < PCI_PROTOCOL_VERSION_1_5)
> > +		return -ENOTTY;
> > +
> > +	/* Hyper-V exposes projected functions directly on the root bus. */
> > +	if (!pci_is_root_bus(pdev->bus))
> > +		return -ENOTTY;
> > +
> > +	if (probe)
> > +		return 0;
> > +
> > +	/* Do not take state_lock: eject holds it while removing/locking pdev. */
> > +	state = READ_ONCE(hbus->state);
> > +	if (state != hv_pcibus_probed && state != hv_pcibus_installed)
> > +		return -ENODEV;
> > +
> > +	init_completion(&comp_pkt.host_event);
> > +	reset.message_type.type = PCI_RESET_DEVICE;
> > +	reset.wslot.slot = devfn_to_wslot(pdev->devfn);
> > +
> > +	ret = vmbus_sendpacket(hbus->hdev->channel, &reset, sizeof(reset),
> > +			       (unsigned long)&pkt, VM_PKT_DATA_INBAND,
> > +			       VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = wait_for_response(hbus->hdev, &comp_pkt.host_event);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (comp_pkt.completion_status == STATUS_NOT_SUPPORTED)
> > +		return -ENOTTY;
> 
> I tried this patch series in a linux-next20260726 build, and running on a D16lds v6
> VM in Azure. The host hypervisor version is 10.0.26100.1652-1-0, and the VM
> has a paravisor with HvLite.
> 
> This VM has an NVMe OS disk, two NVMe temp disks, and a MANA network controller.
> Absent this patch set, the temp disks and MANA report the "reset_method" as "flr",
> while the NVMe OS disk reports no reset methods. With this patch set, "controller"
> is added as a reset method for all. The NVMe disks and MANA network controller
> are probed with PCI protocol 1.5. That's all good and as expected (though I'm not
> sure why the NVMe OS disk doesn't support flr).
> 
> I then did "echo 1 >reset" for the NVMe OS disk. This returns a -ENOTTY error
> from the above line of code. So the host hypervisor (or paravisor?) is saying that
> the new PCI_RESET_DEVICE message isn't supported. Presumably this is new
> functionality that hasn’t been rolled out to where I'm running this Azure VM.
> That's fine too.
> 

That's right. It is not yet rolled out.

> But interestingly, the NVMe OS disk did a Linux-side reset anyway. That's
> because of this stack trace from the "echo 1 >reset" command:
> 
> [   99.642483]  nvme_try_sched_reset+0x25/0x60 [nvme_core]
> [   99.642495]  nvme_reset_done+0x1c/0x40 [nvme]
> [   99.642499]  pci_dev_restore+0x35/0x70
> [   99.642503]  pci_reset_function+0x100/0x140
> [   99.642506]  reset_store+0x5a/0xa0
> [   99.642508]  dev_attr_store+0x16/0x30
> [   99.642512]  sysfs_kf_write+0x71/0x80
> [   99.642516]  kernfs_fop_write_iter+0x140/0x1d0
> [   99.642518]  vfs_write+0x313/0x420
> [   99.642522]  ksys_write+0x68/0xe0
> [   99.642525]  __x64_sys_write+0x18/0x20
> [   99.642527]  x64_sys_call+0x1700/0x21c0
> [   99.642530]  do_syscall_64+0x8d/0x440
> [   99.642532]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Even though __pci_reset_function_locked() failed, the subsequent
> code in pci_reset_function() calls nvme_try_sched_reset(), which puts
> nvme_reset_work() on a workqueue.  nvme_reset_work() tears
> things down on the Linux side and rebuilds, and the message
> 
>     nvme nvme0: 16/0/0 default/read/poll queues
> 
> is output.
> 
> It's not immediately clear to me how to resolve this issue, so
> I'm just pointing it out. :-(
> 

Is resetting the OS disk a real use case?

I'm not sure what magic is happening behind this.

Wei

> Michael
> 
> > +
> > +	if (comp_pkt.completion_status) {
> > +		pci_err(pdev, "Hyper-V device reset failed: %#x\n",
> > +			comp_pkt.completion_status);
> > +		return -EIO;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  /* PCIe operations */
> >  static struct pci_ops hv_pcifront_ops = {
> >  	.read  = hv_pcifront_read_config,
> >  	.write = hv_pcifront_write_config,
> > +	.reset = hv_pcifront_reset,
> >  };
> > 
> >  /*
> > @@ -1996,6 +2056,7 @@ static void hv_compose_msi_msg(struct irq_data *data,
> > struct msi_msg *msg)
> >  		break;
> > 
> >  	case PCI_PROTOCOL_VERSION_1_4:
> > +	case PCI_PROTOCOL_VERSION_1_5:
> >  		size = hv_compose_msi_req_v3(&ctxt.int_pkts.v3,
> >  					cpu,
> >  					hpdev->desc.win_slot.slot,
> > --
> > 2.53.0
> > 
>