Xen devel - Nov 2007 - [VTD][PATCH] Use bitmap to solve domain-id limitation issue

The Capability register reports the domain-id width supported by
hardware. For implementations supporting less than 16-bit domainids,
unused bits of domain identifier field(87:72) in Context entry are
treated as reserved by hardware. For example, for an implementation
supporting 4-bit domain-ids, bits 87:76 of this field are treated as
reserved. 16 is a small number, overflow is easy to happen. What''s
more,
context-entries programmed with the same domain identifier must always
reference the same address translation structure (through the ASR
field). So Dom16 will conflict with Dom0, and device assignment fails.

This patch implements a domaid id bitmap to solve above issue.

Signed-off-by: Weidong Han <weidong.han@intel.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Why must a list be walked every time you want to translate domid->iommu_id?
Wouldn''t you be better to store it in struct hvm_iommu?

Under what lock is the list of domid/iommu_id mappings protected? Under what
lock is the allocation bitmap protected (if necessary)?

This patch is definitely in the right direction, I just think it''s not
fully
baked yet...

 -- Keir

On 29/11/07 13:33, "Han, Weidong" <weidong.han@intel.com> wrote:
> The Capability register reports the domain-id width supported by
> hardware. For implementations supporting less than 16-bit domainids,
> unused bits of domain identifier field(87:72) in Context entry are
> treated as reserved by hardware. For example, for an implementation
> supporting 4-bit domain-ids, bits 87:76 of this field are treated as
> reserved. 16 is a small number, overflow is easy to happen. What''s
more,
> context-entries programmed with the same domain identifier must always
> reference the same address translation structure (through the ASR
> field). So Dom16 will conflict with Dom0, and device assignment fails.
> 
> This patch implements a domaid id bitmap to solve above issue.
> 
> Signed-off-by: Weidong Han <weidong.han@intel.com>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Keir,

I baked a new patch. It removes the mapping list, stores iommu domain id
in struct hvm_iommu instead. In addition, add a spinlock to protect
domain id bitmap. Pls review it. Thanks.

Randy (Weidong)

Keir Fraser wrote:
> Why must a list be walked every time you want to translate
> domid->iommu_id? Wouldn''t you be better to store it in struct
> hvm_iommu? 
> 
> Under what lock is the list of domid/iommu_id mappings protected?
> Under what lock is the allocation bitmap protected (if necessary)?
> 
> This patch is definitely in the right direction, I just think it''s
> not fully baked yet...
> 
>  -- Keir
> 
> On 29/11/07 13:33, "Han, Weidong" <weidong.han@intel.com>
wrote:
> 
>> The Capability register reports the domain-id width supported by
>> hardware. For implementations supporting less than 16-bit domainids,
>> unused bits of domain identifier field(87:72) in Context entry are
>> treated as reserved by hardware. For example, for an implementation
>> supporting 4-bit domain-ids, bits 87:76 of this field are treated as
>> reserved. 16 is a small number, overflow is easy to happen.
What''s
>> more, context-entries programmed with the same domain identifier
>> must always reference the same address translation structure
>> (through the ASR field). So Dom16 will conflict with Dom0, and
>> device assignment fails. 
>> 
>> This patch implements a domaid id bitmap to solve above issue.
>> 
>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Better. The locking is screwed but I''ve fixed it up and checked it in.

 -- Keir

On 5/12/07 07:25, "Han, Weidong" <weidong.han@intel.com> wrote:
> Hi Keir,
> 
> I baked a new patch. It removes the mapping list, stores iommu domain id
> in struct hvm_iommu instead. In addition, add a spinlock to protect
> domain id bitmap. Pls review it. Thanks.
> 
> Randy (Weidong)
> 
> Keir Fraser wrote:
>> Why must a list be walked every time you want to translate
>> domid->iommu_id? Wouldn''t you be better to store it in
struct
>> hvm_iommu? 
>> 
>> Under what lock is the list of domid/iommu_id mappings protected?
>> Under what lock is the allocation bitmap protected (if necessary)?
>> 
>> This patch is definitely in the right direction, I just think
it''s
>> not fully baked yet...
>> 
>>  -- Keir
>> 
>> On 29/11/07 13:33, "Han, Weidong"
<weidong.han@intel.com> wrote:
>> 
>>> The Capability register reports the domain-id width supported by
>>> hardware. For implementations supporting less than 16-bit
domainids,
>>> unused bits of domain identifier field(87:72) in Context entry are
>>> treated as reserved by hardware. For example, for an implementation
>>> supporting 4-bit domain-ids, bits 87:76 of this field are treated
as
>>> reserved. 16 is a small number, overflow is easy to happen.
What''s
>>> more, context-entries programmed with the same domain identifier
>>> must always reference the same address translation structure
>>> (through the ASR field). So Dom16 will conflict with Dom0, and
>>> device assignment fails.
>>> 
>>> This patch implements a domaid id bitmap to solve above issue.
>>> 
>>> Signed-off-by: Weidong Han <weidong.han@intel.com>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel