All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 6/6] VT-d: avoid allocating domid_{bit,}map[] when possible
Date: Mon, 15 Nov 2021 10:37:13 +0100	[thread overview]
Message-ID: <81bafc7c-673e-377c-3417-49f83ad0b284@suse.com> (raw)
In-Reply-To: <BN9PR11MB5433479ED71950BF52AFB8AD8C989@BN9PR11MB5433.namprd11.prod.outlook.com>

On 15.11.2021 07:18, Tian, Kevin wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, November 12, 2021 5:50 PM
>>
>> When an IOMMU implements the full 16 bits worth of DID in context
>> entries, there's no point going through a memory base translation table.
>> For IOMMUs not using Caching Mode we can simply use the domain IDs
>> verbatim, while for Caching Mode we need to avoid DID 0.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> For the case where the memory tables are needed, xvzalloc_array() would
>> of course be an option to use here as well, despite this being boot time
>> allocations. Yet the introduction of xvmalloc() et al continues to be
>> stuck ...
>>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -62,11 +62,32 @@ static struct tasklet vtd_fault_tasklet;
>>  static int setup_hwdom_device(u8 devfn, struct pci_dev *);
>>  static void setup_hwdom_rmrr(struct domain *d);
>>
>> +static bool domid_mapping(const struct vtd_iommu *iommu)
>> +{
>> +    return (const void *)iommu->domid_bitmap != (const void *)iommu-
>>> domid_map;
>> +}
>> +
>> +static domid_t convert_domid(const struct vtd_iommu *iommu, domid_t
>> domid)
>> +{
>> +    /*
>> +     * While we need to avoid DID 0 for caching-mode IOMMUs, maintain
>> +     * the property of the transformation being the same in either
>> +     * direction. By clipping to 16 bits we ensure that the resulting
>> +     * DID will fit in the respective context entry field.
>> +     */
>> +    BUILD_BUG_ON(sizeof(domid_t) > sizeof(uint16_t));
>> +
>> +    return !cap_caching_mode(iommu->cap) ? domid : ~domid;
> 
> If DOMID_MASK grows to 0xFFFF (though unlikely),

I did consider this too unlikely to warrant taking care of. Now that
you ask for it anyway, ...

> then it translates 
> to '0' when caching mode is true. We need extend BUILD_BUG_ON() to 
> check DOMID_MASK in this case, since caching mode implies
> total_size minus one for available domain IDs 

... I guess I'd rather replace the BUILD_BUG_ON() than extend it or
add a 2nd one.

Jan



      reply	other threads:[~2021-11-15  9:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12  9:46 [PATCH 0/6] VT-d: domain ID mapping improvements Jan Beulich
2021-11-12  9:47 ` [PATCH 1/6] VT-d: properly reserve DID 0 for caching mode IOMMUs Jan Beulich
2021-11-12 11:23   ` Roger Pau Monné
2021-11-12 12:07     ` Jan Beulich
2021-11-12 12:19       ` Roger Pau Monné
2021-11-15  5:13         ` Tian, Kevin
2021-11-12 12:21   ` Roger Pau Monné
2021-11-15  5:13   ` Tian, Kevin
2021-11-12  9:48 ` [PATCH 2/6] VT-d: split domid map cleanup check into a function Jan Beulich
2021-11-12 12:31   ` Roger Pau Monné
2021-11-15  5:16   ` Tian, Kevin
2021-11-12  9:48 ` [PATCH 3/6] VT-d: don't leak domid mapping on error path Jan Beulich
2021-11-12 13:42   ` Roger Pau Monné
2021-11-12 13:45     ` Jan Beulich
2021-11-12 14:35       ` Roger Pau Monné
2021-11-15  9:32         ` Jan Beulich
2021-11-15  5:21   ` Tian, Kevin
2021-11-12  9:49 ` [PATCH 4/6] VT-d: tidy domid map handling Jan Beulich
2021-11-15  5:51   ` Tian, Kevin
2021-11-12  9:49 ` [PATCH 5/6] VT-d: introduce helper to convert DID to domid_t Jan Beulich
2021-11-15  5:54   ` Tian, Kevin
2021-11-12  9:50 ` [PATCH 6/6] VT-d: avoid allocating domid_{bit,}map[] when possible Jan Beulich
2021-11-15  6:18   ` Tian, Kevin
2021-11-15  9:37     ` Jan Beulich [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=81bafc7c-673e-377c-3417-49f83ad0b284@suse.com \
    --to=jbeulich@suse.com \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xenproject.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.