-
Notifications
You must be signed in to change notification settings - Fork 374
Firecracker: virtio mmio support #1045
Firecracker: virtio mmio support #1045
Conversation
virtcontainers/kata_agent.go
Outdated
@@ -831,7 +832,10 @@ func (k *kataAgent) appendDevices(deviceList []*grpc.Device, c *Container) []*gr | |||
ContainerPath: dev.ContainerPath, | |||
} | |||
|
|||
if d.SCSIAddr == "" { | |||
if d.VirtPath != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open for suggestions here on how to figure out the actual type. Today we have no top level type information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I agree the if/else here looks flaky.
I think one approach would be to add a field Type
to the BlockDrive
structure. This way, we could factorize both VirtPath
, SCSIAddr
and PCIAddr
into one unique field Dest
(or similar) to describe how to identify the device from the guest side. The Type
field would be used to know how to actually decipher the Dest
field.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has been fixed by deriving the information directly.
/test |
c68642a
to
9684ef2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments but globally LGTM
virtcontainers/kata_agent.go
Outdated
@@ -831,7 +832,10 @@ func (k *kataAgent) appendDevices(deviceList []*grpc.Device, c *Container) []*gr | |||
ContainerPath: dev.ContainerPath, | |||
} | |||
|
|||
if d.SCSIAddr == "" { | |||
if d.VirtPath != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I agree the if/else here looks flaky.
I think one approach would be to add a field Type
to the BlockDrive
structure. This way, we could factorize both VirtPath
, SCSIAddr
and PCIAddr
into one unique field Dest
(or similar) to describe how to identify the device from the guest side. The Type
field would be used to know how to actually decipher the Dest
field.
/test |
/retest |
@sboeuf identified issue here. PTAL @mcastelino : mcastelino@30d2279 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see above comment, and fix @ mcastelino@30d2279
a856de3
to
e340395
Compare
/test |
@egernst @sboeuf @jodh-intel all the review comments should have been addressed. Can you you review/merge. |
@mcastelino looks fine, but you need to fix the CI checks. |
@egernst @ mcastelino/runtime-1@30d2279 is not needed as we can always use virtPath. Now the flow is uniform across volumes and block devices as it should have been. |
e340395
to
027340f
Compare
This change is no longer needed as we can use virtPath vs mmioaddr
/test |
/test |
globalIdx = index + 1 | ||
} | ||
|
||
driveName, err := utils.GetVirtDriveName(globalIdx) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amshinde I'm wondering if we still rely on GetVirtDriveName
for virtio-blk
device identification? I thought we now use pci address for them. Then at least GetVirtDriveName
is not needed for virtio-blk
. We can still keep it for virtio-mmio
. In future we might want to replace it with disk UUID though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @bergwolf
Overall it LGTM
Thanks @mcastelino ! lgtm |
/retest |
Just so we don't try to test and retest, here are some consistent failures due to this patch:
I'm trying to figure out what's wrong here. |
@mcastelino after more investigations, I found that the failing tests were related to some of our Docker integration tests testing |
027340f
to
676b820
Compare
@sboeuf I have pulled in the commit into this PR |
/test |
410b69c
to
e889bb7
Compare
/test |
e889bb7
to
84a3ee9
Compare
/test |
Start adding support for virtio-mmio devices starting with block. The devices show within the vm as vda, vdb,... based on order of insertion and such within the VM resemble virtio-blk devices. They need to be explicitly differentiated to ensure that the agent logic within the VM can discover and mount them appropropriately. The agent uses PCI location to discover them for virtio-blk. For virtio-mmio we need to use the predicted device name for now. Note: Kata used a disk for the VM rootfs in the case of Firecracker. (Instead of initrd or virtual-nvdimm). The Kata code today does not handle this case properly. For now as Firecracker is the only Hypervisor in Kata that uses virtio-mmio directly offset the drive index to comprehend this. Longer term we should track if the rootfs is setup as a block device explicitly. Fixes: kata-containers#1046 Signed-off-by: Sebastien Boeuf <[email protected]> Signed-off-by: Manohar Castelino <[email protected]>
a7b77a8
to
0d84d79
Compare
/test |
Except @bergwolf 's comment, other parts |
Add support for virtio-mmio block devices. Firecracker only support virtio-mmio.
Note: Add a firecracker specific workaround to handle the fact that rootfs of the VM itself is also sent in as block device.