[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 22/33] hostmem-epc: Add the reset interface for EPC backen
From: |
Sean Christopherson |
Subject: |
Re: [PATCH v4 22/33] hostmem-epc: Add the reset interface for EPC backend reset |
Date: |
Fri, 10 Sep 2021 15:34:55 +0000 |
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().
Re: [PATCH v4 22/33] hostmem-epc: Add the reset interface for EPC backend reset, Jarkko Sakkinen, 2021/09/13