amdese / qemu Goto Github PK

QEMU fork

License: Other

Emacs Lisp 0.01% GDB 0.01% Makefile 0.24% C 91.35% C++ 2.82% Haxe 0.49% Objective-C 0.24% Assembly 0.45% Python 2.78% NSIS 0.01% Shell 1.31% Prolog 0.03% Perl 0.28% GLSL 0.01%

qemu's People

Contributors

Stargazers

Watchers

qemu's Issues

QEMU not working with virt-install

Hello,

I've been trying to get live migration working on my Dell EMC PowerEdge C6525 machine (with SEV support). I'm running Ubuntu 20.04 on my machine. I found that the stock software (virsh 6.0.0 + QEMU-4.2.1 + Linux v5.4) does not support live migration for my SEV-enabled VM.

I therefore tried to compile and install QEMU from the branch below to my system.
https://github.com/AMDESE/qemu/tree/sev_live_migration_v4_1

After the installation completes, when I create a new SEV-enabled VM using the new QEMU (with virt-install), I kept getting the error below:
"ERROR Host does not support any virtualization options for arch 'x86_64'""

I then tried to install the mainline v5.18 Linux to my Ubuntu 20.04 machine, but the same error still exists.

I wonder if I'm missing something here? Any comments/tips would be much appreciated!

skipping kernel hashes

Is there any SNP-specific reason as to why it wouldn't make sense to have the kernel-loader hashes stored in a measured page?

2b331b9

It makes sense to me to re-use this mechanism implemented for SEV(-ES) even in the context of SEV-SNP. So, I was wondering if I am missing something here.

Thanks a lot for all the effort in upgrading qemu to support SEV-SNP guests!

VerifyBlob: Hash comparison failed for "kernel"

I am trying to use OvmfPkg/AmdSev package, kernel and QEMU from snp-latest branch. It seems that the injected hashes table is broken when kernel-hashes=on, so measured direct kernel boot does not work.

QEMU: https://github.com/AMDESE/qemu.git, 9cb308e
OVMF: https://github.com/AMDESE/ovmf.git, e1a623d4ac86024284c53f7e577b02b45ffb8b2f

OVMF always sees blobs with 48 extra bytes.

BlobVerifierLibSevHashesConstructor: Found injected hashes table in secure location
Select Item: 0x17
Select Item: 0x8
FetchBlob: loading 10580240 bytes for "kernel"
Select Item: 0x18
Select Item: 0x11
VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
VerifyBlob: Hash comparison failed for "kernel"

But:

$ stat -c %s vmlinuz-6.1.0-rc4-amd-95869433e+
10580192

So the size is always larger than the real one: 10580240 - 10580192 = 48.

I have added diagnostics to the OVMF and there are strange things - hashes are always random for the same kernel blob (the first line is a hash passed by QEMU and the second line is a hash calculated by OVMF):

VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
 20 27 4B AB 6D CF AA 28 92 D5 53 20 D8 3A 73 E8 33 38 01 FA 52 81 51 7C DB 3A F8 CA C5 FB C3 F7
 EE 63 AC 7C 10 CF 10 61 13 90 29 A3 F3 77 6A 6A 5C 37 EB 46 37 56 DD BE A0 6F 89 3F A1 B2 80 FF
VerifyBlob: Hash comparison failed for "kernel"

VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
 A7 E2 45 95 38 57 30 03 51 07 11 C2 1D D8 30 33 A3 23 AF 3D 94 59 BB 73 E6 E1 F4 60 BC C1 B8 48
 6F D7 42 CE 69 A1 28 89 7B 23 CE FF 91 34 50 11 A1 F6 CA 47 FA 6F 7C E9 CE 6B 3B 59 0F 0B 86 3F
VerifyBlob: Hash comparison failed for "kernel"

VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
 E2 65 7A B3 A5 50 73 A8 86 FF 36 64 B8 89 97 AA 39 27 97 FE CA 10 0A A2 71 2D 1D C1 AE F4 C9 96
 FD DB F3 A8 DA E0 2E 14 A6 AD 8C 64 EC 70 9A 37 21 B2 F8 A4 4D A0 1B 21 00 F0 39 CE 55 D3 3F F5
VerifyBlob: Hash comparison failed for "kernel"

One more thing - I am not sure that it is related to the issue:

VarCheckLibRegisterSetVariableCheckHandler - 0x3F2CA497 Success
qemu-system-x86_64: warning: Unkonwn start 0xffc01000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc02000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc03000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc04000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc05000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc06000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc07000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc08000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc09000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0a000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0b000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0c000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0d000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0e000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc0f000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc10000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc11000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc12000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc13000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc14000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc15000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc16000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc17000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc18000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc19000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1a000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1b000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1c000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1d000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1e000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc1f000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc20000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc21000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc22000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc23000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc24000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc25000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc26000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc27000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc28000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc29000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2a000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2b000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2c000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2d000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2e000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc2f000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc30000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc31000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc32000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc33000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc34000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc35000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc36000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc37000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc38000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc39000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3a000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3b000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3c000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3d000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3e000 size 0x1000 shared_to_private 0
qemu-system-x86_64: warning: Unkonwn start 0xffc3f000 size 0x1000 shared_to_private 0
Variable driver common space: 0x3FF9C 0x3FF9C 0x3FF9C
Variable driver will work with auth variable format!

QEMU cmdline is pretty default:

/home/p2pcloud/src/AMDSEV/usr/local/bin/qemu-system-x86_64 -enable-kvm -cpu EPYC-v4 -machine q35 -smp 4,maxcpus=64 -m 2048M,slots=5,maxmem=30G -no-reboot -drive if=pflash,format=raw,unit=0,file=/home/p2pcloud/src/AMDSEV/OVMF_CODE.fd,readonly -drive if=pflash,format=raw,unit=1,file=/home/p2pcloud/src/AMDSEV/disk.fd -drive file=/home/p2pcloud/src/AMDSEV/disk,if=none,id=disk0,format=raw -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true -device scsi-hd,drive=disk0 -machine memory-encryption=sev0,vmport=off -object memory-backend-memfd-private,id=ram1,size=2048M,share=true -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,discard=none,kernel-hashes=on -machine memory-backend=ram1,kvm-type=protected -kernel /home/p2pcloud/src/p2pcloud/builders/heartbeat/kernel -append "console=ttyS0 earlyprintk=serial root=/dev/sda2" -nographic -monitor pty -monitor unix:monitor,server,nowait -global isa-debugcon.iobase=0x402 -debugcon /dev/stdout

SEV VM Live Migration not working: Seeking updates and roadmap plans

Hello,

I am reaching out regarding the Live Migration feature of a SEV VM on SEV enabled machines. I have been able to successfully boot up SEV, SEV-ES, and SEV-SNP guest VMs using branch snp-v3, but unfortunately, I am unable to perform Live Migration for these SEV VMs.

I understand from issue #3 that Live Migration is currently not supported for SEV VMs. As such, I am writing to inquire about the latest development progress on this feature. If there are any updates or if Live Migration support has been added to the roadmap, I would greatly appreciate any information you could provide.

Thank you in advance for your assistance.

QEMU crashes after launching a SNP-enabled guest with TAP

