From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Xu <peterx@redhat.com>, Jason Wang <jasowang@redhat.com>,
mst@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH for 8.1] intel_iommu: refine iotlb hash calculation
Date: Wed, 12 Apr 2023 09:22:38 +0100 [thread overview]
Message-ID: <87fs95pk7n.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9jbuR72u=o6tUvpiA+SYFiASnoYRocKWVurscvdUJJAg@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Tue, 11 Apr 2023 at 15:14, Peter Xu <peterx@redhat.com> wrote:
>>
>> On Mon, Apr 10, 2023 at 11:32:08AM +0800, Jason Wang wrote:
>> > @@ -222,9 +222,9 @@ static guint vtd_iotlb_hash(gconstpointer v)
>> > {
>> > const struct vtd_iotlb_key *key = v;
>> >
>> > - return key->gfn | ((key->sid) << VTD_IOTLB_SID_SHIFT) |
>> > - (key->level) << VTD_IOTLB_LVL_SHIFT |
>> > - (key->pasid) << VTD_IOTLB_PASID_SHIFT;
>> > + return key->gfn | ((uint64_t)(key->sid) << VTD_IOTLB_SID_SHIFT) |
>> > + (uint64_t)(key->level - 1) << VTD_IOTLB_LVL_SHIFT |
>> > + (uint64_t)(key->pasid) << VTD_IOTLB_PASID_SHIFT;
>> > }
>
>> > /* The shift of source_id in the key of IOTLB hash table */
>> > -#define VTD_IOTLB_SID_SHIFT 20
>> > -#define VTD_IOTLB_LVL_SHIFT 28
>> > -#define VTD_IOTLB_PASID_SHIFT 30
>> > +#define VTD_IOTLB_SID_SHIFT 26
>> > +#define VTD_IOTLB_LVL_SHIFT 42
>> > +#define VTD_IOTLB_PASID_SHIFT 44
>>
>> This is for the hash function only, IIUC it means anything over
>> sizeof(guint) will be ignored and not contributing anything to the hash
>> value being generated due to the uint64->guint conversion.
>>
>> IOW, I think "level" and "pasid" will just be ignored.
>
> Whoops, hadn't noticed that guint type... (glib's
> g_int64_hash()'s approach to this is to XOR the top
> 32 bits with the bottom 32 bits to produce the 32-bit
> hash value.)
This is less of a hash and more just concatting a bunch of fields. BTW
if the glib built-in hash isn't suitable we also have the qemu_xxhash()
functions which claim a good distribution of values and we use in a
number of places throughout the code.
> Also, does anybody know what the requirements are on
> consistency between the hash_func and the key_equal_func
> for a GHashTable ? Is the hash_func supposed to return the
> same hash for every key that compares equal under key_equal_func ?
>
> thanks
> -- PMM
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-04-12 8:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 3:32 [PATCH for 8.1] intel_iommu: refine iotlb hash calculation Jason Wang
2023-04-11 13:34 ` Peter Maydell
2023-04-11 14:14 ` Peter Xu
2023-04-11 14:30 ` Peter Maydell
2023-04-11 14:44 ` Peter Xu
2023-04-12 6:52 ` Jason Wang
2023-04-12 8:22 ` Alex Bennée [this message]
2023-04-12 21:06 ` Peter Maydell
2023-04-13 9:42 ` Alex Bennée
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=87fs95pk7n.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.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 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.