On Fri, Sep 10, 2021, Paolo Bonzini wrote: > On 19/07/21 13:21, Yang Zhong wrote: > > +void sgx_memory_backend_reset(HostMemoryBackend *backend, int fd, > > + Error **errp) > > +{ > > + MemoryRegion *mr = &backend->mr; > > + > > + mr->enabled = false; > > + > > + /* destroy the old memory region if it exist */ > > + if (fd > 0 && mr->destructor) { > > + mr->destructor(mr); > > + } > > + > > + sgx_epc_backend_memory_alloc(backend, errp); > > +} > > + > > Jarkko, Sean, Kai, > > this I think is problematic because it has a race window while /dev/sgx_vepc > is closed and then reopened. First, the vEPC space could be exhausted by > somebody doing another mmap in the meanwhile. Second, somebody might (for > whatever reason) remove /dev/sgx_vepc while QEMU runs.
Yep, both error cases are possible. > Yang explained to me (offlist) that this is needed because Windows fails to > reboot without it. We would need a way to ask Linux to reinitialize the > vEPC, that doesn't involve munmap/mmap; this could be for example > fallocate(FALLOC_FL_ZERO_RANGE). > > What do you all think? Mechanically, FALLOC_FL_ZERO_RANGE could work, but it's definitely a stretch of the semantics as the underlying memory would not actually be zeroed. The only other option that comes to mind is a dedicated ioctl().