<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> On 11/8/22, 5:16 AM, "Peter Krempa" <pkrempa@redhat.com> wrote:<o:p></o:p> > On Tue, Nov 08, 2022 at 12:25:26 +0000, Daniel P. Berrangé wrote:<o:p></o:p> > > On Fri, Oct 14, 2022 at 01:12:28PM +0200, Michal Prívozník wrote:<o:p></o:p> > > > On 10/8/22 06:00, Lin Yang wrote:<o:p></o:p> > <o:p></o:p> > [...]<o:p></o:p> > <o:p></o:p> > > > <o:p></o:p> > > > # ./qemu-system-x86_64 -S -nographic -nodefaults -m 128 \<o:p></o:p> > > > -machine pc,sgx-epc.0.memdev=memepc0,sgx-epc.0.node=0 \<o:p></o:p> > > > -object '{"qom-type":"memory-backend-epc","id":"memepc0","prealloc":true,"size":67108864,"host-nodes":[0],"policy":"bind"}' \<o:p></o:p> > > > -monitor stdio<o:p></o:p> > > > QEMU 7.1.50 monitor - type 'help' for more information<o:p></o:p> > > > (qemu) info memory-devices <o:p></o:p> > > > Memory device [sgx-epc]: ""<o:p></o:p> > > > memaddr: 0x100000000<o:p></o:p> > > > size: 67108864<o:p></o:p> > > > node: 0<o:p></o:p> > > > memdev: /objects/memepc0<o:p></o:p> > > > (qemu) info memory_size_summary <o:p></o:p> > > > base memory: 134217728<o:p></o:p> > > > plugged memory: 0<o:p></o:p> > > > (qemu)<o:p></o:p> > > <o:p></o:p> > > I'm not sure this check is showing us the truth.<o:p></o:p> > > <o:p></o:p> > > In backends/hostmem-epc.c, sgx_epc_backend_memory_alloc is<o:p></o:p> > > opening /dev/sgx_vepc and mmap()ing the requested size from<o:p></o:p> > > that file. IOW that's clearly in addition to whatever has<o:p></o:p> > > been mapped as the main RAM.<o:p></o:p> > > <o:p></o:p> > > In hw/i386/sgx-epc.c, sgx_epc_md_get_plugged_size is hardcoded<o:p></o:p> > > to always return 0, which is why 'plugged memory' is reported<o:p></o:p> > > as zero above. I don't know what it is reporting zero.<o:p></o:p> > > <o:p></o:p> > > Is this because the SGX RAM is not accessible to the guest OS<o:p></o:p> > > as "normal" RAM perhaps, and thus to be reported differently.<o:p></o:p> > <o:p></o:p> > So even if the memory is not accessible as normal RAM, but still is<o:p></o:p> > usable by the guest OS, the use of an <devices><memory> element is okay,<o:p></o:p> > but the total memory size of a VM should account for it.<o:p></o:p> > <o:p></o:p> > So in fact all the hacks which exclude it from the total memory size<o:p></o:p> > should be removed.<o:p></o:p> <o:p> </o:p> QEMU reports zero 'plugged memory' for SGX RAM because it will not<o:p></o:p> add more normal RAM to guest OS and it cannot be hotplug/unplug on<o:p></o:p> the fly, since it is realized through CPUID and has to be initialized before<o:p></o:p> vcpu.<o:p></o:p> <o:p> </o:p> One the host, BIOS reserves part of RAM as SGX RAM, which cannot be<o:p></o:p> directly accessed by other application or kernel. The host OS only <o:p></o:p> see RAM size = physical memory size – SGX RAM.<o:p></o:p> <o:p> </o:p> Does “total memory size” here means all memory device size, like all<o:p></o:p> physical memory size on host, not normal RAM size? If not, it might <o:p></o:p> give confusing info to user since guset OS shows a different normal RAM<o:p></o:p> size.<o:p></o:p> <o:p> </o:p> Really appreciated all your reviewing.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Lin. <o:p></o:p> </div> </body> </html>