-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
point kvm/qemu/libkvmi to kvmi-v12 branches #127
base: master
Are you sure you want to change the base?
Conversation
Surprisingly, it's not libkvmi which failed, it's the self tests: https://app.travis-ci.com/github/KVM-VMI/kvm-vmi/builds/239353934#L1105
|
Libvmi compilation failed https://app.travis-ci.com/github/KVM-VMI/kvm-vmi/builds/239413034#L1181
|
e097b00
to
02f54d9
Compare
The build timed out: Looks like building the kernel takes more time than it used to be. now: The build time increased by |
98786ea
to
b3a5096
Compare
|
Something is weird, QEMU tells me |
If both (QEMU, kernel) are built with the same KVM_CAP_INTROSPECTION value, double check that you use the right QEMU (/usr/ vs /usr/local/). |
Ah yes, that was it :) |
@adlazar Any chance you could rebase your libvmi branch on the latest master of libvmi? I tried to do that but I'm getting:
|
Also, is |
First, kvmi-v12 is not a replacement for kvmi-v7 (far from it) :(. It has only basic introspection features. While KVMI_GET_MAX_GFN is one of these, I'm not sure is the proper way to obtain that value. I've used the libvmi commit from kvm-vmi@master as a base (I wasn't sure if upstream was ready for my changes :) ), but the errors are caused by the fact that the wire-protocol changed a bit and it's summarized by this commit message (https://github.com/adlazar/libkvmi/commit/bf95b407c8bdfba07504489603422a68a13012d0). For For libvmi, most of the changes can be done almost automatically (event.common.event -> event.common.hdr.event and any other event.common.X => event.common.ev.X). See https://github.com/adlazar/libvmi/commit/16f7aa4df2bf5c3d4c39522fd195af4ae5b24169 . Also, I've tried to keep the source changes (to libkvmi and libvmi) as small as possible, but to still be able to test the new kernel. |
Done. Waiting for Travis to build it :) |
@tklengyel , not quite, but now I think I've done all the necessarily changes. |
@adlazar LibVMI right now needs to know the max address or have a complete memory map to determine if a requested access is sane or not. I'm not actually sure this is something absolutely necessary, its just been how LibVMI was setup from the start. Right now without it init will completely fail. |
Somehow it wasn't able to start the second playbook:
compared to a normal build
|
It fails on task/vm. I saw an error related to docker on a local run. My guess is that x86_64_defconfig is not enough for docker. |
I'll add support for max address, somehow... |
I tried to rebuild this branch locally with vagrant, and the
I'm running on AMD Ryzen Pro here.
|
Signed-off-by: Adalbert Lazăr <[email protected]>
Signed-off-by: Adalbert Lazăr <[email protected]>
and hope that build time will be smaller Signed-off-by: Adalbert Lazăr <[email protected]>
The test can hang and we want to avoid burning Travis CI credits
So, packer depend on docker, which refuses to start I just tested with So Docker can't start on the KVMi kernel |
Just pushed a fix where we install Packer from the zip archive distributed by packer.io instead of the Debian package |
Yeah, the build is passing ✔️ ❗ |
To get LibVMI working it still needs this: libvmi/libvmi@8d0fabf |
@tklengyel , I thought these two commits fixed the memory size issue: |
Ah, didn't catch those commits. Is the QEMU patch going to work even if the guest is booted with ovmf and there is no e820 map? |
I guess so - https://github.com/KVM-VMI/qemu/blob/kvmi-v12/hw/i386/pc.c#L1160 |
@adlazar is remote mapping no longer available in the 5.15 kernel? |
@tklengyel I believe kvmi-v12 is a subset of kvmi-v7 features to faciliate the review for KVM maintainers. |
I don't know what's the right move here then, I don't see a reason to move to v12 if it has less features. If v12 gets merged to upstream that's a different story, then yes, but with it being out-of-tree just as v7 I would prefer a v7 that's rebased on 5.15 tbh. |
Point QEMU, KVM and libkvmi submodules to kvmi-v12 branches.
kvmi-v12 has less features than kvmi-v7, but it is two bits closer to upstream :)