[libvirt][PATCH v16 5/9] conf: Introduce SGX EPC element into device memory xml

Yang, Lin A lin.a.yang at intel.com
Thu Nov 10 19:07:53 UTC 2022


On 11/9/22, 11:37 PM, "Peter Krempa" <pkrempa at redhat.com> wrote:
> On Thu, Nov 10, 2022 at 06:09:46 +0000, Yang, Lin A wrote:
> > On 11/8/22, 5:16 AM, "Peter Krempa" <pkrempa at redhat.com> wrote:
> > > On Tue, Nov 08, 2022 at 12:25:26 +0000, Daniel P. Berrangé wrote:
> > > > On Fri, Oct 14, 2022 at 01:12:28PM +0200, Michal Prívozník wrote:
> > > > > On 10/8/22 06:00, Lin Yang wrote:
> > >
> > > [...]
> > >
> > > > >
> > > > > # ./qemu-system-x86_64 -S -nographic -nodefaults -m 128 \
> > > > > -machine pc,sgx-epc.0.memdev=memepc0,sgx-epc.0.node=0 \
> > > > > -object '{"qom-type":"memory-backend-epc","id":"memepc0","prealloc":true,"size":67108864,"host-nodes":[0],"policy":"bind"}' \
> > > > > -monitor stdio
> > > > > QEMU 7.1.50 monitor - type 'help' for more information
> > > > > (qemu) info memory-devices
> > > > > Memory device [sgx-epc]: ""
> > > > >   memaddr: 0x100000000
> > > > >   size: 67108864
> > > > >   node: 0
> > > > >   memdev: /objects/memepc0
> > > > > (qemu) info memory_size_summary
> > > > > base memory: 134217728
> > > > > plugged memory: 0
> > > > > (qemu)
> > > >
> > > > I'm not sure this check is showing us the truth.
> > > >
> > > > In backends/hostmem-epc.c, sgx_epc_backend_memory_alloc is
> > > > opening /dev/sgx_vepc and mmap()ing the requested size from
> > > > that file. IOW that's clearly in addition to whatever has
> > > > been mapped as the main RAM.
> > > >
> > > > In hw/i386/sgx-epc.c, sgx_epc_md_get_plugged_size is  hardcoded
> > > > to always return 0, which is why 'plugged memory' is reported
> > > > as zero above. I don't know what it is reporting zero.
> > > >
> > > > Is this because the SGX RAM is not accessible to the guest OS
> > > > as "normal" RAM perhaps, and thus to be reported differently.
> > >
> > > So even if the memory is not accessible as normal RAM, but still is
> > > usable by the guest OS, the use of an <devices><memory> element is okay,
> > > but the total memory size of a VM should account for it.
> > >
> > > So in fact all the hacks which exclude it from the total memory size
> > > should be removed.
> >
> > QEMU reports zero 'plugged memory' for SGX RAM because it will not
> > add more normal RAM to guest OS and it cannot be hotplug/unplug on
> > the fly, since it is realized through CPUID and has to be initialized before
> > vcpu.
> >
> > One the host, BIOS reserves part of RAM as SGX RAM, which cannot be
> > directly accessed by other application or kernel. The host OS only
> > see RAM size = physical memory size – SGX RAM.
> >
> > Does “total memory size” here means all memory device size, like all
> > physical memory size on host, not normal RAM size? If not, it might
> > give confusing info to user since guset OS shows a different normal RAM
> > size.
>
> Libvirt's total memory size must include any memory usable by the guest
> OS regardless of how it is made available to it and regardless of
> whether un-modified OS is able to use it. Same applies e.g. to
> virtio-mem which requires a guest driver.
>
> Similarly the EPC memory most likely is provided to the guest via normal
> memory mapping (If not make sure to explicitly point it out next time.)
> and thus also must be included in the calculation and validation of
> maximum memory address space. This calculation/validation is done in
> qemuDomainDefValidateMemoryHotplug and thus is correct and EPC must be
> included in it. The funciton and variable naming may be confusing so
> you can change it, but functionally it seems it must be included in the
> calculation.

Thank you so much for explanation in details.

True, EPC is mapped to separate memory region in guest via mmap(). It’s
clear to me now. Let me quickly resolve it in next patch.

Regards,
Lin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20221110/2ff86689/attachment-0001.htm>


More information about the libvir-list mailing list