Skip to content

qemu: build using --enable-linux-user fails #665

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

Open
luigix25 opened this issue Apr 7, 2025 · 5 comments
Open

qemu: build using --enable-linux-user fails #665

luigix25 opened this issue Apr 7, 2025 · 5 comments

Comments

@luigix25
Copy link

luigix25 commented Apr 7, 2025

This is due to commit coconut-svsm/qemu@06c0498. It includes confidential-guest-support.h that is included only if CONFIG_USER_ONLY is undefined. Reverting that commit fixes the issue.

@stefano-garzarella
Copy link
Member

The patch attached here should fix the issue, but maybe @kraxel wanted to enable it independently of CONFIG_SEV. Should we take confidential-guest.c out of CONFIG_SEV?

diff --git a/target/i386/meson.build b/target/i386/meson.build
index d13392498a..d2021b83b7 100644
--- a/target/i386/meson.build
+++ b/target/i386/meson.build
@@ -5,9 +5,8 @@ i386_ss.add(files(
   'helper.c',
   'xsave_helper.c',
   'cpu-dump.c',
-  'nocc.c',
 ))
-i386_ss.add(when: 'CONFIG_SEV', if_true: files('host-cpu.c', 'confidential-guest.c'))
+i386_ss.add(when: 'CONFIG_SEV', if_true: files('host-cpu.c', 'confidential-guest.c', 'nocc.c'))
 
 # x86 cpu type
 i386_ss.add(when: 'CONFIG_KVM', if_true: files('host-cpu.c'))

@kraxel
Copy link
Contributor

kraxel commented Apr 8, 2025

The patch attached here should fix the issue, but maybe @kraxel wanted to enable it independently of CONFIG_SEV.

That was the idea, yes. Although enabling it for *-user targets doesn't make much sense. Make it depend on sysemu instead?

Should we take confidential-guest.c out of CONFIG_SEV?

Either that, or reorganize the code (for example move into the igvm backend) so native mode does not require confidential-guest.c in the first place. Having a "nocc" backend for "cc" is a bit awkward anyway, even though that was the easiest way to wire up things quickly to experiment with native mode IGVM files.

@stefano-garzarella
Copy link
Member

The patch attached here should fix the issue, but maybe @kraxel wanted to enable it independently of CONFIG_SEV.

That was the idea, yes. Although enabling it for *-user targets doesn't make much sense. Make it depend on sysemu instead?

Yeah, honestly, I didn't get why confidential-guest.c is added to i386_ss instead of i386_system_ss.

Should we take confidential-guest.c out of CONFIG_SEV?

Either that, or reorganize the code (for example move into the igvm backend) so native mode does not require confidential-guest.c in the first place. Having a "nocc" backend for "cc" is a bit awkward anyway, even though that was the easiest way to wire up things quickly to experiment with native mode IGVM files.

Yeah, I saw it was WIP, so I agree that for the final solution we can reorganize it.
Should I send #665 (comment) in our fork as temp solution, or do you prefer to reorganize the code?

@kraxel
Copy link
Contributor

kraxel commented Apr 8, 2025

Yeah, I saw it was WIP, so I agree that for the final solution we can reorganize it. Should I send #665 (comment) in our fork as temp solution, or do you prefer to reorganize the code?

I think moving it to CONFIG_SEV as temporary stopgap is fine.

stefano-garzarella added a commit to stefano-garzarella/qemu that referenced this issue Apr 8, 2025
This is a temporary workaround to avoid a build problem with qemu-user
since nocc.c depends on confidential-guest.c.

In the long run we will reorganize the code to avoid the dependency and
compile nocc.c without CONFIG_SEV.

Reported-by: Luigi Leonardi <[email protected]>
Closes: coconut-svsm/svsm#665
Fixes: 06c0498 ("load state from igvm for non-cc VMs")
Signed-off-by: Stefano Garzarella <[email protected]>
@stefano-garzarella
Copy link
Member

Yeah, I saw it was WIP, so I agree that for the final solution we can reorganize it. Should I send #665 (comment) in our fork as temp solution, or do you prefer to reorganize the code?

I think moving it to CONFIG_SEV as temporary stopgap is fine.

done here: coconut-svsm/qemu#20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants