On 11/08/22 19:02, Chao Peng wrote:
On Thu, Aug 11, 2022 at 01:30:06PM +0200, Gupta, Pankaj wrote:
While debugging an issue with SEV+UPM, found that fallocate() returns an error in QEMU which is not handled (EINTR). With the below handling of EINTR subsequent fallocate() succeeds:
QEMU code has not well-tested so it's not strange you met problem. But from the man page, there is signal was caught for EINTR, do you know the signal number?
Thanks for you patch but before we change it in QEMU I want to make sure it's indeed a QEMU issue (e.g. not a kernel isssue).
diff --git a/backends/hostmem-memfd-private.c b/backends/hostmem-memfd-private.c index af8fb0c957..e8597ed28d 100644 --- a/backends/hostmem-memfd-private.c +++ b/backends/hostmem-memfd-private.c @@ -39,7 +39,7 @@ priv_memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp) MachineState *machine = MACHINE(qdev_get_machine()); uint32_t ram_flags; char *name;
- int fd, priv_fd;
- int fd, priv_fd, ret; if (!backend->size) { error_setg(errp, "can't create backend with size 0");
@@ -65,7 +65,15 @@ priv_memfd_backend_memory_alloc(HostMemoryBackend *backend, Error **errp) backend->size, ram_flags, fd, 0, errp); g_free(name);
- fallocate(priv_fd, 0, 0, backend->size);
+again:
- ret = fallocate(priv_fd, 0, 0, backend->size);
- if (ret) {
perror("Fallocate failed: \n");if (errno == EINTR)goto again;elseexit(1);- }
However, fallocate() preallocates full guest memory before starting the guest. With this behaviour guest memory is *not* demand pinned.
This is with reference to the SEV demand pinning patches that I was working on. The understanding was UPM will not reserve memory for SEV/TDX guest in the beginning similar to normal guest. Here is the relevant quote from the discussion with Sean[1]:
"I think we should abandon this approach in favor of committing all our resources to fd-based private memory[*], which (if done right) will provide on-demand pinning for "free". "
Is there a way to prevent fallocate() from reserving full guest memory?
Regards Nikunj [1] https://lore.kernel.org/kvm/YkIh8zM7XfhsFN8L@google.com/