From: Arnd Bergmann <arnd@arndb.de>
To: Avi Kivity <avi@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>,
"Fernando Luis Vázquez Cao" <fernando@oss.ntt.co.jp>,
"Takuya Yoshikawa" <yoshikawa.takuya@oss.ntt.co.jp>,
mtosatti@redhat.com, kvm@vger.kernel.org,
kvm-ia64@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty bitmaps
Date: Fri, 23 Apr 2010 14:46:07 +0200 [thread overview]
Message-ID: <201004231446.07880.arnd@arndb.de> (raw)
In-Reply-To: <4BD195B7.3070409@redhat.com>
On Friday 23 April 2010, Avi Kivity wrote:
> On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
> >
> >> Using a 64-bit integer avoids the problem (though perhaps not sufficient
> >> for s390, Arnd?)
> >>
> > When there is only a __u64 for the address, it will work on s390 as well,
> > gcc is smart enough to clear the upper bit on a cast from long to pointer.
> >
>
> Ah, much more convenient than compat_ioctl. I assume it part of the
> ABI, not a gccism?
I don't think it's part of the ABI, but it's required to guarantee
that code like this works:
int compare_pointer(void *a, void *b)
{
unsigned long ai = (unsigned long)a, bi = (unsigned long)b;
return ai == bi; /* true if a and b point to the same object */
}
We certainly rely on this already.
Arnd
next prev parent reply other threads:[~2010-04-23 12:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-20 10:53 [PATCH RFC v2 0/6] KVM: moving dirty gitmaps to user space! Takuya Yoshikawa
2010-04-20 10:54 ` Alexander Graf
[not found] ` <C70797C1-08EC-4DBA-9595-4047CAE8E457-l3A5Bk7waGM@public.gmane.org>
2010-04-20 11:13 ` Takuya Yoshikawa
2010-04-20 10:56 ` [PATCH RFC v2 1/6] KVM: introduce slot level dirty state management Takuya Yoshikawa
2010-04-20 10:57 ` [PATCH RFC v2 2/6] KVM: introduce wrapper functions to create and destroy dirty bitmaps Takuya Yoshikawa
2010-04-20 11:00 ` [PATCH RFC v2 4/6] KVM: change mark_page_dirty() to handle endian issues explicitly Takuya Yoshikawa
[not found] ` <20100420200043.956302db.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-20 11:00 ` Alexander Graf
2010-04-20 11:20 ` Takuya Yoshikawa
2010-04-21 11:15 ` Avi Kivity
[not found] ` <20100420195349.dab60b1d.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-20 10:59 ` [PATCH RFC v2 3/6] KVM: introduce a wrapper function to copy dirty bitmaps to user space Takuya Yoshikawa
[not found] ` <20100420195913.ac44281c.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-21 11:12 ` Avi Kivity
2010-04-22 8:57 ` Takuya Yoshikawa
[not found] ` <4BD00F64.4020405-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-23 10:26 ` Avi Kivity
2010-04-20 11:02 ` [PATCH RFC v2 5/6] KVM: moving " Takuya Yoshikawa
[not found] ` <20100420200225.efca602f.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-20 11:10 ` Alexander Graf
[not found] ` <20234257-D6B8-44A6-BD91-C7B9D0E4970B-l3A5Bk7waGM@public.gmane.org>
2010-04-20 11:26 ` Takuya Yoshikawa
2010-04-21 11:26 ` Avi Kivity
[not found] ` <4BCEE0E4.6060707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-22 9:07 ` Takuya Yoshikawa
2010-04-23 10:28 ` Avi Kivity
[not found] ` <4BD17665.5090101-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-23 11:14 ` Takuya Yoshikawa
[not found] ` <4BD1812E.6030707-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-23 11:29 ` Yoshiaki Tamura
2010-04-23 11:45 ` Avi Kivity
2010-04-20 11:03 ` [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty bitmaps Takuya Yoshikawa
2010-04-20 11:15 ` Alexander Graf
[not found] ` <480E8E1E-32BD-429E-96C8-5AA69A8BDDF3-l3A5Bk7waGM@public.gmane.org>
2010-04-20 11:33 ` Takuya Yoshikawa
[not found] ` <4BCD90FE.9060300-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-20 11:33 ` Alexander Graf
2010-04-20 11:44 ` Takuya Yoshikawa
2010-04-21 8:29 ` Fernando Luis Vázquez Cao
2010-04-21 9:41 ` Alexander Graf
2010-04-22 2:45 ` Fernando Luis Vázquez Cao
[not found] ` <4BCFB862.7010509-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-22 6:09 ` Fernando Luis Vázquez Cao
[not found] ` <4BCFE805.5040500-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-22 23:29 ` Alexander Graf
2010-04-23 10:17 ` Fernando Luis Vázquez Cao
2010-04-23 10:20 ` Alexander Graf
[not found] ` <9B7714E9-7244-4569-B8DB-B3E31E680CAF-l3A5Bk7waGM@public.gmane.org>
2010-04-23 11:57 ` Avi Kivity
[not found] ` <4BD18B1D.1080604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-23 12:26 ` Alexander Graf
2010-04-23 12:27 ` Arnd Bergmann
2010-04-23 12:42 ` Avi Kivity
2010-04-23 12:46 ` Arnd Bergmann [this message]
2010-04-23 12:53 ` Avi Kivity
[not found] ` <4BD19831.5000405-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-23 12:59 ` Alexander Graf
[not found] ` <9557F344-EC7C-450F-AED9-5BB865C08650-l3A5Bk7waGM@public.gmane.org>
2010-04-23 13:20 ` Avi Kivity
2010-04-23 13:12 ` Arnd Bergmann
[not found] ` <20100420200353.2d2a6dec.yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-21 11:46 ` Avi Kivity
[not found] ` <4BCEE579.9020206-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-04-22 9:34 ` Takuya Yoshikawa
[not found] ` <4BD0181C.6020900-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>
2010-04-23 11:58 ` Avi Kivity
2010-04-20 12:05 ` [PATCH RFC v2 0/6] KVM: moving dirty gitmaps to user space! Takuya Yoshikawa
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=201004231446.07880.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=fernando@oss.ntt.co.jp \
--cc=kvm-ia64@vger.kernel.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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