Skip to content

[shimV2] adds vpci device controller#2643

Open
rawahars wants to merge 1 commit intomicrosoft:mainfrom
rawahars:vpci-dev-ctrl
Open

[shimV2] adds vpci device controller#2643
rawahars wants to merge 1 commit intomicrosoft:mainfrom
rawahars:vpci-dev-ctrl

Conversation

@rawahars
Copy link
Contributor

Summary

This change adds the VPCI device controller which can be used to assign/unassign virtual PCI devices to the UVM. The same then can be assigned to the containers running in the UVM.

Changes

The package exposes a controller that handles the full lifecycle of vPCI device assignments on a UVM. When a device is assigned, the controller issues a host-side HCS call to attach the physical PCI device to the VM. For Linux guests (LCOW), it additionally notifies the GCS so the guest can wait for the required device paths to become available before any workload uses them. For Windows guests (WCOW), no guest-side notification is needed. When a device is removed, the controller tears down the host-side assignment and cleans up all associated state.

Key Design Decisions

  • Reference counting: If the same physical device is assigned multiple times, the controller reuses the existing VMBus channel and increments a reference count instead of issuing a duplicate HCS call. The device is only removed once the reference count reaches zero.
  • Invalid device state: If the host-side HCS assignment succeeds but the guest-side notification fails, the device is marked invalid. It remains tracked so the caller can still trigger host-side cleanup, preventing resource leaks.

This change adds the VPCI device controller which can be used to assign/unassign virtual PCI devices to the UVM. The same then can be assigned to the containers running in the UVM.

Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
@rawahars rawahars requested a review from a team as a code owner March 23, 2026 09:42
defer m.mu.Unlock()

// Check for an existing assignment with the same device key.
if existingGUID, ok := m.keyToGUID[key]; ok {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have an identity conflict here.

So you either need to allow the caller to specify the guid, and validate that its found settings are the same, or you need to have the caller only specify the host path and vf number and you control the guid. Then you know they match and are associated the same.

// Since the V2 shims only support WS2025 and later, this is set as true.
propagateAffinity := true

settings := hcsschema.VirtualPciDevice{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you supposed to be making a new device for every function? Or are we supposed to be adding functions to a single device? What controls that answer?


// addGuestVPCIDevice notifies the guest about the new device and blocks until
// the required sysfs/device paths are available before workloads use them.
func (m *Manager) addGuestVPCIDevice(ctx context.Context, vmBusGUID string) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really a guest Add? It seems like it's a "wait guest ready"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants