test_guest_early_printk : test with the kernel in the guest VM

[hector-cao]

right now, we are testing the host kernel
actually, we want to do this test for the guest VM kernel
I propose to fix that by redesigning the test in 2 steps:

• append the wanted kernel commandline in the guest VM
• restart the guest VM

[spmcmillan]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.

A really ugly way is to use qemu-nbd, mount the image, pull out the kernel, unmount the image and use the pulled out kernel...

[fanchen2]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.

We often add "earlyprintk" in kernel cmdline to show more logs when booting, this is an old common function of kernel, which can be token as a common setting, just FYI.

[spmcmillan]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.

We often add "earlyprintk" in kernel cmdline to show more logs when booting, this is an old common function of kernel, which can be token as a common setting, just FYI.

Thanks @fanchen2 , does the existence of this test imply that this has failed for TD in the past?

[hector-cao]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.

A really ugly way is to use qemu-nbd, mount the image, pull out the kernel, unmount the image and use the pulled out kernel...

we designed the tests so that each QEMU machine has its own image layer for its modifications (through overlay mechanism : https://libvirt.org/kbase/backing_chains.html ). So, on top of the original image, each QEMU machine will create an overlay image that sits on top of the original one and all the modifications to the machine will only live in the overlay layer and not go into the original image

[fanchen2]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.

We often add "earlyprintk" in kernel cmdline to show more logs when booting, this is an old common function of kernel, which can be token as a common setting, just FYI.

Thanks @fanchen2 , does the existence of this test imply that this has failed for TD in the past?

The original case is to check if TDVM can boot up with debug=off and earlyprintk, the previous failure is caused by "debug" function, which is not integrated into this software stack. I understand you, we expect earlyprintk works all the time, but on one can ensure it.

[spmcmillan]

This makes sense, however, it changes the image permanently and might affect other tests. Should we go through and modify it back? Though if this test fails, we cannot modify it back. Which is not great.
A really ugly way is to use qemu-nbd, mount the image, pull out the kernel, unmount the image and use the pulled out kernel...

we designed the tests so that each QEMU machine has its own image layer for its modifications (through overlay mechanism : https://libvirt.org/kbase/backing_chains.html ). So, on top of the original image, each QEMU machine will create an overlay image that sits on top of the original one and all the modifications to the machine will only live in the overlay layer and not go into the original image

Good deal. LGTM

[spmcmillan]

LGTM