Thread (164 messages) 164 messages, 20 authors, 2023-05-25

Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory

From: Nikunj A. Dadhania <hidden>
Date: 2022-08-11 17:28:56
Also in: kvm, linux-doc, linux-fsdevel, linux-kselftest, linux-mm, lkml, qemu-devel

On 11/08/22 19:02, Chao Peng wrote:
On Thu, Aug 11, 2022 at 01:30:06PM +0200, Gupta, Pankaj wrote:
quoted
quoted
quoted
quoted
Test
----
To test the new functionalities of this patch TDX patchset is needed.
Since TDX patchset has not been merged so I did two kinds of test:

-  Regresion test on kvm/queue (this patchset)
    Most new code are not covered. Code also in below repo:
    https://github.com/chao-p/linux/tree/privmem-v7

-  New Funational test on latest TDX code
    The patch is rebased to latest TDX code and tested the new
    funcationalities. See below repos:
    Linux: https://github.com/chao-p/linux/tree/privmem-v7-tdx
    QEMU: https://github.com/chao-p/qemu/tree/privmem-v7
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?
I haven't check that, but that should be fairly straight forward to get.
I presume that you are referring to signal_pending() in the shmem_fallocate()
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).
As per the manual fallocate() can return EINTR, and this should be handled 
by the user space.

Regards
Nikunj
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help