Support assigning devices into LCOW #1215
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Kathryn Baldauf <[email protected]>
dcantah
reviewed
Nov 19, 2021
Comment on lines
+34
to
+46
| case vpciDeviceIDTypeLegacy, vpciDeviceIDType: | ||
| // validate that the device is ready | ||
| fullPCIPath, err := pci.FindDeviceFullPath(ctx, d.ID) | ||
| if err != nil { | ||
| return errors.Wrapf(err, "failed to find device pci path for device %v", d) | ||
| } | ||
| // find the device node that links to the pci path we just got | ||
| dev, err := devicePathFromPCIPath(fullPCIPath) | ||
| if err != nil { | ||
| return errors.Wrapf(err, "failed to find dev node for device %v", d) | ||
| } | ||
| addLinuxDeviceToSpec(ctx, dev, spec, true) | ||
| } |
There was a problem hiding this comment.
We don't need to handle an invalid device type?
There was a problem hiding this comment.
I suppose at this point we'd already validated it before passing it over to the guest
There was a problem hiding this comment.
Well better question, don't need to handle the gpu case here*?
There was a problem hiding this comment.
No, gpu devices are handled through a different code path, see workload_container.go.
We could add an invalid error here but like you said, it's already validated at this point.
dcantah
reviewed
Nov 19, 2021
dcantah
reviewed
Nov 19, 2021
dcantah
reviewed
Nov 19, 2021
dcantah
reviewed
Nov 19, 2021
dcantah
approved these changes
Nov 19, 2021
anmaxvl
reviewed
Nov 22, 2021
Signed-off-by: Kathryn Baldauf <[email protected]>
katiewasnothere
force-pushed
the
support_lcow_assigned_device
branch
from
7e5350c
to
80376f8
Compare
anmaxvl
approved these changes
Nov 30, 2021
dcantah
approved these changes
Nov 30, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In linux, there is no way to predetermine the dev device path since dev nodes are determined and created by the device driver. As a result, we need to search for the dev node that corresponds with a given device that we've already assigned in with vpci support.
Unfortunately, there is no great way to get the dev node information from the content in the sysfs path for the vmbus instance added for the assigned device, which we can easily determine. One option would be to query linux uevents for device node creation events. However, we determined that route was overly complex for today's needs. Instead, this PR adds simple logic to find pci assigned devices in LCOW and add them to the container spec. This works by first finding the full sysfs path of the vmbus instance and then looping through all /dev devices on the host UVM to find the device that links to that vmbus device.
Signed-off-by: Kathryn Baldauf [email protected]