Hi there,
I'm getting Bus Error from QEMU on branch snp-v3. The following is the command I used to launch QEMU
qemu-system-x86_64 -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 -machine memory-encryption=sev0,vmport=off -enable-kvm -machine q35 -cpu EPYC-v4 -smp 4 -m 8G,maxmem=32G,slots=10 -global driver=cfi.pflash01,property=secure,value=on -drive file=$HOME/AMDSEV/snp-release-2022-07-15/usr/local/share/qemu/OVMF_CODE.fd,index=0,if=pflash,format=raw,readonly -drive file=$HOME/AMDSEV/snp-release-2022-07-15/usr/local/share/qemu/OVMF_VARS.fd,index=1,if=pflash,format=raw -drive file=$HOME/$hda,format=qcow2,index=0,media=disk -netdev tap,id=hostnet1,ifname=tap1,script=$HOME/qemu-ifup,downscript=no -device e1000,netdev=hostnet1,id=net1,addr=0x5,mac=52:54:00:6a:5e:61 -vnc 0.0.0.0:9 -serial telnet::4559,server,nowait -monitor stdio
Inside tap script qemu-ifup:

#!/bin/sh
set -x

switch=virbr0

if [ -n "$1" ];then
        #tunctl -u `whoami` -t $1
        ip tuntap add $1 mode tap user `whoami`
        ip link set $1 up
        sleep 0.5s
        #brctl addif $switch $1
        ip link set $1 master $switch
        exit 0
else
        echo "Error: no interface specified"
        exit 1
fi

There's no such issue with sev-guest. For sev-snp-guest, if I change the network type to user, then QEMU is working properly. How can I fix this?

ReducedPhysBits value

Hi there,
there is an ongoing discussion in the Kata Containers project PR #5007 about the value of the field reduced-phys-bits for SEV-SNP VMs passed to QEMU via the command line.

We established that host and guest reduced physical address bits are to be treated separately, the host's address space is generally reduced by 5 on Epyc Milan platforms, while the guest's address space is always reduced by 1 for now (see Manual Vol. 2, section 15.34.6).

In the QEMU snp-v3 code, this value is at times hardcoded, like here:

