On 11/08/22 19:02, Chao Peng wrote: > On Thu, Aug 11, 2022 at 01:30:06PM +0200, Gupta, Pankaj wrote: >> >>>> 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
