From: Glauber Costa <glommer@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org, avi@redhat.com
Subject: [PATCH] always assign userspace_addr
Date: Tue, 18 Nov 2008 01:04:22 -0200 [thread overview]
Message-ID: <1226977462-8086-1-git-send-email-glommer@redhat.com> (raw)
Currently, kvm only sets new.userspace_addr in slots
that were just allocated. This is not the intended behaviour,
and actually breaks when we try to use the slots to implement
aliases, for example.
Cirrus VGA aliases maps and address to a userspace address, and
then keep mapping this same address to different locations
until the whole screen is filled.
The solution is to assign new.userspace_addr no matter what,
so we can be sure that whenever the guest changes this field,
it sees the change being reflected in the code.
Signed-off-by: Glauber Costa <glommer@redhat.com>
---
virt/kvm/kvm_main.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a87f45e..fc3abf0 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -762,15 +762,6 @@ int __kvm_set_memory_region(struct kvm *kvm,
memset(new.rmap, 0, npages * sizeof(*new.rmap));
new.user_alloc = user_alloc;
- /*
- * hva_to_rmmap() serialzies with the mmu_lock and to be
- * safe it has to ignore memslots with !user_alloc &&
- * !userspace_addr.
- */
- if (user_alloc)
- new.userspace_addr = mem->userspace_addr;
- else
- new.userspace_addr = 0;
}
if (npages && !new.lpage_info) {
int largepages = npages / KVM_PAGES_PER_HPAGE;
@@ -791,6 +782,15 @@ int __kvm_set_memory_region(struct kvm *kvm,
if ((base_gfn+npages) % KVM_PAGES_PER_HPAGE)
new.lpage_info[largepages-1].write_count = 1;
}
+ /*
+ * hva_to_rmmap() serialzies with the mmu_lock and to be
+ * safe it has to ignore memslots with !user_alloc &&
+ * !userspace_addr.
+ */
+ if (npages && user_alloc)
+ new.userspace_addr = mem->userspace_addr;
+ else
+ new.userspace_addr = 0;
/* Allocate page dirty bitmap if needed */
if ((new.flags & KVM_MEM_LOG_DIRTY_PAGES) && !new.dirty_bitmap) {
--
1.5.6.5
next reply other threads:[~2008-11-18 1:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 3:04 Glauber Costa [this message]
2008-11-19 15:55 ` [PATCH] always assign userspace_addr Anthony Liguori
2008-11-19 18:43 ` Glauber Costa
2008-11-19 18:51 ` Anthony Liguori
2008-11-19 20:53 ` Glauber Costa
2008-11-19 20:59 ` Anthony Liguori
2008-11-20 11:01 ` Avi Kivity
2008-11-20 11:02 ` Avi Kivity
2008-11-21 18:11 ` Glauber Costa
2008-11-24 13:08 ` Glauber Costa
2008-11-25 14:04 ` Avi Kivity
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=1226977462-8086-1-git-send-email-glommer@redhat.com \
--to=glommer@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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