From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@linux.vnet.ibm.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org
Cc: cornelia.huck@de.ibm.com, agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH RFC 0/1] KVM: ioctl for reading/writing guest memory
Date: Tue, 03 Feb 2015 14:05:32 +0100 [thread overview]
Message-ID: <54D0C79C.409@de.ibm.com> (raw)
In-Reply-To: <54D0C64D.8090400@redhat.com>
Am 03.02.2015 um 13:59 schrieb Paolo Bonzini:
>
>
> On 03/02/2015 13:11, Thomas Huth wrote:
>> The userspace (QEMU) then can simply call this ioctl when it wants
>> to read or write from/to virtual guest memory. Then kernel then takes
>> the IPTE-lock, walks the MMU table of the guest to find out the
>> physical address that corresponds to the virtual address, copies
>> the requested amount of bytes from the userspace buffer to guest
>> memory or the other way round, and finally frees the IPTE-lock again.
>>
>> Does that sound like a viable solution (IMHO it does ;-))? Or should
>> I maybe try to pursue another approach?
>
> It looks feasible to me as well.
Yes, we discussed this internally a lot and things are really tricky. The
ipte lock could be exported to userspace, but we might also need to handle
storage keys (and key protection) in an atomic fashion, so this really
looks like the only safe way.
I guess we will give it some more testing, but to me it looks like a good
candidate for kvm/next after 3.20-rc1.
Christian
prev parent reply other threads:[~2015-02-03 13:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 12:11 [Qemu-devel] [PATCH RFC 0/1] KVM: ioctl for reading/writing guest memory Thomas Huth
2015-02-03 12:11 ` [Qemu-devel] [PATCH RFC 1/1] KVM: s390: Add MEMOP " Thomas Huth
2015-02-03 13:04 ` Paolo Bonzini
2015-02-03 15:16 ` Thomas Huth
2015-02-03 15:22 ` Paolo Bonzini
2015-02-04 7:53 ` Thomas Huth
2015-02-04 8:26 ` Christian Borntraeger
2015-02-04 10:39 ` Paolo Bonzini
2015-02-04 11:25 ` Christian Borntraeger
2015-02-04 11:42 ` Paolo Bonzini
2015-02-04 12:16 ` Christian Borntraeger
2015-02-04 10:57 ` Thomas Huth
2015-02-05 13:00 ` Cornelia Huck
2015-02-03 12:59 ` [Qemu-devel] [PATCH RFC 0/1] KVM: " Paolo Bonzini
2015-02-03 13:05 ` Christian Borntraeger [this message]
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=54D0C79C.409@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=agraf@suse.de \
--cc=cornelia.huck@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).