From: stsp <stsp2@yandex.ru>
To: kvm@vger.kernel.org
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Subject: guest/host mem out of sync on core2duo?
Date: Sun, 13 Jun 2021 01:49:13 +0300 [thread overview]
Message-ID: <bd4a2d30-5fb4-3612-c855-946d97068b9a@yandex.ru> (raw)
Hi kvm developers.
I am having the strange problem
that can only be reproduced on a
core2duo CPU but not AMD FX or
Intel Core I7.
My code has 2 ways of setting the
guest registers: one is the guest's
ring0 stub that just pops all regs
from stack and does iret to ring3.
That works fine.
But sometimes I use KVM_SET_SREGS
and resume the VM directly to ring3.
That randomly results in either a
good run or invalid guest state
return, or a page fault in guest.
I tried to analyze when either of
the above happens exactly, and
I have a very strong suspection
that the problem is in a way I
update LDT. LDT is shared between
guest and host with KVM_SET_USER_MEMORY_REGION,
and I modify it on host.
So it seems like if I just allocated
the new LDT entry, there is a risk
of invalid guest state, as if the
guest's LDT still doesn't have it.
If I modified some LDT entry, there
can be a page fault in guest, as if
the entry is still old.
I've found that the one needs to
check KVM_CAP_SYNC_MMU to
safely write to the guest memory,
but it doesn't seem to be documented
well. Of course maybe my problem
has nothing to do with that, but I
think it does.
So can it be that even though I
check for the KVM_CAP_SYNC_MMU,
writing to the guest memory from
host is still unsafe? What is this
KVM_CAP_SYNC_MMU actually all
about?
next reply other threads:[~2021-06-12 22:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 22:49 stsp [this message]
2021-06-13 12:36 ` guest/host mem out of sync on core2duo? stsp
2021-06-14 17:06 ` Sean Christopherson
2021-06-14 17:32 ` stsp
2021-06-17 14:42 ` Sean Christopherson
2021-06-18 15:59 ` stsp
2021-06-18 21:07 ` Jim Mattson
2021-06-18 21:55 ` stsp
2021-06-18 22:06 ` Jim Mattson
2021-06-18 22:26 ` stsp
2021-06-18 22:32 ` Sean Christopherson
2021-06-19 0:11 ` stsp
2021-06-19 0:54 ` Sean Christopherson
2021-06-19 9:18 ` stsp
2021-06-21 2:34 ` exception vs SIGALRM race (was: Re: guest/host mem out of sync on core2duo?) stsp
2021-06-21 22:33 ` Jim Mattson
2021-06-21 23:32 ` stsp
2021-06-22 0:27 ` stsp
2021-06-28 21:47 ` Jim Mattson
2021-06-28 21:50 ` stsp
2021-06-28 22:00 ` stsp
2021-06-28 22:27 ` Jim Mattson
2021-07-06 16:28 ` Paolo Bonzini
2021-07-06 22:22 ` stsp
2021-07-06 23:41 ` Paolo Bonzini
2021-06-23 23:38 ` exception vs SIGALRM race (with test-case now!) stsp
2021-06-24 0:11 ` stsp
2021-06-24 0:25 ` stsp
2021-06-24 18:05 ` exception vs SIGALRM race on core2 CPUs (with qemu-based test-case this time!) stsp
2021-06-24 18:07 ` stsp
2021-06-25 23:35 ` exception vs SIGALRM race on core2 CPUs (with fix!) stsp
2021-06-26 0:15 ` Jim Mattson
2021-06-26 0:35 ` stsp
2021-06-26 21:50 ` stsp
2021-06-27 12:13 ` stsp
2021-06-26 14:03 ` exception vs SIGALRM race (another patch) stsp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd4a2d30-5fb4-3612-c855-946d97068b9a@yandex.ru \
--to=stsp2@yandex.ru \
--cc=kvm@vger.kernel.org \
--cc=sean.j.christopherson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.