[libvirt][PATCH RESEND v10 5/5] qemu: Add command-line to generate SGX EPC memory backend

Yang, Lin A lin.a.yang at intel.com
Thu Feb 24 20:19:00 UTC 2022


On 2/22/22, 1:19 AM, "Michal Prívozník" <mprivozn at redhat.com> wrote:

> On 2/16/22 11:25, Michal Prívozník wrote:
>
> >> diff --git a/tests/qemuxml2argvdata/sgx-epc.x86_64-6.2.0.args b/tests/qemuxml2argvdata/sgx-epc.x86_64-6.2.0.args
> >> new file mode 100644
> >> index 0000000000..e1aa274054
> >> --- /dev/null
> >> +++ b/tests/qemuxml2argvdata/sgx-epc.x86_64-6.2.0.args
> >> @@ -0,0 +1,38 @@
> >> +LC_ALL=C \
> >> +PATH=/bin \
> >> +HOME=/tmp/lib/domain--1-QEMUGuest1 \
> >> +USER=test \
> >> +LOGNAME=test \
> >> +XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \
> >> +XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \
> >> +XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
> >> +/usr/bin/qemu-system-x86_64 \
> >> +-name guest=QEMUGuest1,debug-threads=on \
> >> +-S \
> >> +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-QEMUGuest1/master-key.aes"}' \
> >> +-machine pc-q35-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \
> >> +-accel tcg \
> >> +-cpu qemu64 \
> >> +-m 134 \
> >> +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":140509184}' \
> >> +-overcommit mem-lock=off \
> >> +-smp 1,sockets=1,cores=1,threads=1 \
> >> +-object '{"qom-type":"memory-backend-epc","id":"memepc0","prealloc":true,"size":67108864}' \
> >> +-object '{"qom-type":"memory-backend-epc","id":"memepc1","prealloc":true,"size":16777216}' \
> >> +-M sgx-epc.0.memdev=memepc0,sgx-epc.1.memdev=memepc1 \
> >
> > I don't think this is correct. IIUC, this can be passed to -machine
> > directly, e.g.:
> >
> > -machine
> > pc-q35-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram,sgx-epc.0.memdev=memepc0,sgx-epc.1.memdev=memepc1
> >
> > And when I try to do that, I get:
> >
> >   qemu-system-x86_64: Parameter 'sgx-epc.0.node' is missing
> >
> > Any idea, what's going on? I would much rather avoid using -M if we can
> > help it.
> >
>
> One more thing. I've enabled SGX on my machine hoping to test this out,
> but my attempts are failing so far. Firstly, with these patches qemu is
> unhappy, because .node attribute is missing:
>
> /home/zippy/work/qemu/qemu.git/build/qemu-system-x86_64 \
>
> -machine pc-i440fx-4.0,usb=off,dump-guest-core=off \
> -accel kvm \
> -cpu host,migratable=on \
> -m size=4194304k,slots=16,maxmem=1099511627776k \
>
> -object '{"qom-type":"memory-backend-memfd","id":"memepc0","hugetlb":true,"hugetlbsize":2097152,"prealloc":true,"size":67108864,"host-nodes":[0],"policy":"bind"}' \
> -M sgx-epc.0.memdev=memepc0 \
>
> qemu-system-x86_64: Parameter 'sgx-epc.0.node' is missing

Did you use qemu latest master branch here for experiments? NUMA
support is added in qemu master branch, which requires 'sgx-epc.0.node'
parameter, but not in its latest 6.2.0 release.

So here I didn’t add 'sgx-epc.0.node' parameter to align with qemu 6.2.0.
NUMA support could be separate patch after qemu new release. The other
options is we add NUMA support at this time. Any suggestions?

>
> But okay, I can add .node, but that doesn't get me much further:
>
> /home/zippy/work/qemu/qemu.git/build/qemu-system-x86_64 \
>
> -machine pc-i440fx-4.0,usb=off,dump-guest-core=off \
> -accel kvm \
> -cpu host,migratable=on \
> -m size=4194304k,slots=16,maxmem=1099511627776k \
>
> -object '{"qom-type":"memory-backend-memfd","id":"memepc0","hugetlb":true,"hugetlbsize":2097152,"prealloc":true,"size":67108864,"host-nodes":[0],"policy":"bind"}' \
> -M sgx-epc.0.memdev=memepc0,sgx-epc.0.node=0 \
>
> qemu-system-x86_64: Invalid parameter type for 'memdev', expected: memory-backend-epc

I think I fixed this kind of issue by moving memory-backend-epc type check before hugetlb
check. Could you pls share your domain xml, so I can reproduce it on my side? Thanks.

Thanks,
Lin.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220224/9a9569fd/attachment-0001.htm>


More information about the libvir-list mailing list