Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

updateInterface: enable hot-add nic on arm64 #545

Merged
merged 1 commit into from
May 20, 2019

Conversation

jongwu
Copy link
Contributor

@jongwu jongwu commented Apr 30, 2019

For now, update interface in agent will fail when hot-add
nic to a running containers on arm64 as rescan pci bus will
occur between uf and bf of shpc hotplug interrupt handling.

Another problem is that the rootBusPath will be
"/devices/platform/4010000000.pcie/pci0000:00" on arm64.

To enable hot-add nic on arm64, rootBusPath should be changed here
and shpc hotplug should be disabled in guest kernel.

This patch just change rootBusPath.

Fixes: #544
Signed-off-by: Jianyong Wu [email protected]

@bergwolf @jodh-intel @teawater @Pennyzct

device_amd64.go Outdated

var pciBusRescanFile = sysfsDir + "/bus/pci/rescan"

func rescanPciBus() error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since hot-add differs only on ARM, how about keeping the new files (device_amd64.go, device_s390x.go, etc), but having all non-ARM implementations call a generic handler like this:

func rescanPciBus() error {
    return genericRescanPCIBus()
}

That would avoid the duplication.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jodh-intel thanks, if the implementation for rescanPciBus contains many lines of code, it is better to package them. but for only one line, keep it maybe better, as I fear of that more function call need more stack context switch which may be harmful to performance.

@teawater
Copy link
Member

teawater commented May 1, 2019

/test

@grahamwhaley grahamwhaley requested a review from devimc May 3, 2019 15:52
@jongwu
Copy link
Contributor Author

jongwu commented May 6, 2019

@teawater @bergwolf any comments?

@jongwu
Copy link
Contributor Author

jongwu commented May 8, 2019

could someone help me retrigger test?

@grahamwhaley
Copy link
Contributor

/test
sure

@Pennyzct
Copy link
Contributor

Pennyzct commented May 8, 2019

Hi~ @grahamwhaley could we add ARM CI machine here?? ;)

@grahamwhaley
Copy link
Contributor

@Pennyzct - I expect so. If you are confident it is stable enough, then I don't think anybody will object. The only 'rule' I try to lay down is that if it becomes unstable and starts to block PRs, and is not fixed in a reasonable time, then we may disable it again :-)
@chavafg - you OK with this?
So, @Pennyzct - we are also always looking for other members of the community to become helpers with the CI in general - would you like more access to the Jenkins master machine to help us with that? We should also discuss that ;-)

@jodh-intel
Copy link
Contributor

@grahamwhaley - could you add those CI arch requirements maybe to https://github.com/kata-containers/ci/blob/master/README.md?

@grahamwhaley
Copy link
Contributor

@jodh-intel - sure, I opened kata-containers/ci#156 as a starter.

@chavafg
Copy link
Contributor

chavafg commented May 8, 2019

I agree we can add the arm job to the agent repo.

Copy link
Contributor

@jodh-intel jodh-intel left a comment

Choose a reason for hiding this comment

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

I'm not a fan of duplication, but this "1-liner duplication" can always be refactored in a follow-up PR I guess.

Thanks for dealing with all the architectures here by the way too.

@jodh-intel
Copy link
Contributor

/test

@jongwu
Copy link
Contributor Author

jongwu commented May 13, 2019

@jodh-intel yeah, code duplication is not a good code style.

@jongwu
Copy link
Contributor Author

jongwu commented May 14, 2019

@grahamwhaley @bergwolf any comments?

@grahamwhaley
Copy link
Contributor

np from me. I'd quite like to hear from @devimc on it for the pci/hotplug stuff.
I nudged a rebuild of the jenkins-vsock - the only one failing, and I think that was a generic issue I'm hoping we fixed overnight...

@jongwu
Copy link
Contributor Author

jongwu commented May 14, 2019

@grahamwhaley thanks.

@@ -0,0 +1,11 @@
//
// Copyright (c) 2019 Intel Corporation
Copy link
Member

Choose a reason for hiding this comment

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

This is probably a wrong header

@@ -0,0 +1,11 @@
//
// Copyright (c) 2019 Intel Corporation
Copy link
Member

Choose a reason for hiding this comment

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

ARM Limited?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jcvenegas I'm confused with these copyright header, those no-arm64 code are all copy from the original file with Intel header. so I'm not sure how to write these header. @jodh-intel @grahamwhaley @bergwolf any idea?

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for raising this issue @jongwu! I agree that this is confusing, so we need to document this. IANAL so will need to get input from folks more knowledgeable in that area. Since this file is based on an existing one, I would think it is "safe" to always reference the original copyright as well (so that you could list both Intel and ARM for 2019).

@grahamwhaley - any thoughts on this? I'm happy to write it up once we have clarity on this subtle area.

As to a location for where to put the words.. I think it would either need to go in:

Wherever it goes, it needs to cover the following copyright scenarios:

  • Adding a new source file.
  • Adding a new source file which is similar to an existing file:
    • Exact copy but for different arch (covering both a tiny fragment (like on this PR) and also a very large and complex file).
    • "Based on" an existing file but with potentially extensive modifications.
  • ... ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @jodh-intel, it is very helpful for me. If I get it right, the copyright header for device_amd64.go, device_ppc64le.go and device_s390x.go should include both intel and ARM. Is that right?
If that is the truth, what's the shape of these header? eg. it should be "Intel Corporation and ARM limited" or "Intel Corporation && ARM limited" or something else?

Copy link
Contributor

Choose a reason for hiding this comment

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

afaik, you would put your new addition copyright on a new line, so like:

//
// Copyright (c) 2018 Intel Corporation
// Copyright (c) 2019 <your company/person name here>
//
// SPDX-License-Identifier: Apache-2.0
//

and replace your company etc. :-)

Copy link
Contributor

Choose a reason for hiding this comment

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

I should probably note - your company may have its own ideas, rules or specific name/format for this btw, and you might want to check internally first.

Copy link
Contributor

Choose a reason for hiding this comment

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

// Copyright (c) 2019 ARM Limited
//
// SPDX-License-Identifier: Apache-2.0
//
plz use this. ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @grahamwhaley

For now, update interface in agent will fail when hot-add
nic to a running containers on arm64 as rescan pci bus will
occur between uf and bf of shpc hotplug interrupt handling.

Another problem is that the rootBusPath will be
"/devices/platform/4010000000.pcie/pci0000:00" on arm64.

To enable hot-add nic on arm64, rootBusPath should be changed here
and shpc hotplug should be disabled in guest kernel.

This patch just change rootBusPath.

Fixes: kata-containers#544
Signed-off-by: Jianyong Wu <[email protected]>
@Pennyzct
Copy link
Contributor

Hi~ @grahamwhaley
Sorry for the delayed response about adding ARM CI machines on agent repo.
I got sidetracked for a few other issues. 😥
For now, there could only be me full-time dedicated to the ARM CI maintenance, in the future, there may be more arm folks.;) So if anytime ARM CI blocks PR here and doesn't get fixed for a quite time, you sure could bring it down.😄
And I'm very happy to become helpers with the CI community and have more access to the Jenkins master machine to help you guys.
So All in all, let's bring ARM CI online agent repo. ;)

@grahamwhaley
Copy link
Contributor

@Pennyzct - as long as we are happy we have the capacity (as discussed on other Issue), sure - @chavafg maybe we should first add @Pennyzct to the Jenkins master as admin, and then guide on how to add (clone/edit) a new job... thx!

@jongwu
Copy link
Contributor Author

jongwu commented May 17, 2019

@devimc any comments?

@devimc
Copy link

devimc commented May 17, 2019

/test

@teawater teawater merged commit 065b34d into kata-containers:master May 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

updateInterface: fail to hot-add nic to container on arm64
8 participants