SevCapability *
sev_get_capabilities(Error **errp)
{
...
    /*
     * When SEV feature is enabled, we loose one bit in guest physical
     * addressing.
     */
    cap->reduced_phys_bits = 1;

but can also be provided through the command line by adding reduced-phys-bits=... to the sev-snp-guest object, which is the value used when initializing the VM.

The documentation, however, states the following:

   When memory encryption is enabled, we loose certain bits in
   physical address space. The ``reduced-phys-bits`` is used to
   provide the number of bits we loose in physical address space.
   Similar to C-bit, the value is Host family dependent. On EPYC,
   the value should be 5.

Furthermore, I noticed the following behaviour.

SEV-VMs allow a range from reduced-phys-bits=1-(2^32-1)
SNP-VMs allow a range from reduced-phys-bits=1-319

Inside the guest, the value is always the same as the specified value up until 63, after that it stays cropped at 63, probably because of some bit mask for the 6-bit field somewhere. I concluded that value is not used inside the guest for now since it has no apparent impact. The field is set in the current QEMU code as follows:

    case 0x8000001F:
        *eax = sev_enabled() ? 0x2 : 0;
        *eax |= sev_es_enabled() ? 0x8 : 0;
        *eax |= sev_snp_enabled() ? 0x10 : 0;
        *ebx = sev_get_cbit_position();
        *ebx |= sev_get_reduced_phys_bits() << 6;
        *ecx = 0;
        *edx = 0;
        break;

This is the CPUID definition in AMD's manual Vol. 3, section E.4.17 :

CPUID Fn8000_001F_EBX Secure Encryption

Bits Field Name Description

31:16 — Reserved.

15:12 NumVMPL Number of VM Permission Levels supported

11:6 PhysAddrReduction Physical Address bit reduction

5:0 CbitPosition C-bit location in page table

Bits	Field Name Description
31:16	— Reserved.
15:12	NumVMPL Number of VM Permission Levels supported
11:6	PhysAddrReduction Physical Address bit reduction
5:0	CbitPosition C-bit location in page table

To me, it looks like the SNP-specific QEMU version should probably be updated to

contain up-to-date information on the reduced-phys-bits field and its impact
would benefit from not using both hard-coded values and user-specified values or at least explicitly state why this is done in each case (if the value is always 1 for now, is an extra field for the command line even necessary or can it be omitted until that changes?)
have some sort of (unified) verification of the input value since right now I can start an SEV-VM with reduced-phys-bits=4294967295 but "only" boot SNP-VMS with up to reduced-phys-bits=319, (which might have to do with 4.) and
probably use a bit mask when setting the ebx field for the reduced bits in the above CPU code since right now this overwrites all higher fields if I am not mistaken which could cause issues if these fields are used

I don't know if this is the best place to start this conversation or if there are mailing lists more suited for this, let me know if there is a better way. I am happy to hear your thoughts or be corrected in case I got anything wrong.

libvirt triggering qemu segfault

I am experiencing an issue where libvirt triggering qemu results in a segfault. When I try to start an SNP-enabled VM using libvirt, the startup fails. After checking the dmesg logs, I found that qemu experienced a segfault.

[ 8418.356520] qemu-system-i38[74529]: segfault at 0 ip 0000563b14cfeb97 sp 00007fffbe91dfe0 error 4 in qemu-system-i386[563b1491e000+571000] likely on CPU 1 (core 1, socket 0)
[ 8418.356543] Code: 83 c4 08 48 89 de 5b 5d e9 c6 4b c2 ff 66 0f 1f 44 00 00 f3 0f 1e fa 41 55 49 89 d5 41 54 49 89 f4 55 48 89 fd 53 48 83 ec 08 <48> 8b 3f e8 31 fe ff ff 48 89 c3 48 85 c0 74 11 48 83 c4 08 48 89
[ 8418.872872] qemu-system-x86[74541]: segfault at 0 ip 000055aec7deca87 sp 00007ffed953e900 error 4 in qemu-system-x86_64[55aec79c7000+5de000] likely on CPU 1 (core 1, socket 0)
[ 8418.872893] Code: 83 c4 08 48 89 de 5b 5d e9 26 15 be ff 66 0f 1f 44 00 00 f3 0f 1e fa 41 55 49 89 d5 41 54 49 89 f4 55 48 89 fd 53 48 83 ec 08 <48> 8b 3f e8 31 fe ff ff 48 89 c3 48 85 c0 74 11 48 83 c4 08 48

According to the libvirt logs, the qemu monitor connection got disconnected right after executing the 'query-sev-capabilities' command.

Jul 26 08:21:21 ubuntu libvirtd[134476]: QEMU_MONITOR_SEND_MSG: mon=0x7fc47800a460 msg={"execute":"query-sev-capabilities","id":"libvirt-44"}
                                          fd=-1
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: QEMU_MONITOR_IO_WRITE: mon=0x7fc47800a460 buf={"execute":"query-sev-capabilities","id":"libvirt-44"}
                                          len=56 ret=56 errno=0
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_UNREF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_UNREF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: Unable to read from monitor: Connection reset by peer
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_UNREF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_UNREF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: OBJECT_REF: obj=0x7fc47800a460
Jul 26 08:21:21 ubuntu libvirtd[134476]: Failed to probe capabilities for /usr/local/bin/qemu-system-i386: Unable to read from monitor: Connection reset by peer

However, I could not reproduce this behavior on VMs that were started using the launch_qemu script. Upon investigating the libvirt qemu startup command, I discovered that libvirt would start a non-SNP enabled VM first to perform some checks, and it was during this process that qemu crashed.

/usr/local/bin/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -qmp unix:/var/lib/libvirt/qemu/qmp-JQ5G81/qmp.monitor,server=on,wait=off -pidfile /var/lib/libvirt/qemu/qmp-JQ5G81/qmp.pid -daemonize

By using gdb to obtain the call stack and based on the location of the error, I tried out a possible fix qemu/11which successfully started the SNP-enabled VM.

Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
object_property_find_err (obj=0x0, name=0x555555f5089f "sev-device", errp=0x5555566d24a0 <error_abort>) at ../qom/object.c:1312
1312        ObjectProperty *prop = object_property_find(obj, name);
(gdb) where
#0  object_property_find_err
    (obj=0x0, name=0x555555f5089f "sev-device", errp=0x5555566d24a0 <error_abort>) at ../qom/object.c:1312
#1  0x0000555555c7c08a in object_property_get
    (obj=obj@entry=0x0, name=name@entry=0x555555f5089f "sev-device", v=v@entry=0x5555569c4c10, errp=errp@entry=0x5555566d24a0 <error_abort>)
    at ../qom/object.c:1389
#2  0x0000555555c7f6b0 in object_property_get_qobject
    (obj=obj@entry=0x0, name=name@entry=0x555555f5089f "sev-device", errp=errp@entry=0x5555566d24a0 <error_abort>) at ../qom/qom-qobject.c:40
#3  0x0000555555c7c6e7 in object_property_get_str
    (obj=obj@entry=0x0, name=name@entry=0x555555f5089f "sev-device", errp=0x5555566d24a0 <error_abort>) at ../qom/object.c:1437
#4  0x0000555555ab8bef in sev_get_capabilities (errp=0x7fffffffdbf8)
    at ../target/i386/sev.c:1009
#5  qmp_query_sev_capabilities (errp=errp@entry=0x7fffffffdbf8)
    at ../target/i386/sev.c:1053
#6  0x0000555555c6f735 in qmp_marshal_query_sev_capabilities
    (args=<optimized out>, ret=0x7ffff5ea6e98, errp=0x7ffff5ea6e90)
    at qapi/qapi-commands-misc-target.c:236
#7  0x0000555555ddd2ad in do_qmp_dispatch_bh (opaque=0x7ffff5ea6ea0)
    at ../qapi/qmp-dispatch.c:128
#8  0x0000555555dfc135 in aio_bh_call (bh=0x5555569c1f10)
    at ../util/async.c:155
#9  aio_bh_poll (ctx=ctx@entry=0x55555676a7d0) at ../util/async.c:184
#10 0x0000555555de6ee2 in aio_dispatch (ctx=0x55555676a7d0)
    at ../util/aio-posix.c:421
#11 0x0000555555dfbd92 in aio_ctx_dispatch
    (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:326
#12 0x00007ffff7952569 in g_main_context_dispatch ()
    at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x0000555555dfd6f8 in glib_pollfds_poll ()
    at ../util/main-loop.c:290
#14 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
#15 main_loop_wait (nonblocking=nonblocking@entry=0)
    at ../util/main-loop.c:592
#16 0x0000555555a417e3 in qemu_main_loop ()
    at ../softmmu/runstate.c:731
#17 0x00005555558630da in qemu_default_main () at ../softmmu/main.c:37
#18 0x00007ffff7423510 in __libc_start_call_main
     (main=main@entry=0x55555585e220 <main>, argc=argc@entry=11, argv=argv@entry=0x7fffffffdf68) at ../sysdeps/nptl/libc_start_call_main.h:58
#19 0x00007ffff74235c9 in __libc_start_main_impl
     (main=0x55555585e220 <main>, argc=11, argv=0x7fffffffdf68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdf58) at ../csu/libc-start.c:381
#20 0x0000555555863005 in _start ()

undefined reference to `kvm_has_restricted_memory'

Hi there,

I'm trying to build snp-latest branch and is getting the following error

FAILED: qemu-system-aarch64 
c++ -m64 -mcx16 @qemu-system-aarch64.rsp
/usr/bin/ld: libqemu-aarch64-softmmu.fa.p/softmmu_memory.c.o: in function `memory_region_init_ram':
/root/qemu/build/../softmmu/memory.c:3619: undefined reference to `kvm_has_restricted_memory'
/usr/bin/ld: libqemu-aarch64-softmmu.fa.p/softmmu_memory.c.o: in function `memory_region_init_rom_device':
/root/qemu/build/../softmmu/memory.c:3702: undefined reference to `kvm_has_restricted_memory'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
make: *** [Makefile:165: run-ninja] Error 1

I'm using a system similar to CentOS 9, GCC version is 11.3.1, is there any dependency I should install, or any compiler flag I need to set?

How to set `host_data` properly in QEMU

Hi there, I'm trying to set host data on snp-v3 branch. I included the following in my QEMU command -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,host-data=b2l3bmNvd3FuY21wbXA. Both guest and host kernels were from here, and I could get a guest report using sev-guest. While I can set Report Data with sev-guest-get-report, Host data is still blank no matter what I passed to QEMU.
The following is the guest report I got with the Makefile in sev-guest used in hashing

[sev-guest]root@localhost# ./sev-guest-parse-report guest_report.bin                                          
Version: 2
Guest SVN: 0
Policy: 0xb0000
 - Debugging Allowed:       Yes
 - Migration Agent Allowed: No
 - SMT Allowed:             Yes
 - Min. ABI Major:          0
 - Min. ABI Minor:          0
Family ID:
    00000000000000000000000000000000
Image ID:
    00000000000000000000000000000000
VMPL: 0
Signature Algorithm: 1 (Invalid)
Platform Version: 03000000000008115
 - Boot Loader SVN:   3
 - TEE SVN:           0
 - SNP firmware SVN:  8
 - Microcode SVN:    115
Platform Info: 0x1
- SMT Enabled: Yes 
Author Key Enabled: Yes
Report Data:
    31bf7d4a0a9abf65d5184e53531661b8d67a83f2787a3e1a6bbe32fb235a158d
    a4daf7a92c20cc3ba538668c81b3519d6d0a07cae726a9694e30440b74cdf75b
Measurement:
    8b988c46fcc74422bce82fb42a481821ccc4dd667e5eb687
    328901e228009547340957823e0c4f96891d5cb5d0f996bc
Host Data:
    0000000000000000000000000000000000000000000000000000000000000000
ID Key Digest:
    000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000
Author Key Digest:
    000000000000000000000000000000000000000000000000
    000000000000000000000000000000000000000000000000
Report ID:
    755ce22a77ba7d7ec99d6d904c7b15f71f2addcd34bf96ba6150a67409f1c0a5
Migration Agent Report ID:
    ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Reported TCB: 03000000000008115
 - Boot Loader SVN:   3
 - TEE SVN:           0
 - SNP firmware SVN:  8
 - Microcode SVN:    115
Chip ID:
    c2a6528b7364e07e9f5c653ab3aa0dbd7384f9a80dfde54cc643ddbb89d89364
    25ff8a32568ca6ed771020dc39c33ccffb3b43cac0c501a0093cad6012dfd3ed
Signature:
  R:
    5068cb59b7dcbb3388594538b447b1dbd6396832395ad5bba3719c225e3839da3b98ed4c
    f3bca287f2a7abd7ea509595000000000000000000000000000000000000000000000000
  S:
    d7ffd39755b8fb1d3da4496d24ddcfcaf97d18bdc8ad5fc96b83d84f1c830e364f5aaa7f
    bc99a52233aa0ea03a026533000000000000000000000000000000000000000000000000

Please advise

amdese / qemu Goto Github PK

qemu's People

Contributors

Stargazers

Watchers

Forkers

qemu's Issues

QEMU not working with virt-install

skipping kernel hashes

VerifyBlob: Hash comparison failed for "kernel"

SEV VM Live Migration not working: Seeking updates and roadmap plans

QEMU crashes after launching a SNP-enabled guest with TAP

ReducedPhysBits value

CPUID Fn8000_001F_EBX Secure Encryption

libvirt triggering qemu segfault

undefined reference to `kvm_has_restricted_memory'

How to set `host_data` properly in QEMU

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent